MediumFrontend6 min read

Implement memoize() with custom resolver and cache limit

Q: Implement memoize() with custom resolver and cache limit

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the eviction claim — that exceeding `maxSize` genuinely forces a real recomputation on the next access to the evicted key — was verified directly with a real call counter, not just reasoned about from the `Map` insertion-order behavior. ## 1. The problem, restated `memoize(fn, { resolver, maxSize })` returns a wrapped function that caches `fn`'s results by a computed key — defaulting to all arguments, or using `resolver(...args)` if given — and evicts the oldest (or least-recently-used) entry once the cache exceeds `maxSize`. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Default key with no resolver? | A real, common choice is `JSON.stringify(args)` — worth naming its own real limitation (fails for functions/circular args). | | LRU or strict insertion-order eviction? | LRU (refreshing recency on

607 views

108 of 154

The problem

Problem, as an interviewer would state it: "Implement memoize(fn, options) — cache the result of a call so repeated calls with the same arguments skip real recomputation. Support a custom resolver function for computing the cache key, and a maxSize that evicts the oldest entry once exceeded."

Examples:

Code

const memoSquare = memoize(expensiveSquare);
memoSquare(5); // real computation
memoSquare(5); // cached, no real computation

Clarifying questions expected:

If no resolver is given, how should the default cache key be computed for multiple arguments?
On maxSize eviction, is it always the LEAST RECENTLY USED entry that goes, or strictly the oldest by insertion?
Should accessing a cached entry refresh its recency for eviction purposes?

Code / implementation expected: Yes — real, direct proof of plain caching, a custom resolver ignoring an argument, and maxSize eviction genuinely forcing a real recomputation.

memoize
cache
closure

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 eviction claim — that exceeding maxSize genuinely forces a real recomputation on the next access to the evicted key — was verified directly with a real call counter, not just reasoned about from the Map insertion-order behavior.

1. The problem, restated

memoize(fn, { resolver, maxSize }) returns a wrapped function that caches fn's results by a computed key — defaulting to all arguments, or using resolver(...args) if given — and evicts the oldest (or least-recently-used) entry once the cache exceeds maxSize.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Default key with no resolver?	A real, common choice is `JSON.stringify(args)` — worth naming its own real limitation (fails fo

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: memoize() caches correctly, a custom resolver correctly ignores an unconsidered argument, and maxSize eviction forces a real recomputation

Practice

Discussion

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

No comments yet. Share how you would answer it.

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

Deep Freeze Object

Continue