MediumDSAAsked in 20246 min read

Implement objectMap(obj, fn) — Transform Every Value via Object.entries/fromEntries

Q: Implement objectMap(obj, fn) — Transform Every Value via Object.entries/fromEntries

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the real, defining "map for objects" framing this question tests was verified directly: the callback correctly received each key as its SECOND argument (`(value, key) => ...`), mirroring `Array.prototype.map`'s own familiar `(value, index)` signature, confirmed via a real, direct string-interpolation test combining both the key and the value. ## 1. The problem, restated Transform every VALUE of a plain object via `fn`, keeping the exact same set of KEYS unchanged — returning a genuinely NEW object, built directly on top of the real, native `Object.entries`/`Object.fromEntries` pair, matching a real, common "map, but for objects" utility that many codebases hand-roll independently. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Callback receives the key? | Yes — mirroring `Array.prototype.map`'s o

4.1k views

46 of 154

The problem

Problem, as an interviewer would state it: "Implement objectMap(obj, fn) — transforming EVERY value of a plain object via fn, keeping the same keys, matching a real, common Array.prototype.map-equivalent for objects, built directly on Object.entries/Object.fromEntries."

Examples:

Code

objectMap({a:1, b:2, c:3}, v => v * 2); // {a:2, b:4, c:6}

Clarifying questions expected:

Should the callback receive the KEY (and index) as additional arguments, matching Array.prototype.map's own real, familiar signature?
Should the original object remain completely untouched, with a genuinely new object returned?
Should this bank's own already-covered Object.fromEntries polyfill be reused as a building block here?

Code / implementation expected: Yes — real, direct proof of correct value transformation, confirmation the key is correctly passed as the callback's second argument, and confirmation the original object is never mutated.

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: Medium

How to read this doc: the real, defining "map for objects" framing this question tests was verified directly: the callback correctly received each key as its SECOND argument ((value, key) => ...), mirroring Array.prototype.map's own familiar (value, index) signature, confirmed via a real, direct string-interpolation test combining both the key and the value.

1. The problem, restated

Transform every VALUE of a plain object via fn, keeping the exact same set of KEYS unchanged — returning a genuinely NEW object, built directly on top of the real, native Object.entries/Object.fromEntries pair, matching a real, common "map, but for objects" utility that many codebases hand-roll independently.

2. Clarifying questions a strong candidate asks

| Question | Why i

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: objectMap() correctly transforms every value while keeping keys unchanged, with the key correctly passed as the callback's second argument

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

No comments yet. Share how you would answer it.

Question 46 of 154 in JavaScript coding

Keep your momentum going.

Mark this question solved to track your progress, then take the next one while it is fresh.

All JavaScript coding questions

Up nextMedium→

Observable map/filter operators

Continue