JavaScript Memoization Interview Questions

What memoization actually is

Memoization is an optimization technique that caches the return value of a function based on its input arguments. The word comes from "memorandum" — a note to remember something by. On the first call with a given set of arguments, the function runs normally and stores the result in a cache. On every subsequent call with the same arguments, the cached result is returned without executing the function body at all.

Memoization is only valid for pure functions — functions that always return the same output for the same input and produce no side effects. A function that reads from a database, generates random numbers, or depends on the current timestamp cannot be safely memoized because the same input could produce different results at different times.

The simplest memoization implementation

A basic memoize function wraps another function and uses a closure to maintain a cache object between calls. The cache lives inside the closure — it persists across invocations without polluting the outer scope.

function memoize(fn) {
  const cache = {}

  return function(...args) {
    const key = JSON.stringify(args)

    if (key in cache) {
      return cache[key]       // cache hit — skip computation
    }

    const result = fn(...args)
    cache[key] = result       // cache miss — compute and store
    return result
  }
}

function slowSquare(n) {
  // Simulate expensive computation
  for (let i = 0; i < 1e8; i++) {}
  return n * n
}

const fastSquare = memoize(slowSquare)

fastSquare(12)   // slow — runs computation, caches result
fastSquare(12)   // instant — returns cached 144
fastSquare(12)   // instant
fastSquare(7)    // slow — new input, runs computation, caches 49
fastSquare(7)    // instant

The closure keeps cache alive between calls. Each unique combination of arguments gets one cache entry. The cache persists for the entire lifetime of the memoized function reference.

The cache key problem — three ways JSON.stringify fails

The cache key must uniquely and consistently identify a set of arguments. JSON.stringify(args) covers the common cases but has three real limitations that interviewers specifically probe.

Problem 1 — Object property order is significant to JSON.stringify:

JSON.stringify({ a: 1, b: 2 })   // '{"a":1,"b":2}'
JSON.stringify({ b: 2, a: 1 })   // '{"b":2,"a":1}'  ← different key!

// These produce different cache keys despite being semantically identical
memoized({ a: 1, b: 2 })   // cache miss — computes and stores
memoized({ b: 2, a: 1 })   // cache miss — computes again (wrong)

Problem 2 — Functions and Symbols are silently dropped:

JSON.stringify({ fn: () => {} })   // '{}'  — function omitted
JSON.stringify({ id: Symbol() })   // '{}'  — Symbol omitted

// Two completely different function arguments produce the same key '{}'
// Cache returns the first result for all subsequent calls — incorrect

Problem 3 — Circular references throw immediately:

const obj = {}
obj.self = obj
JSON.stringify(obj)   // TypeError: Converting circular structure to JSON

The fix is to make the key strategy configurable and fall back to a custom resolver for non-serializable arguments:

function memoize(fn, getKey = (...args) => JSON.stringify(args)) {
  const cache = new Map()
  return function(...args) {
    const key = getKey(...args)
    if (cache.has(key)) return cache.get(key)
    const result = fn(...args)
    cache.set(key, result)
    return result
  }
}

// Custom key for user objects: use a stable unique identifier
const getUser = memoize(fetchUser, (id, options) => `${id}:${options.role}`)

// Custom key for DOM elements: use WeakMap (see next section)

WeakMap pattern — memoizing object arguments without memory leaks

When a function receives an object and the question is identity (same reference = same result), a WeakMap is the correct backing store. Unlike a plain object or Map, WeakMap does not prevent its keys from being garbage collected. When the object is no longer referenced elsewhere in the application, its cache entry disappears automatically.

function memoizeWithObject(fn) {
  const cache = new WeakMap()

  return function(obj) {
    if (cache.has(obj)) {
      return cache.get(obj)     // cache hit
    }
    const result = fn(obj)
    cache.set(obj, result)      // weak reference — no GC prevention
    return result
  }
}

const analyzeLayout = memoizeWithObject((el) => {
  // Expensive DOM measurement
  return el.getBoundingClientRect()
})

const btn = document.getElementById('submit')
analyzeLayout(btn)   // computes and caches
analyzeLayout(btn)   // instant — same reference

// If btn is later removed from DOM and the reference dropped,
// the WeakMap entry is garbage collected automatically — no leak

Memoizing recursive functions — the fibonacci pattern

Memoization has its most dramatic impact on recursive functions with overlapping subproblems. The naive recursive Fibonacci recomputes the same values exponentially — fib(50) makes over two billion calls. Memoization reduces this to 51 unique computations.

// Naive recursive — O(2^n) time
function fib(n) {
  if (n <= 1) return n
  return fib(n - 1) + fib(n - 2)
}

fib(40)   // ~200 million calls — takes seconds
fib(50)   // ~2 billion calls — effectively hangs

// Memoized — O(n) time
function memoize(fn) {
  const cache = new Map()
  return function(n) {
    if (cache.has(n)) return cache.get(n)
    const result = fn(n)
    cache.set(n, result)
    return result
  }
}

// CRITICAL: reassign fib so the recursive calls use the memoized version
const fib = memoize(function(n) {
  if (n <= 1) return n
  return fib(n - 1) + fib(n - 2)   // calls memoized fib — cache hit every time
})

fib(50)    // instant — 51 unique subproblems, all others from cache
fib(100)   // instant

The most common mistake: the inner recursive call must reference the memoized version. If the function references the original pre-memoization name, inner calls bypass the cache entirely and only the outermost call is memoized.

LRU cache — bounded memoization for production

An unbounded cache is a memory leak — every unique argument set adds a permanent entry that is never evicted. In production, always bound the cache size. A Least Recently Used (LRU) cache discards the entry accessed least recently when the cache reaches its capacity.

class LRUCache {
  constructor(capacity) {
    this.capacity = capacity
    this.cache    = new Map()   // Map preserves insertion order — key to LRU
  }

  get(key) {
    if (!this.cache.has(key)) return undefined
    // Refresh access order: delete then re-insert moves key to end (most recent)
    const value = this.cache.get(key)
    this.cache.delete(key)
    this.cache.set(key, value)
    return value
  }

  set(key, value) {
    if (this.cache.has(key)) {
      this.cache.delete(key)     // remove to refresh position
    } else if (this.cache.size >= this.capacity) {
      // First entry = least recently used — delete it
      this.cache.delete(this.cache.keys().next().value)
    }
    this.cache.set(key, value)
  }
}

function memoizeWithLRU(fn, capacity = 100) {
  const lru = new LRUCache(capacity)
  return function(...args) {
    const key    = JSON.stringify(args)
    const cached = lru.get(key)
    if (cached !== undefined) return cached
    const result = fn(...args)
    lru.set(key, result)
    return result
  }
}

Map's guaranteed insertion order is what makes this implementation clean — the first entry is always the least recently used. This pattern is one of the most common standalone coding interview questions at senior level.

Memoization with TTL — for data that expires

Some functions are pure over a short window but not indefinitely — API responses, configuration reads, computed positions. A TTL (time-to-live) cache serves results within the valid window and recomputes after expiry.

function memoizeWithTTL(fn, ttlMs = 60_000) {
  const cache = new Map()   // key → { value, expiresAt }

  return function(...args) {
    const key   = JSON.stringify(args)
    const entry = cache.get(key)

    if (entry && Date.now() < entry.expiresAt) {
      return entry.value    // still valid
    }

    const value = fn(...args)
    cache.set(key, { value, expiresAt: Date.now() + ttlMs })
    return value
  }
}

// Caches for 5 minutes, then recomputes on the next call
const getConfig = memoizeWithTTL(fetchRemoteConfig, 5 * 60 * 1000)

useMemo and useCallback in React

React's memoization hooks apply the same principle inside the component lifecycle. They cache values between renders and recompute only when specified dependencies change.

import { useMemo, useCallback, memo } from 'react'

function ProductList({ products, filters, onSelect }) {

  // useMemo — caches the computed value
  // Only recomputes when products or filters changes
  const filtered = useMemo(() => {
    return products
      .filter(p => p.category === filters.category)
      .filter(p => p.price <= filters.maxPrice)
      .sort((a, b) => a.price - b.price)
  }, [products, filters])

  // useCallback — caches the function reference
  // Without this, a new function object is created each render,
  // causing MemoizedCard below to re-render even when nothing changed
  const handleSelect = useCallback((id) => {
    onSelect(id)
  }, [onSelect])

  return filtered.map(p =>
    <MemoizedCard key={p.id} product={p} onSelect={handleSelect} />
  )
}

// memo wraps a component so it only re-renders when props change
// Only effective when all props are stable references — hence useCallback above
const MemoizedCard = memo(function Card({ product, onSelect }) {
  return <div onClick={() => onSelect(product.id)}>{product.name}</div>
})

The costly mistake: memoizing cheap computations or non-referentially-sensitive values. useMemo and useCallback run on every render to compare dependencies. For a simple addition or string concatenation, this check costs more than just recomputing. Apply them selectively — only when the computation is genuinely expensive, or when a stable reference prevents a memoized child from re-rendering.

When NOT to memoize

Memoization is a performance tool, not a default. The overhead of cache lookup and key generation exceeds the savings in these four cases:

// 1. Cheap functions — cache overhead exceeds computation cost
const add = memoize((a, b) => a + b)    // slower than a + b directly

// 2. Impure functions — returns incorrect cached results
const getTime = memoize(() => Date.now())   // always returns first cached timestamp

// 3. Unique inputs — cache grows forever, never hits
const processId = memoize(id => transform(id))   // if every id is unique, 0% cache hits

// 4. Large object arguments with JSON.stringify
// Serializing a 5,000-key object on every call is slower than recomputing