MediumDSAAsked in 20245 min read

Index By Utility

Q: Index By Utility

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the safety claim is verified precisely. A naive `{}` accumulator given a key of `"__proto__"` was shown to swallow the item and hijack the RESULT object's own prototype (own keys empty, the item's fields readable by inheritance) — while the global `Object.prototype` stayed clean. A null-prototype result was verified to store that key as an ordinary own property. ## 1. The problem, restated Turn a list into a lookup table: `result[keyOf(item)] = item`. The interesting part is what happens when keys repeat, and when a key is a name that a plain object treats specially. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Duplicate keys? | Last-wins is the default of most libraries, but silently discarding data is a decision. Offer first-wins and throw modes. | | Untrusted keys? | Data from an API can con

3.2k views

59 of 154

The problem

Problem, as an interviewer would state it: "Implement indexBy(array, key) — converting an array into an object keyed by a property (or by a function's result) for O(1) lookup, with sensible handling for duplicate keys and for hostile keys such as __proto__."

Examples:

Code

indexBy([{ id: 1, n: "a" }, { id: 2, n: "b" }], "id");
// { 1: { id: 1, n: "a" }, 2: { id: 2, n: "b" } }

Clarifying questions expected:

When two items produce the same key, should the first or last win — or should it be an error?
Is the key property guaranteed to be safe, or could it come from untrusted data?
Should a function be accepted as well as a property name?

Code / implementation expected: Yes — real, direct proof of each collision mode and of the prototype-safety behavior.

array
object

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 safety claim is verified precisely. A naive {} accumulator given a key of "__proto__" was shown to swallow the item and hijack the RESULT object's own prototype (own keys empty, the item's fields readable by inheritance) — while the global Object.prototype stayed clean. A null-prototype result was verified to store that key as an ordinary own property.

1. The problem, restated

Turn a list into a lookup table: result[keyOf(item)] = item. The interesting part is what happens when keys repeat, and when a key is a name that a plain object treats specially.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Duplicate keys?	Last-wins is the default of most libraries, but silently discarding

The solution is hidden so you can try first

5 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: indexBy collision modes work, and a __proto__ key is safe on a null-prototype result but hijacks the prototype of a plain object result

Practice

Discussion

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

No comments yet. Share how you would answer it.

Question 59 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→

Build an Async Priority Task Scheduler

Continue