Both React.memo and useMemo are described as memoization in React, and candidates often use the names interchangeably. What does each one actually cache, and when would you reach for one rather than the other?

## Two different units of caching The word "memoization" hides the important difference: **what is being cached**. `React.memo(Component)` caches a *rendered result*. It returns a wrapper component. When the parent re-renders and would normally re-render this child, React compares the new props with the old ones, shallowly, with `Object.is` per key. If they are all equal, React does not call the component function and reuses the element tree from last time. Everything below that component is skipped along with it. `useMemo(fn, deps)` caches a *value inside one render*. The component is already rendering — React is executing its body right now. When execution reaches the `useMemo` call, React compares the dependency array with the one from the previous render, again with `Object.is` per element. If nothing changed, it returns the stored value and does not call `fn`. If something changed, it calls `fn` and stores the new result. So the honest one-liner is: `React.memo` can stop a render from happening; `useMemo` only makes a render that is happening cost less. ## The two reasons to reach for useMemo **Skipping expensive work.** If the render computes something genuinely costly — sorting or grouping thousands of rows, building an index, parsing a large payload — and the inputs rarely change, `useMemo` skips that work on the renders where the inputs did not move. ```jsx const sorted = useMemo( () => rows.slice().sort((a, b) => a.name.localeCompare(b.name)), [rows] ); ``` **Preserving reference identity.** This is the reason people underrate. A value produced by `useMemo` keeps the same reference across renders while its dependencies hold still. That matters when the value is handed to something that compares by identity: a child wrapped in `React.memo`, or another hook's dependency array. Here the computation may be trivial and `useMemo` still earns its place, because the *identity* is the product, not the speed. ## How they compose The classic pairing: ```jsx const config = useMemo(() => ({ locale, currency }), [locale, currency]); return <PriceTable config={config} />; // PriceTable is wrapped in React.memo ``` Without the `useMemo`, `config` is a new object literal every render, `PriceTable`'s props comparison always fails, and the `React.memo` wrapper is pure overhead — a comparison that can never succeed. Adding `React.memo` to a child while leaving object props inline is one of the most common ways teams convince themselves they optimized something. The reverse is also true: `useMemo` on the parent with an unmemoized child buys nothing on the render path, because the child re-renders regardless of whether its props kept identity. ## When each one is the wrong tool Use `React.memo` when a component re-renders often with unchanged inputs *and* rendering it is not trivial. On a component that emits a few DOM nodes from primitive props, the props comparison costs roughly what the render costs, so you have added code and gained nothing measurable. Use `useMemo` when the computation is expensive or the identity is consumed by an equality check. On `useMemo(() => a + b, [a, b])` the machinery — allocating the closure, allocating the array, comparing the dependencies — is at least as expensive as the addition it avoids. ## The interview trap A frequent probe: "you wrapped the child in `React.memo` but it still re-renders — why?" The answer is almost never about `React.memo` being broken. Something in the props is a new reference each render, and the fix is to stabilise that value (often with `useMemo`, sometimes by hoisting a constant out of the component, sometimes by restructuring so the value never crosses the boundary). Being able to say which of the two tools addresses which half of the problem is the whole point of the question.