React Interview Questions: How to Reason Through the Second Question

Most React interview questions are not really about React. The first question — what is a hook, what does state do — is a warm-up. The interview starts at the second question, when the interviewer asks why you chose that approach and what it costs you. That follow-up is where candidates who memorised definitions and candidates who actually reason about code start to look different.

This article is about that second and third question. It gives you a repeatable way to reason about trade-offs out loud, for the follow-ups that come up most often in a React technical interview. It is not a list of definitions to memorise. It is a way to think on your feet.

Why React Interview Questions Move Past the First Answer

Anyone can learn that useState returns a pair. Interviewers know this, so they rarely stop there. The signal they are looking for is what you say next: can you connect a concept to a decision, and can you defend that decision when someone pushes on it?

A definition answer sounds like this: "useMemo caches a computed value between renders." True, but it tells the interviewer nothing about your judgement.

A trade-off answer sounds like this: "useMemo caches a computed value, so I reach for it when a calculation is genuinely expensive or when a value is passed down and identity matters for a memoised child. The cost is extra code and a dependency array that can go stale if I get it wrong, so for cheap calculations I leave it out."

The second answer shows you know when not to use the tool. That is the part interviewers are testing.

A follow-up question is usually curiosity, not a trap. The interviewer wants to see how you think when the ground shifts slightly. If you treat it as an attack, you get defensive; if you treat it as an invitation to reason, you relax and the answer gets better.

A short pause before you answer is normal and it reads as thinking, not as blanking. "Let me think about the trade-off there for a second" is a complete, professional sentence. Rushing into a half-formed answer is what actually costs you.

A Four-Step Pattern for Any React Follow-Up

When a follow-up lands and your mind goes quiet, you do not need a script. You need a shape. This four-step pattern fits almost any React follow-up question, from hooks to performance to component design.

Step one: restate the constraint

Say out loud what the question is really weighing. "So the question is whether I optimise for render performance here, or for readability and a smaller surface area." Naming the constraint buys you a second of thinking time and shows the interviewer you heard the real question.

Step two: name one option you would pick, and one you would not

"I'd use a memoised child component here. I wouldn't reach for a global store just to avoid passing one prop down two levels." Picking a side matters. "It depends" on its own is not an answer; "it depends on X, and here X is true, so I'd do Y" is.

Step three: give the concrete cost of your choice

Every choice has a bill. Name it. Re-renders, bundle size, indirection, a larger test surface, a dependency array to maintain. Candidates who can name the cost of their own decision sound like they have shipped code before.

Step four: say when you would change your mind

"If the list grew past a few hundred rows, I'd stop hand-rolling this and look at virtualisation." This is the step that separates a considered answer from a rehearsed one. It shows your decision is conditional on real constraints, not a habit.

State, Props and Re-renders: The Follow-Up About Why It Re-rendered

"Why did that component re-render?" is one of the most common React follow-up questions, and it rewards a clear mental model rather than hand-waving.

A component re-renders when its own state changes, when its parent re-renders, or when a value it reads from context changes. Props changing is a consequence of the parent re-rendering, not a separate trigger. If you can say that sentence cleanly, you are already ahead of a lot of candidates.

Reference identity is where people get caught. Two objects with the same contents are not the same object. If you create a new object or array on every render and pass it down to a memoised child, the child still re-renders, because the reference changed even though the values did not. That is the mechanism behind a whole family of "why is my memo not working" follow-ups.

Memoising a value or a component buys you fewer renders. It costs you an extra dependency array to keep correct, a little more code to read, and a real risk of stale values if you capture the wrong thing. For a cheap component, that is a bad trade. Say that out loud — it shows you optimise deliberately, not reflexively.

If the interviewer asks about the precise order of some internal step and you are not certain, do not invent it. "I know the practical rule — memo won't help if the prop identity changes each render — but I'd want to check the exact internals of the current version rather than guess." That is an honest, strong answer. Guessing confidently and being wrong is the only bad outcome here.

Hooks Follow-Ups: Dependency Arrays, Effects and Cleanup

Hooks questions are where a lot of React interview answers collapse into vague gestures. Keep them concrete.

"Why is this effect running twice?" usually comes down to what is in the dependency array and whether the effect is set up to be safe if it runs more than once. The useful move is to reason from the dependency list: what values does this effect actually read, and does the list match them? If you can walk through that out loud, you are answering the real question.

A good rule to say out loud: if it happens because the user did something, it belongs in an event handler. If it can be computed from existing props or state during render, it is derived state and does not need an effect at all. Effects are for synchronising with something outside React — a subscription, a network request, the document title. Naming that boundary is a strong answer to a design follow-up.

Every effect is a place where timing, cleanup and dependencies can go wrong. Fewer effects usually means a simpler component. The counter-argument is that sometimes an effect is the honest way to express "this needs to stay in sync with something external," and hiding that behind derived state makes the code harder to follow. Say which side you are on and why.

Cleanup is not housekeeping. If you subscribe to something and do not unsubscribe, you have a leak, and in a component that mounts and unmounts you have a bug. Framing cleanup as correctness rather than neatness is the kind of phrasing that lands well in a React technical interview.

Component Design Follow-Ups: Composition, Context and Prop Drilling

Design follow-ups test whether you can talk about structure, not just syntax.

Context is for values that are genuinely shared across a subtree — a theme, a current user, a locale. It is not a shortcut for avoiding prop drilling through two levels. If you reach for context every time a prop travels down, you may be hiding a data-flow problem rather than solving one. Saying that distinction out loud is a strong move.

If the follow-up is a design question — "how would you build a Tabs component?" — compound components and render props are both answers about who controls the API. Compound components give the caller a familiar, constrained shape. Render props hand more control back to the caller. Both are legitimate; the question is which fits the use case.

Flexibility for the caller usually costs you a harder-to-document API and more ways for people to misuse it. A constrained API is easier to test and easier to onboard onto. Pick one and justify it against the team you are imagining.

"If I had another day, I'd pull this state up one level so the two siblings stop passing callbacks to each other." Interviewers like hearing that you see the next improvement and can describe it briefly. It shows judgement without implying the current code is bad.

Performance Follow-Ups: Lists, Keys and Lazy Loading

Performance follow-ups are really questions about priorities. Answer them that way.

Keys tell React how to match items between renders. Get them wrong — say, by using the array index on a list that reorders — and React can reuse the wrong component instance, which shows up as state attached to the wrong row. If you can explain that consequence rather than just "keys should be unique," you are answering at the right level.

Virtualisation renders only the visible rows, which helps long lists but adds a dependency and complicates anything that needs to measure the full list. Code splitting reduces the initial bundle but introduces loading states and a little latency when a chunk is first needed. Neither is free.

A skeleton screen can make an app feel faster while doing nothing for actual time to interactive. Say that distinction out loud. It shows you care about the user's experience and the underlying metric, not just the demo.

"I'd profile first rather than guess" is a good answer, not an evasive one — as long as you say what you would measure and what result would change your mind. Pair it with a concrete example from your own work and it stops sounding like a dodge.

When the Follow-Up Is "How Would You Test This?"

Testing follow-ups are a fast way for an interviewer to check whether you think about behaviour or implementation.

Assert on what the user sees and does — the button is disabled, the error message appears — rather than on internal state or which function was called. Behaviour tests survive a refactor; implementation tests break every time you rename something.

"I wouldn't test that this component calls a particular internal helper, because that's an implementation detail I want to be free to change." Saying what you would not test is often more revealing than listing what you would.

Integration tests give you more confidence that a feature works end to end but run slower and fail for more reasons. Unit tests are fast and precise but can pass while the feature is broken. Most teams want a mix, and saying so is a reasonable, honest answer.

If a component is hard to test, that is often a design signal — too many responsibilities, or state trapped in the wrong place. Making that connection shows the interviewer you think about these things together rather than as separate topics.

Practising React Follow-Ups Without Scripting Yourself

You cannot memorise your way through a follow-up sequence, because you do not know which follow-up is coming. What you can do is practise reasoning out loud until it feels normal.

A memorised paragraph answers one question. The moment the interviewer asks "and why not the other approach?", the paragraph has nowhere to go. Reasoning, unlike a paragraph, can be re-entered from any angle.

Speak your answers rather than writing them. Record yourself on your phone, then listen back for structure — did you name the constraint, pick a side, name a cost, and say when you would change your mind? Review the structure, not the wording. Wording will vary naturally and that is fine.

The most convincing React interview answers are specific. Pull examples from something you actually built: the list you virtualised, the context you removed, the effect you deleted. Specific beats generic every time, and it keeps you honest.

When you listen back, you will find a spot where you wandered. Do not rewrite the whole answer. Fix the first sentence so it names the constraint, and the rest usually falls into place.

The Python Interview Questions: Concepts and Trade-Offs piece makes a similar point in a different language: the pattern of naming a constraint and defending a choice travels well across stacks. You can find more practice material on our blog.

Putting It Together: A Ten-Minute Warm-Up Before the Call

Ten minutes before the interview, run this warm-up. It is short enough to actually do.

1. Pick three React concepts — say, memoisation, effects, and context — and say one trade-off for each out loud. One sentence each is enough.
2. Prepare two honest "I would need to check" answers. Choose topics where you genuinely are not certain of the internals, and practise saying so without apologising for it.
3. Have one project story ready that shows a decision you reversed. A time you changed your mind is more persuasive than a time you were right.
4. Keep the goal in view: you are demonstrating reasoning, not recall. The interviewer already knows you can look up a definition. They are watching to see how you think when the question moves.

If you want a place to run this warm-up regularly, the authorized use policy explains how practice tools are meant to be used: for preparation and honest self-review, not for anything during a live interview.

Reasoning out loud is a skill, and like any skill it improves with repetition. Practise the four-step pattern until it is automatic, and the follow-up stops feeling like a trap and starts feeling like the interesting part of the conversation.

Frequently asked questions

What if I do not know the answer to a React follow-up question?

Say so plainly, then say what you do know and how you would find out. For example: "I know memo won't help if the prop identity changes each render, but I'd want to check the exact internals rather than guess." An honest, bounded answer is far stronger than a confident wrong one, and interviewers generally respect it.

Should I mention React version differences in my answers?

Only when the version actually changes your decision. If a behaviour or API you rely on differs between versions, say which one you are assuming and why. Otherwise, mentioning versions for its own sake adds noise. Tie it to a concrete choice you are making.

How detailed should my trade-off explanation be before I stop talking?

Use the four-step shape: name the constraint, pick an option and reject one, give the concrete cost, then say when you would change your mind. That is usually 20 to 40 seconds. Then stop and let the interviewer steer. If you are still talking after naming the cost and the condition, you are probably repeating yourself.

Can I use my own side project as an example in a React interview?

Yes, and you usually should. Specific examples from something you actually built are more convincing than generic ones, and they keep your answers honest. Pick a decision you made, describe the constraint you were under, and say what you would do differently now.

How do I practise React follow-up questions on my own?

Answer out loud rather than writing your answers down. Record yourself, then listen back only for structure: did you name the constraint, pick a side, name a cost, and say when you would change your mind? Fix the opening sentence of any answer where you rambled, and leave the rest alone.

Is it bad to say 'it depends' in a React technical interview?

Not on its own, but it is incomplete. "It depends" without the second half sounds evasive. The full answer is: "It depends on X; in this case X is true, so I'd choose Y, and the cost of that is Z." Naming the condition and then committing to a choice is what interviewers are listening for.

Practise your React answers out loud and review the recording for structure.