Lesson 17 of 80

Memoization

Q: Implement a memoize function and explain when it's safe to use.

A strong answer covers: A closure-based cache (Map or object) keyed by argument(s), returning the cached result on a repeat call instead of recomputing; Only correct for pure functions — same input must always produce the same output; Awareness of cache growth/memory tradeoffs and the need for a composite key with multiple arguments.

Caching a function's results by its arguments, so calling it again with the same input skips the work entirely — a closure holding a cache instead of a timer.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

Why is memoization only safe for pure functions?

Because a cached result is reused for any input seen before, which is only correct if output depends solely on inputImpure functions run too fast to benefit from cachingJavaScript's Map can't store values from impure functions

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Memoization

What interviewers actually ask about this, and what a strong answer has to cover.

Implement a memoize function and explain when it's safe to use.

A strong answer covers

A closure-based cache (Map or object) keyed by argument(s), returning the cached result on a repeat call instead of recomputing
Only correct for pure functions — same input must always produce the same output
Awareness of cache growth/memory tradeoffs and the need for a composite key with multiple arguments

Likely follow-ups

How would you memoize a function that takes multiple arguments?
How does this relate to React's useMemo and useCallback?
What happens to your cache if the wrapped function's inputs are objects instead of primitives — does Map.has still work the way you'd expect?

Practice these with the AI interviewer →

The plain-language idea

Memoization wraps a function with a cache: before running the real work, check if this exact input was seen before. If yes, return the stored answer. If no, compute it, store it, then return it.

function memoize(fn) {
  const cache = new Map();       // lives in the closure, one per wrapped function
  return function (arg) {
    if (cache.has(arg)) return cache.get(arg);
    const result = fn(arg);
    cache.set(arg, result);
    return result;
  };
}

const slowSquare = (n) => { /* expensive work */ return n * n; };
const fastSquare = memoize(slowSquare);
fastSquare(5); // computes, caches
fastSquare(5); // returns cached instantly, doesn't call slowSquare again

This is the exact same shape as debounce: a function returns another function that closes over some private state (there, a timer; here, a cache) that survives between calls.

Memoization: a cache keyed by the argumentStep 1 of 3

fastSquare(5) — not in the cache yet. Compute it the slow way, then store the result.

What people usually miss

Watch out

It trades memory for speed. An unbounded cache on a function called with many unique inputs can leak memory — real implementations often cap cache size or use a WeakMap when the key is an object, so entries can be garbage-collected.
Multi-argument functions need a composite key. A Map keyed on one argument doesn't work for fn(a, b) — you typically serialize the arguments (JSON.stringify([a, b])) or nest maps.
React's useMemo/useCallback are this exact idea, applied to a component's renders instead of a plain function's calls — "skip recomputation if the inputs haven't changed."

Why this matters in interviews

Memoized Fibonacci ("naive recursive fib is exponential, memoized fib is linear") is a classic exercise that checks whether you can connect closures, recursion, and time-complexity reasoning in one answer.