React interview questions

React interviews used to be lifecycle methods and state management library trivia. They are now about the rendering model and where code runs — which is harder to memorise and much more revealing.

The single most common modern question is some form of "why did this component re-render". A candidate who can reason through it has a mental model; one who has only used React by pattern-matching cannot, and the gap shows within two follow-ups.

The shift reflects what actually causes trouble in production. Nobody debugs a lifecycle method any more; they debug a component that renders forty times, an effect that fires in a loop, or code that touched a browser API on the server.

Expect questions about what triggers a render, why state updates appear asynchronous, and why reading state immediately after setting it gives the old value. The explanation — that the value in scope belongs to that render — is the one worth being able to say cleanly.

Reconciliation and keys come up constantly, usually as a bug to diagnose: a list where inputs keep the wrong values after reordering. Being able to say that index keys tie state to position rather than identity, and what breaks as a result, is a strong answer.

Be precise about what a parent re-render does. A child re-renders when its parent does, regardless of whether its props changed, and the common misconception that unchanged props prevent it is exactly what the follow-up question is hunting for.

• What causes a re-render, and what does not
• Why a state value looks stale inside a closure
• What keys do during reconciliation, and why index keys break reordering
• Batching, and when updates are grouped

Interviewers ask about effects because misuse is so widespread. The strongest signal you can give is knowing when *not* to use one — deriving a value during render instead of syncing it in an effect, or handling something in an event handler rather than reacting to state afterwards.

Be ready for the dependency array and cleanup. A question about a subscription or timer that leaks is common, and the answer should cover both what cleanup does and when it runs relative to the next effect.

The classic anti-pattern worth naming unprompted is an effect that sets state derived from props. It causes a second render, it can loop, and the value should simply have been computed during render — recognising that on sight is a reliable seniority signal.

This is now a standard round and the one candidates most often answer vaguely. Saying Server Components are "faster because they render on the server" does not survive a follow-up.

Be able to state what cannot cross the boundary, what a server component cannot do — no state, no effects, no browser APIs — and how you would debug a component that fails because it touched `window` on the server. That last one is the most common real-world error and knowing it signals genuine use.

Know what serialises across the boundary too. Functions and class instances do not, which is why passing a callback from a server component to a client one fails, and being able to say that before being asked is the kind of detail that ends this round early.

Expect to be asked when to memoise. The answer interviewers want is "after measuring", with an understanding that memoisation has its own cost and that wrapping everything is a common and counterproductive habit.

Stronger candidates talk about structural fixes before memoisation: moving state down so fewer components subscribe to it, splitting a context that changes too often, or shrinking the client boundary so less ships at all.

Mentioning what you would measure with makes the answer concrete. Being able to say you would profile, find which component is re-rendering and why, and only then decide, separates you from candidates reciting a list of optimisation hooks.

Usually a small interactive component — a debounced search, a list with filtering, a form with validation — built while you talk. Accessibility and the non-happy-path states are where most candidates lose marks silently.

Handle loading, empty and error states without being asked, and use a real `button` rather than a clickable div. Neither takes extra time, and both are noticed.

Narrate the decisions rather than only the code. Saying why you are lifting a piece of state, or why you are debouncing the value rather than the request, gives the interviewer the reasoning they are actually scoring.

• Distinguish empty-because-new from empty-because-filtered
• Show a real error state with a retry, not a blank screen
• Use semantic elements so keyboard and screen reader use works
• Clean up timers and subscriptions you create
• Say what you would add with more time, and why you skipped it