React interview questions for experienced developers — past the "what is a hook" stage
For experienced React developers, interviews stop asking what useEffect does and start asking why your app re-renders three times when it shouldn't. Here's what that level of question actually looks like.
There's a clear line in React interviews between "can you use the API" and "do you understand why the API behaves the way it does." Junior interviews live on one side of that line — what's a hook, what's the difference between state and props. Experienced interviews live on the other side, and the questions are built to expose whether you've actually debugged a re-render problem at 2am or just read about how React works.
Re-renders — the question that separates "uses React" from "understands React"
What gets recited: React re-renders when state or props change.
What actually gets tested: "Here's a component tree, the parent's state changes — which children re-render, and why?" The honest answer requires understanding that a parent re-render triggers child re-renders by default, regardless of whether the child's own props changed, unless something intervenes — React.memo, well-structured component composition (passing children as props rather than nesting), or moving state down to the component that actually needs it. Interviewers are listening for whether you reach for useMemo/useCallback reflexively (a common overcorrection) or actually diagnose where the unnecessary work is happening first.
useEffect dependency arrays — the bug that ships to production constantly
Almost every experienced React developer has shipped a useEffect with a wrong dependency array — either missing a dependency (stale closure bug, the effect uses an old value) or including one that changes every render (infinite loop, or an effect that fires far more than intended). The strong interview answer doesn't just recite "the dependency array controls when the effect reruns" — it explains how to reason about what belongs in it: anything referenced inside the effect that can change should be there, and if that causes the effect to fire too often, the real fix is usually restructuring the effect or the state it depends on, not lying to the linter by omitting a dependency.
State management — not "Redux vs Context," but "when do you reach for either"
This question gets asked badly a lot — as a preference poll. The better version, and the one worth being ready for, is situational: "this feature needs to share state across three unrelated components three levels apart, what do you reach for?" A strong answer distinguishes server state (data fetched from an API — better handled by a library built for caching and invalidation, like React Query, than by manually shoving it into global state) from client UI state (a modal's open/closed status, form input — often fine in local state or Context), and explains that reaching for Redux by default, for everything, is itself a smell.
Custom hooks — the question that reveals whether you actually extract logic, or just wrap it
"Write a custom hook for X" is common, but the follow-up that matters more is "how do you decide something should be a custom hook?" The strong answer: when the same stateful logic — not just the same JSX — is duplicated across components, or when a component's logic is complex enough that pulling it into a named hook makes the component itself easier to read. A custom hook that just wraps useState and returns it, with no actual shared logic, is usually not adding value — and interviewers who ask you to explain a hook's design are checking whether you know that distinction.
Performance — profiling before optimizing, not the reverse
The trap experienced developers fall into during interviews is jumping straight to "I'd add useMemo here" without being asked to diagnose anything first. A stronger answer to "this component is slow, what do you do" starts with the React DevTools Profiler — actually identifying which component is re-rendering unnecessarily and why — before reaching for a specific fix. Naming the diagnostic step first is often what separates someone who's memorized optimization techniques from someone who's actually fixed a real performance problem under time pressure.
If you want to practice explaining React tradeoffs out loud, with follow-ups when an answer stays too generic, try role-specific mock interviews for React/Frontend — free to start.