React interview questions seniors actually get asked

Nobody senior gets asked to list the lifecycle methods. What they get asked is why a page re-renders more than it should, why an effect fired twice, and why the app feels slow when every request is fast.

Here are the areas those questions come from, and what a strong answer contains.

What actually causes a re-render

The most common senior React question in any form, and the one that most reliably separates candidates.

A component re-renders when its state changes, when its parent re-renders, or when a context it consumes changes. That is the whole list. The part people get wrong is the second one: a child re-renders because its parent did, regardless of whether its props changed at all. Props are not an input to the decision, they are only an input to what the render produces.

Effects, and why they are the biggest source of bugs

Expect at least one effect question. The strong framing is that an effect is for synchronising with something outside React: a subscription, a timer, an imperative browser API. Most of the time, a bug that arrives with an effect is a sign the work did not belong in one.

• Derived state in an effect. Computing state from props inside an effect causes an extra render and a frame of stale UI. Compute it during render instead.
• The stale closure. An effect captures the values from the render it ran in. Miss a dependency and it quietly reads an old value forever, which is the single most common React bug in production code.
• Missing cleanup. Subscriptions, intervals and in-flight requests need a cleanup function, or you get leaks and out-of-order responses overwriting newer ones.
• Fetching in an effect without cancellation. Two quick navigations and the slower response wins. Interviewers ask about this specifically.

If you can explain why an effect that fetches needs to handle its own obsolescence, you are well past the median candidate.

Keys

Looks like a beginner topic, is not. Everyone knows keys should be stable and not the array index. Far fewer can say what actually goes wrong.

Keys tell React which element in the new list corresponds to which element in the old one. With index keys, deleting the first item means every element shifts, so React reuses the wrong instances: state stays attached to the wrong row, inputs keep the wrong value, animations play on the wrong element. The list still looks right until the components hold state, at which point the bug is bizarre and hard to trace.

{rows.map((row, i) => (
  <EditableRow key={i} row={row} />   // index key: identity shifts on delete
))}

{rows.map((row) => (
  <EditableRow key={row.id} row={row} />  // stable identity survives reorder
))}

Where state should live

Architecture questions in a React interview are usually really state-ownership questions. Expect some version of how you would structure state in a large application.

The answer that reads as senior starts by separating server state from client state. Data that lives in a database and is cached in the browser has completely different needs from whether a dropdown is open: it needs revalidation, deduplication and staleness handling, none of which a general state container gives you. Once you say that out loud, the question of which global state library to use mostly evaporates, which is exactly the point being tested.

Then colocate the rest. State should live at the lowest common ancestor of the components that use it, and lifting everything to the top is a performance and maintenance problem disguised as tidiness.

Performance, properly

The weak answer to any performance question is a list of memoisation hooks. The strong answer starts with diagnosis, because the three causes have different fixes and applying the wrong one wastes a sprint.

1. Rendering too often: a context or a parent updating more than it should. Fix the source, then memoise if it still matters.
2. Rendering too much at once: a large list. Virtualise it. No amount of memoisation helps here.
3. Not a React problem at all: a slow request, a large bundle, an expensive synchronous computation blocking the main thread.

Mention that memoisation is not free, since every memo adds a comparison and a dependency array that can be wrong, and you have said something most candidates do not.

Rendering on the server

Increasingly standard in senior frontend rounds, and a place where a lot of otherwise strong candidates are vague.

Be able to say plainly what runs where, what hydration actually is and why a mismatch happens, and why moving data fetching to the server changes the waterfall problem. The interesting follow-up is usually about anything time or locale dependent, since a date formatted with the server's timezone and then re-rendered in the browser's is the classic mismatch, and explaining that specific case demonstrates real experience.

How to prepare

Take a component you have written and answer three questions about it. When does it re-render. What would happen if this effect's dependency array were wrong. Where would this fall over with ten thousand rows.

That exercise finds gaps faster than any question list, because it produces the layer underneath the answer, which is where the follow-up will land.