You need to group or count an array of objects by a key using reduce. How do you design the accumulator, and what is wrong with returning { ...acc, [key]: value } from the reducer?

## The shape of the fold Grouping and counting are the two most common non-arithmetic uses of `reduce`, and both hinge on the same idea: the initial value creates a container, and each step folds one element into it. ```js // group const byDept = people.reduce((acc, p) => { (acc[p.dept] ||= []).push(p); return acc; }, {}); // count const counts = words.reduce((acc, w) => { acc[w] = (acc[w] || 0) + 1; return acc; }, {}); ``` Both are single passes with constant work per element. ## Why mutating the accumulator here is correct Functional style discourages mutation because shared state is what makes code hard to reason about. That argument does not apply to the object created by `reduce`'s initial value: it was allocated by this call, no other code holds a reference to it until the fold finishes, and it is not the input. Mutating it is a *local* mutation inside an otherwise pure function — the fold as a whole still takes an array and returns a new value, leaving the source untouched. What would be wrong is mutating something you were handed: pushing into an array that lives in outer scope, or writing to a property of the elements. Keep the distinction sharp in an interview; candidates who say "never mutate in a reducer" usually cannot explain which object they mean. ## The spread anti-pattern ```js // looks purer, behaves badly const lookup = items.reduce((acc, x) => ({ ...acc, [x.id]: x }), {}); ``` Each iteration builds a **new** object and copies every key accumulated so far. Over `n` distinct keys that is roughly `n * n / 2` property copies plus `n` short-lived objects for the garbage collector, versus `n` assignments for the mutating version. On a few dozen items nobody notices; on a few tens of thousands it is the difference between milliseconds and seconds, and it shows up in a profile as time spent in object allocation. The usual defence — "it is immutable, so it is safer" — does not hold: the intermediate objects are unreachable the instant the next one is built, so the immutability buys nothing that mutating a private accumulator does not already give you. The same reasoning applies to `[...acc, x]` inside a reducer, which is the array-shaped version of the same mistake. ## Always return the accumulator ```js items.reduce((acc, x) => { acc[x.id] = x; }, {}); // TypeError on the second element ``` A braced arrow body with no `return` yields `undefined`, which becomes the accumulator for the next call — so `acc[x.id] = x` throws `TypeError: Cannot set properties of undefined`. With a one-element array it does not even throw; it silently returns `undefined`. Two habits avoid it: use the comma-operator form `(acc[x.id] = x, acc)` if you like terse reducers, or always write the explicit `return acc`. ## Choosing the container A plain object literal is not a clean dictionary. Its keys are coerced to strings, it inherits from `Object.prototype` so `acc['toString']` is truthy before you ever wrote to it, and assigning the key `'__proto__'` on a plain object goes through the inherited setter rather than creating an own property. When the keys come from user or network data, prefer: ```js const safe = items.reduce((acc, x) => { (acc[x.k] ||= []).push(x); return acc; }, Object.create(null)); const asMap = items.reduce((acc, x) => acc.set(x.k, [...(acc.get(x.k) || []), x]), new Map()); ``` `Object.create(null)` gives a prototype-less object; a `Map` additionally preserves non-string keys and insertion order and reports its size directly. ## Do you even need reduce? Since **ES2024** the language has the operation built in: ```js Object.groupBy(people, p => p.dept); // null-prototype object of arrays Map.groupBy(people, p => p.dept); // Map, keys may be objects ``` Where your runtime supports it, that is clearer than any hand-rolled reduce and gets the prototype question right by construction. And when the fold is doing nothing an ordinary loop would not do more legibly, a plain accumulation loop is a perfectly professional answer — `reduce` earns its place when the fold is the point, not when it is a disguise for a loop. ## What a strong answer sounds like Name the private-accumulator argument for mutating in place, quantify the spread version's cost, mention the missing-`return` trap, and note the prototype hazard with a plain object — then say you would reach for `Object.groupBy` where it is available.