You are asked to write a general-purpose `memoize(fn)` wrapper for a production codebase. How do you build the cache key, and what makes memoization unsafe for a given function?

## The naive version, and why it is only a starting point ```js function memoize(fn) { const cache = new Map(); return (arg) => { if (cache.has(arg)) return cache.get(arg); const value = fn(arg); cache.set(arg, value); return value; }; } ``` This is correct for one argument that is a primitive, and it already shows the two habits worth having: use `Map` rather than a plain object (a `Map` accepts any key type and cannot collide with inherited property names), and use `has` rather than a truthiness check, so a legitimately cached `undefined`, `0`, `''` or `null` is not recomputed forever. `Map` keys compare with SameValueZero, so `NaN` works as a key, and `0` and `-0` are the same key. Object arguments compare by identity, which is exactly right when callers reuse the same object and exactly useless when they build a fresh equivalent one per call. ## Building keys for several arguments There is no universally correct key function, which is why a good answer refuses to pretend otherwise. The common shortcut has three named failure modes: ```js const key = JSON.stringify(args); ``` - **Collisions.** `JSON.stringify([{a: undefined}])` and `JSON.stringify([{}])` are both `"[{}]"`, so two different calls share a cache entry and one gets the other's answer. Functions and `undefined` values vanish the same way, and a `Date` serialises to the same string as the equivalent ISO string. - **Misses.** Property order is preserved in the output, so `{a: 1, b: 2}` and `{b: 2, a: 1}` produce different keys for equal inputs — a silent cache miss that makes the memo look useless under load. - **Failures.** A cyclic structure throws `TypeError`, and `BigInt` throws too. A cache layer that can crash the call it was meant to speed up is a poor trade. So make the key function a parameter — `memoize(fn, keyFor)` — and let each call site pick. When arguments are a small fixed set of primitives, a delimiter join is faster and safer than `JSON.stringify`. When the argument is an object the caller holds onto, a `WeakMap` keyed on the object avoids serialisation entirely and lets the entry disappear when the object does. When arguments have a natural identifier — a user id, a URL — key on that and nothing else. ```js function memoize(fn, keyFor = (args) => args[0]) { const cache = new Map(); return (...args) => { const k = keyFor(args); if (cache.has(k)) return cache.get(k); const value = fn(...args); cache.set(k, value); return value; }; } ``` ## When memoization is unsafe Caching is only sound when `fn` is a *function* in the mathematical sense: same inputs, same output, no observable effects. Concretely, do not memoize when: - **The result depends on state outside the arguments** — a mutable module variable, the current time, a random value, a database. The cache freezes a snapshot and the code starts reporting stale answers with no error anywhere. - **The function has side effects worth repeating** — logging, incrementing a counter, writing to storage. Memoizing silently deletes those effects from every call after the first. - **The returned value is mutable and callers mutate it.** Every caller receives the same object reference, so one caller's mutation is visible to all the others. Either return a defensive copy or freeze the value. ## Bounding and lifetime A `Map`-backed cache in a long-lived process never shrinks. If the key space is small and closed (thirty locale codes, ten configuration names) that is fine and simple. If it is open — user ids, arbitrary URLs, search strings — the cache is an unbounded retention of every value ever computed, and the process dies eventually. Add a cap with an eviction policy (an LRU is the standard choice; a `Map` iterates in insertion order, which makes a crude LRU easy to write), or a time-to-live if freshness matters more than hit rate. `WeakMap` gives you collection for free but only when the key is the object whose lifetime should govern the entry. ## Errors and promises Decide explicitly what a thrown error does. The default in the code above is that nothing is cached — the `set` never runs, so the next call retries. That is usually right. For an async function, the value you cache is the promise, which means a rejection is cached too and every later caller receives the same failed promise. If retry is wanted, delete the entry when the promise rejects. ## What the interviewer is checking Not whether you can write a `Map` lookup — everyone can. They want to hear you interrogate the *function* before wrapping it, name a concrete key-collision case, and volunteer the unbounded-growth problem before being prompted. "It depends on the key function, and here is the one I would use for these arguments" is the answer that lands.