React interviews mix framework specifics — hooks, rendering, state — with JavaScript fundamentals that decide whether you actually understand what React is doing. Below are the most common questions with model answers. Middle: deeper understanding, optimization, and real-world situations.
It helps when the computation is genuinely expensive, or when the value is a dependency of another hook or a memoized child, where a new reference each render defeats the memoization. It is noise around cheap operations, because the comparison and the retained value cost something too. Wrapping every value in useMemo makes code harder to read for no measurable gain.
Open the Profiler, record an interaction, and use "why did this render" to see whether it was props, state, or the parent. The usual causes are an object or arrow function created inline in the parent, context whose value is a fresh object every render, or state that lives higher in the tree than it needs to. Fix the cause rather than reaching for React.memo, which only hides it.
Context avoids threading a value through components that do not care about it — theme, locale, the current user. It becomes wrong for frequently changing state, because every consumer re-renders when the value changes and there is no selector to subscribe to part of it. At that point you want a state library with subscriptions rather than one context holding everything.
Because the naive version is missing everything that makes server data hard: caching, deduplicating identical requests, refetching when the window regains focus, retries, and not writing into an unmounted component. Rewriting those per screen is where the bugs live. The mental shift is that server data is a cache you synchronise, not state you own.
useEffect runs after the browser has painted, so the user may briefly see the state before it. useLayoutEffect runs synchronously after DOM mutations but before paint, which prevents that flicker at the cost of blocking. Use useLayoutEffect only when you measure the DOM and immediately change it based on the measurement — a tooltip position, a scroll adjustment.
An error boundary catches it and shows a fallback instead of a blank page, since an uncaught render error unmounts the whole tree. Boundaries do not catch errors in event handlers or async code, which is the part people miss — those need ordinary try/catch. Place boundaries around meaningful sections so one broken widget does not take down the screen.
At route level first, because a user landing on one screen should not download the rest of the app. Then around genuinely heavy, rarely used components — a chart library, a rich text editor, a modal that most users never open. Splitting smaller than that adds request overhead and loading states in exchange for kilobytes.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle React Frontend interview →