Question 1

What is the difference between a Set and a Map? When do you pick each?

Accepted Answer

Start from the short definition: both are built on the same hash mechanism; a Set stores keys only, a Map stores key–value pairs. Then give the selection rule in one sentence — that is what makes the answer memorable: "If my question is yes/no it is a Set; if it is which data it is a Map." Give one real example each: Set — removing duplicates from a list of emails, or checking blocked ids; Map — building an id → user index so every later lookup is O(1). Add complexity too, since that is the real point of the question: has/get/add/set are all O(1) average on both. includes on an array is O(n) — at 100k elements that is the difference between a hundred million steps and ten thousand.

Question 2

Can you use an object as a hash map key? Does it differ between languages?

Accepted Answer

Open with "yes, but it depends on how equality is defined", then walk the three languages separately — this structure impresses interviewers. JavaScript: Map uses SameValueZero and objects compare by reference. m.set({id:1}, 'a'); m.get({id:1}) → undefined, because that is a second, entirely different object. For value keys I build a composite string myself: ` ${team}:${id} . Kotlin: equality comes from the equals/hashCode pair. A data class generates both from its constructor properties, so TeamSlot("qa", 3) is the same key anywhere. A plain class falls back to reference identity. Dart: the default is reference-based; for value semantics you must override operator == and hashCode TOGETHER. Writing only one is the classic mistake. In Dart 3 records (('qa', 3)`) give value equality for free. Finish by restating the rule that holds everywhere: a key must be immutable, otherwise the hash changes and the entry is lost.

Question 3

What happens if you override equals but forget hashCode?

Accepted Answer

Answer this one with the mechanism step by step, because the outcome is counter-intuitive at first sight. "The map looks at hashCode first to pick the bucket, and only then compares with equals inside that bucket. If hashCode was not overridden, the default implementation is identity-based — two objects that consider themselves equal get different hashes and land in different buckets. So equals is never called: map.containsKey(equalObject) returns false, and a set happily stores two copies of the same logical value." Then state the contract: equal objects must have equal hash codes; the converse is not required (different objects may share a hash — that is just a collision). Give the practical fix too: a data class in Kotlin, IDE generation or a record in Java, writing both together with Object.hash(...) in Dart (or using equatable/freezed). This detail moves the answer from "knows it" to "has hit it in real work".

Question 4

In JavaScript, when can a plain object ({}) not stand in for a Map?

Accepted Answer

Give the reasons as a list, one sentence each: Key types: an object can only have string and symbol keys. obj[1] silently becomes obj["1"], and obj[someObject] becomes "[object Object]" — so all object keys overwrite each other. Map accepts any type. Prototype: an object inherits from Object.prototype, so "toString" in obj is true even if you added nothing, and keys like __proto__ or constructor create prototype pollution risk. A Map starts clean. Size: Object.keys(obj).length collects every key — O(n); map.size is O(1). Performance: Map is optimised for frequent insert/delete; an object's hidden classes degrade under a churning key set. Then the decision rule: "If the keys are known and fixed up front — config, a DTO — a plain object is completely fine. If the keys arrive at runtime, especially from user data — Map." Add one important exception: JSON serialisation. JSON.stringify(map) yields {}, so returning an API response requires Object.fromEntries(map). That small detail signals practical experience.

Question 5

Can you rely on a map's iteration order?

Accepted Answer

The key to this answer is that "it depends" is not enough — you must name what each structure actually guarantees. JS Map/Set: insertion order is guaranteed by the spec. You can rely on it. Kotlin HashMap: no order guarantee at all; order can shift with version, capacity, even insertion sequence. LinkedHashMap gives insertion order, TreeMap/sortedMapOf give the keys' natural order. Note: Kotlin's mapOf() actually returns a LinkedHashMap — a frequent point of confusion. Dart: the {} literal and the Map() constructor create a LinkedHashMap, so insertion order is preserved. HashMap is explicitly unordered; for sorted keys use SplayTreeMap. Then give the practical conclusion, which is what the interviewer really wants to hear: "If order is a product requirement I do not leave it to behaviour that happens to work: I either choose a structure that guarantees it, or sort explicitly at the output. And in tests, order-dependent assertions are a classic cause of flaky tests."

Question	JavaScript	Kotlin	Dart
How do you get a value-based key?	By building a string key by hand	`data class` — automatic	Override `==` + `hashCode`, or a Dart 3 record
Iteration order	`Map`/`Set` preserve insertion order (guaranteed)	`HashMap` — none; `LinkedHashMap` — insertion; `TreeMap` — sorted	The `{}` literal is a `LinkedHashMap` — insertion order; `HashMap` — none
If you need keys in sorted order	No built-in — extract the keys and `sort`	`sortedMapOf` / `java.util.TreeMap`	`SplayTreeMap` (`dart:collection`)
Size	`map.size`	`map.size`	`map.length`

Set and Map usage patterns

📚 Sources and documentation