Polyfill Object.fromEntries() — Handle Duplicate and Symbol Keys

Q: Polyfill Object.fromEntries() — Handle Duplicate and Symbol Keys

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** the real, defining relationship this question tests — that `Object.fromEntries` is genuinely the documented INVERSE of `Object.entries` — was verified directly: a real object passed through `Object.entries` and then back through this polyfill produced the exact original object back, confirmed via a real deep-equality check. ## 1. The problem, restated Convert any real ITERABLE of `[key, value]` pairs (a plain array of pairs, a real `Map`, a generator yielding pairs) into a genuine plain object — with a LATER entry for the same key correctly overwriting an earlier one, and both string and Symbol keys correctly preserved — matching real native `Object.fromEntries`'s own complete, documented contract. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Last entry wins on a duplicate key? | Yes — real nativ

Create object from key-value pairs | JS Coding Challenge

The problem

Problem, as an interviewer would state it: "Implement Object.fromEntries from scratch — converting an iterable of [key, value] pairs back into a plain object, matching real native Object.fromEntries's own documented contract, including its real, defining relationship with Object.entries."

Examples:

Code

Object.fromEntries([["a", 1], ["b", 2]]); // {a: 1, b: 2}
Object.fromEntries(new Map([["x", 10]])); // {x: 10}

Clarifying questions expected:

When the SAME key appears in multiple entries, does the LAST occurrence genuinely win, matching a real, predictable overwrite order?
Does this need to accept any real iterable of pairs (a Map, a generator), not just a plain array of arrays?
Should a Symbol used as a key be correctly preserved, not silently dropped or stringified?

Code / implementation expected: Yes — real, direct proof against the ACTUAL native Object.fromEntries, including duplicate-key overwrite order, a real Symbol key, a real Map input, and a real round trip through Object.entries.

js-coding
utility
algorithm

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 practical JavaScript coding interviews. Difficulty: Easy

How to read this doc: the real, defining relationship this question tests — that Object.fromEntries is genuinely the documented INVERSE of Object.entries — was verified directly: a real object passed through Object.entries and then back through this polyfill produced the exact original object back, confirmed via a real deep-equality check.

1. The problem, restated

Convert any real ITERABLE of [key, value] pairs (a plain array of pairs, a real Map, a generator yielding pairs) into a genuine plain object — with a LATER entry for the same key correctly overwriting an earlier one, and both string and Symbol keys correctly preserved — matching real native Object.fromEntries's own complete, documented contract.

2. Clarifying questions a strong candidate asks

|

The solution is hidden so you can try first

6 min read · 9 sections

Run the code

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

JavaScriptReal, direct proof: the Object.fromEntries polyfill matches real native output, including duplicate-key overwrite order, a real symbol key, and a real Map input