The standard React interview asks what the virtual DOM is, what a key does, and the difference between state and props. Every candidate who has read a blog post answers all three, which means the questions sort nobody. These four are harder to prepare for because they are drawn from code that actually shipped, and because the interesting part of each is a judgement rather than a fact.
The short version
Ask about code that exists, not concepts. Concepts are memorised; judgement is not.
The best signal in any answer is a stated assumption, not a correct conclusion.
Let candidates use documentation and an assistant. You are hiring for the job, and the job has both.
Score how they handle not knowing. It predicts more than anything they do know.
Trivia questions have a false-negative problem: good engineers fail them and it tells you nothing.
Why the usual questions fail
Trivia questions have two failure modes and both are expensive. They produce false positives, because the answers are memorable and widely published, so a weak candidate who prepared looks strong. And they produce false negatives, because a strong engineer who has not thought about reconciliation internals in three years fumbles a definition while being entirely capable of the work.
The deeper problem is that they test recall of how React works, when the job is judgement about what to do with a codebase. Those correlate far less than interviewers assume. The most productive React engineers we have worked with would give mediocre answers to a virtual DOM question and excellent answers to all four below.
"A question that every prepared candidate answers correctly is not an interview question. It is a formality with a scoring column attached."
These four sit inside a longer process, described stage by stage in how to hire React developers.
The four questions
Each is presented as a short extract of real code, and the candidate is asked to fix it and explain. What follows is what each one is actually testing.
If you are assessing an engineer proposed by a vendor rather than a direct hire, ask to run your own format. The hire React developers page states plainly that we expect it.
What good and bad sound like
The gap between these is not knowledge. In most cases both candidates know the same APIs, and what differs is whether they reason about the situation or pattern-match to a remembered fix.
The second row is the one that separates most reliably. Nearly every candidate fixes the warning. A much smaller number ask what happens when the user navigates away and back before the first request resolves, which is the bug that actually reaches production.
The third question is really about cost: the difference between a considered answer and a reflexive one shows up later as rework, which is the largest hidden line in what React development costs.
Running the interview well
Give the code in advance
Twenty minutes to read before the call. You are testing reasoning, not reading speed under observation.
Allow every tool
Documentation, search, an assistant. Ask them to say where they used one. The job has all of them.
Stay quiet
The first ten minutes are the signal. An interviewer who hints is assessing themselves.
Where our interests differ from yours
We publish these, so any candidate we send you could have read them. That weakens them for us and is the price of showing our working. If you use them, change the codebase they sit on and add one question from your own history. The local one will always outperform ours.
One more rule worth adopting: ask every candidate the same questions in the same order, and write the score before discussing it with anyone else. Interview panels converge on the first opinion voiced, and the cost is that you end up with one person's judgement wearing the whole panel's confidence.
Framework preference is not a signal in an interview, but it is a real decision for a project, and React or Next.js weighs it separately.
What to weight, and what to ignore
Measuring rather than asserting is the same discipline a performance budget enforces at the project level.
Questions we stopped asking, and why
Each of these was in our set at some point. Each was removed after we noticed it was either failing people we later wished we had hired, or passing people we later replaced.
The pattern across all four: each rewarded preparation or performance rather than judgement. That is the test to apply to any question you are considering. Ask whether a mediocre engineer who spent an evening revising could answer it as well as a strong one who did not. If yes, it is not earning its place.
We also retired one habit rather than a question: asking follow-ups until the candidate failed. It feels like calibration and it is actually a guaranteed way to end every interview on a failure, which distorts both the candidate's performance and the interviewer's memory of it. Now we stop at the point where the answer is good enough for the work.
Interviews are a sample, not a proof. A two week paid pilot is the only part of the process that produces evidence rather than impressions.
Questions people ask
Where to go next
These four sit inside a larger process, described in how to hire React developers. If the question is what a team costs rather than how to assess one, what React development costs has the drivers. The vetting we put our own engineers through, and the replacement terms behind it, are on the hire React developers page.
Yogesh Jadhav
Founder of reactdevstudio. Ten years as a working full stack developer, across SaaS products and client work.
Related, Group B only
Three more on engineering
Engineering posts only, scored within Group B, so a technical reader is never handed a procurement checklist.