useMemo and useCallback: 5 things that actually trip people up

Tarun Sharma — Tue, 18 Aug 2026 12:47:54 +0000

Both of these get memorized as syntax pretty fast. What doesn't get memorized is what they're actually doing under the hood, and that's where the bugs show up. Here's the stuff that actually trips people up once you go past "wrap it in useMemo I guess."

1. They solve different problems, not the same one

useMemo caches a value. useCallback caches a function reference. People treat them like interchangeable "make it faster" hooks, but useCallback(fn, deps) is really just useMemo(() => fn, deps) under the hood, it just hands you back the function itself instead of calling it for you.

2. Neither one makes your code faster by default

Wrapping something in useMemo has a cost too, it runs the dependency comparison on every render. If the calculation inside is cheap, you're paying more than you save. Reach for these when the calculation is genuinely expensive, or when the value needs to keep the same reference across renders (see #3), not as a reflex on every derived value.

3. The real reason you need useCallback: keeping props stable for React.memo

If you pass a normal inline function as a prop to a memoized child, that child re-renders anyway, because the function is a new reference every single render. useCallback is what actually keeps that reference stable across renders so React.memo's shallow comparison has something to bail out on. Without it, memo is comparing a new function to another new function every time and always finding them "different."

4. The dependency array lies just as easily here as with useEffect

Same stale closure trap you'd hit with useEffect. If you memoize a function with useCallback(fn, []) and fn reads a prop or state value from outside, you get a function frozen with whatever that value was on the first render. The fix is the same one as always: put it in the deps array, don't fight the linter into silence.

5. Object and array literals as deps break memoization silently

useMemo(() => doSomething(config), [config]) looks safe until config is { foo: bar } created inline on every render, in which case the dependency is a new reference every time and the memo never actually hits, it recalculates every render while looking like it's working. Move the object outside the render, or memoize it too.

Curious what the actual useMemo or useCallback bug was that got you. Drop it below, would love to hear it.

5 React interview questions I'd actually ask (and how I'd answer them)

Tarun Sharma — Fri, 14 Aug 2026 08:26:33 +0000

Most "React interview questions" lists online are either trivia (define useEffect) or so advanced they're not useful below 3-4 years of experience. Here are 5 I think are actually worth knowing, with the answer I'd give if asked.

1. What does this log, and why?

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i));
}

It logs 3, 3, 3. var gives the whole loop one shared variable, so by the time the callbacks run, the loop has already finished and i is 3. Swap var for let and it logs 0, 1, 2, let creates a fresh binding for every iteration, so each callback closes over its own copy.

2. Why doesn't an empty dependency array guarantee no stale-closure bugs?

An effect with [] only runs once, but any function or state it references from the render it was created in is frozen at that value forever, that's a stale closure. It's the same mechanism as question 1, just applied to a React render instead of a loop iteration.

3. What's the actual difference between useMemo and useCallback?

useCallback(fn, deps) is just useMemo(() => fn, deps). One memoizes a value, the other memoizes a function reference. People treat them as separate concepts when one is a special case of the other.

4. Why can a sibling component re-render even though its own props didn't change?

Because React re-renders every child of a component that re-renders, by default, regardless of whether that specific child's props changed. React.memo is what actually stops it, re-rendering isn't opt-out at the parent level, it's opt-in per child.

5. What does the virtual DOM actually skip?

It skips DOM writes, not DOM reads or re-renders. React still runs your component function and builds a new tree every render; the virtual DOM diff is what decides which actual DOM mutations are necessary, which are usually the expensive part.

What would you add to this list?

DEV Community: Tarun Sharma