Question 1

How do you choose between a Map and a plain object in JavaScript?

Accepted Answer

Split the answer into three axes — that covers the question completely. Key types: an object coerces every key to a string or symbol, so obj[1] and obj['1'] are the same slot; a Map accepts any type as a key, objects and functions included, and keeps types distinct. Order and API: a Map guarantees insertion order, size is O(1), it iterates directly (for (const [k, v] of map)), and has/delete give a clean API. With an object, counting keys means Object.keys().length — O(n). Safety: an object inherits keys from the prototype chain — obj['toString'] returns something unexpected; a Map has no such problem. With externally supplied keys this is a genuine security concern. When I pick object: for configuration and data objects with fixed, known-ahead keys; when working directly with JSON (a Map doesn't serialise with JSON.stringify); when the literal syntax is more compact. When I pick Map: when keys are dynamic, when I need object keys, with frequent insertion/deletion, or when I track the size. Short summary: "Map as a data structure, object as a data object."

Question 2

What criteria guide your choice of collection? Explain with an example.

Accepted Answer

Say that you derive the choice from the access pattern, then list the criteria: Which operation happens most? Index access → List; lookup by key → Map; membership → Set; insertion/removal at the ends → Deque; removal by priority → a heap. Does order matter? Insertion order (LinkedHashMap, JS Map), sorted order (TreeMap, SplayTreeMap), or not at all (HashMap — slightly faster). How big is it? For 20 elements list.contains() is perfectly fine; for 100,000 a Set is mandatory. Is mutability needed? Kotlin's listOf vs mutableListOf expresses intent at the type level and prevents accidental mutation. Any memory constraints? Hash structures use more space than arrays; a fixed-capacity ring buffer gives guaranteed bounds. Give a concrete example — this is what brings the answer to life: "I had to join orders to users. The first version called users.find(...) per order — O(n × m). I built a Map<id, user> once and the whole thing became O(n + m); at 50,000 orders the runtime went from several seconds to milliseconds." End with the important nuance: keeping two structures at once is often the right answer — a map plus a doubly linked list for an LRU cache, an array plus an id → index map for a list that must be both ordered and searchable. That reads as maturity.

Question 3

How does a hash map work and why is it considered O(1)?

Accepted Answer

Describe the mechanism step by step: The key goes through a hash function producing a number That number is mapped to an index in the bucket array (hash % capacity, or a bit mask) The (key, value) pair is stored in that bucket On lookup the same computation runs and goes straight to the right bucket Why O(1): hashing takes constant time (proportional to key size, but independent of element count) and reaching the bucket is an array index. Lookup time doesn't grow as the map grows — that's what O(1) means. Collisions: two different keys landing in the same bucket. The fixes are chaining (a list or tree inside the bucket) and open addressing (probe to the next free slot). Because collisions are rare, the average stays O(1). Worst case O(n): when all keys land in one bucket — a poor hash function or deliberately crafted input (hash flooding). Modern implementations convert an oversized bucket into a balanced tree, capping this at O(log n); some also add a random seed to the hash. Load factor and rehashing: when the ratio of entries to buckets crosses a threshold (typically 0.75), the array doubles and every key is redistributed — that's O(n), but rare enough that insertion stays amortized O(1). The practical consequence — stating this completes the answer: a key's hashCode/equals pair must be correct and consistent (equal objects must hash equally), and keys must be immutable — otherwise the hash changes and the entry is lost.

Question 4

In an interview, may you use a built-in collection, or must you write it by hand?

Accepted Answer

The right move is to ask, then show both sides. First, clarify: "Would you like me to implement this structure by hand, or may I use the language's built-in type?" Asking that alone makes a good impression, because it shows you want to avoid wasted effort. Then act on the context: If the question is about the structure itself ("reverse a linked list", "implement a stack", "build an LRU cache") — the whole point is pointer manipulation and edge cases, so write it by hand. If the question is about an algorithm ("find two numbers summing to target", "shortest path with BFS") — use the built-in Map, Set, ArrayDeque. Hand-rolling a hash map here wastes time and distracts from the real problem. The strongest answer combines both: "In a real project I'd use ArrayDeque — it's a circular buffer and gives O(1) at both ends. But if you'd like me to show the internals, I can write it by hand." That demonstrates practical maturity and theoretical preparation at once. Whichever path you take, know the complexity of every collection you use — the interviewer will ask: "Why is Set.has() O(1)?", "What does shift() cost?". Using a built-in structure without knowing its price is the worst combination.

Question 5

What hidden collection-related performance problems have you run into?

Accepted Answer

Here concrete examples beat general reasoning by a wide margin. Give several typical ones in problem → cause → fix form. 1. A linear search inside a loop. orders.map(o => users.find(u => u.id === o.userId)) — O(n × m). Cause: find rescans the whole list on every call. Fix: build a Map once — O(n + m). This is the most common one by far. 2. shift()/removeAt(0) used as a dequeue. Every call is an O(n) shift, O(n²) overall. Fix: ArrayDeque, Queue, or a head index. 3. String concatenation in a loop. result += chunk — O(n²), because strings are immutable. Fix: StringBuilder/StringBuffer, or collect pieces and join. 4. Recomputing a lazy Iterable. Dart's map/where and Kotlin's Sequence are lazy; iterating the result several times redoes the work each time. Fix: materialise once with toList(). 5. Creating a new collection every iteration. [...arr, item] or list + item inside a loop — an O(n) copy each time, O(n²) overall. Fix: accumulate in a mutable structure and freeze at the end. 6. A bad hash key. A class without equals/hashCode used as a map key makes every object unique — the cache never hits and the map grows unbounded. Fix: a data class or a correct equals/hashCode. 7. Memory leaks. An uncleaned cache or collection grows forever. Fix: a size limit, LRU eviction, or a WeakMap. Close with methodology: "Most of these are invisible on small test data. So I measure with realistically sized data, and in code review I've made "what gets called inside this loop?" a habitual question."

Structure	JavaScript	Kotlin	Dart	What's inside
Dynamic array	`Array`	`List` / `MutableList` (`ArrayList`)	`List`	A contiguous buffer plus a length; O(1) index, amortized O(1) append
Hash map	`Map` (preserves insertion order) / a plain `object`	`HashMap`, `LinkedHashMap` (the default for `mapOf`)	`Map` (defaults to `LinkedHashMap`)	A hash table; get/put/delete O(1) average
Hash set	`Set`	`HashSet`, `LinkedHashSet` (the default for `setOf`)	`Set` (defaults to `LinkedHashSet`)	A hash table of keys only; `has` is O(1)
Deque / Queue	None — `Array` or hand-rolled	`ArrayDeque`	`Queue`, `ListQueue`, `DoubleLinkedQueue`	A circular buffer (or linked list); O(1) at both ends
Linked list	None	`java.util.LinkedList` (not recommended)	`LinkedList` (`dart:collection`)	Nodes plus pointers
Sorted map/set	None	`sortedMapOf`, `TreeMap` (JVM)	`SplayTreeMap`, `SplayTreeSet`	A balanced tree; O(log n) operations, order preserved
Weakly-referenced map	`WeakMap`, `WeakSet`	`WeakHashMap` (JVM)	`Expando`, `WeakReference`	The entry disappears when the key is collected — useful for caches

Built-in collections by language

📚 Sources and documentation