When should you use Map and Set over objects and arrays?

Q: When should you use Map and Set over objects and arrays?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every coercion and dedup claim below was actually run in Node. ## 1. Why This Even Matters — A Story First A plain object's keys are like index cards in a box that only accepts cards labeled with PLAIN TEXT — hand it an actual physical object instead of a label, and the box's intake clerk just writes a generic, identical description ("an object") on the card for EVERY such object, no matter how different they actually are. A `Map` is a box that genuinely accepts the physical objects themselves as index tabs — two different objects are always two different, distinguishable tabs, no matter what they "look like." ## 2. The Core Idea 📌 **Interview term:** a `Map` accepts any value, including an object, as a genuinely distinct key with no coercion — while a p

The problem

Question presented to candidate: "If you use an object as a key on a plain JavaScript object, like obj[someObject] = value, what actually happens to that key? Would a Map handle it differently?"

What a strong answer should cover:

📌 Interview term: object key coercion — verified directly: using an object as a key on a plain {} genuinely coerces it to the literal string "[object Object]" — every distinct object used as a key this way collides on the exact same string, a real, silent data-corruption bug.
📌 Interview term: Map's real, direct answer to the prompt — verified directly: a Map genuinely accepts the object itself, with no coercion at all, as a real, distinct key — two different object references are genuinely two different, non-colliding keys.
📌 Interview term: Map has a real, direct .size — verified directly: unlike a plain object (which requires Object.keys(obj).length to count entries), a Map genuinely has a real .size property, always accurate.
📌 Interview term: Set dedupes while keeping type-DISTINCT values separate — verified directly: a Set built from [1, "1", 1, 2, 2] genuinely keeps both the number 1 and the string "1" as two SEPARATE entries (using SameValueZero comparison, the same algorithm covered in this bank's own includes vs. indexOf question), while still correctly removing the genuine duplicate 1s and 2s.
A precise answer names that Map/Set also genuinely guarantee real insertion-order iteration (a formal spec guarantee, not just an implementation detail) and are directly iterable via for...of — while a plain object/array can be used similarly in PRACTICE for simple cases, but without the same formal guarantees or capabilities (arbitrary key types, guaranteed size, no prototype-pollution risk from inherited properties).

Clarifying questions expected:

None — this is a definitional/comparison question; directly answering the prompt's object-key coercion scenario (and Map's real fix) is the strong signal.

Code / implementation expected: Yes — the side-by-side object-key-coercion vs. Map-object-key test is the clearest, most convincing demonstration.

map
set

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every coercion and dedup claim below was actually run in Node.

1. Why This Even Matters — A Story First

A plain object's keys are like index cards in a box that only accepts cards labeled with PLAIN TEXT — hand it an actual physical object instead of a label, and the box's intake clerk just writes a generic, identical description ("an object") on the card for EVERY such object, no matter how different they actually are. A Map is a box that genuinely accepts the physical objects themselves as index tabs — two different objects are always two different, distinguishable tabs, no matter what they "look like."

2. The Core Idea

📌 Interview term: a Map accepts a

The solution is hidden so you can try first

6 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal proof: a plain object coerces an object key to '[object Object]' (a real collision bug) while Map genuinely accepts it as a distinct key