Senior React interviews are rarely about API surface. They circle a handful of areas where a candidate either understands the rendering model or is pattern-matching, and the follow-ups find out which within about two minutes.
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.
Why is this component re-rendering when its props have not changed?
Junior answer: Because something in its props is changing identity between renders, so React sees a new value and re-renders it. Wrapping it in memo and memoising the props usually fixes it.
Senior answer: By default it re-renders because its parent did, and props do not come into it. Identity only matters once you wrap it in memo, at which point a new object or function prop defeats the comparison, which is why memo so often changes nothing. Before reaching for memo I would find out why the parent is rendering that often, since that is usually the actual bug. On the last one of these I looked at, a context was holding a new object every render, so every consumer rendered on every keystroke.
The follow-up is always what memo actually compares. Answer one gets stuck there.
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
))}
The bug that makes this concrete: remove the first row and the text input's value follows the wrong item, because index keys made React reuse the wrong instance.
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.
- Rendering too often: a context or a parent updating more than it should. Fix the source, then memoise if it still matters.
- Rendering too much at once: a large list. Virtualise it. No amount of memoisation helps here.
- 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.
The question behind the question
When an interviewer asks about performance, they usually want to know whether you measure. Saying which tool you would open and what you would look for first is worth more than any list of optimisations.
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.
Common questions
Do I need to know class components?
Enough to work in a codebase that has them, and to talk about migration. Nobody senior is being tested on lifecycle trivia.
How much state library knowledge is expected?
Less than people think. What is expected is the reasoning about which state is server state, which is local, and why that distinction decides the tooling.
Are React internals fair game?
Reconciliation and the rendering model, yes, because they explain behaviour you hit in practice. Fiber implementation details, rarely, and an interviewer who leads with them is testing something other than your ability to do the job.
The fastest way to find out whether your React answers hold up is to be followed up on them. Run a React-focused interview at your level. Practise a React interview
