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.
React is common enough that the standard questions are everywhere. In the Stack Overflow Developer Survey 2025, 44.7% of all respondents said they had done extensive work with React over the past year, and so had 46.9% of professional developers. Every one of those people has seen the virtual DOM question. Most have a rehearsed answer.
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.
There is also evidence that the format itself distorts the result. A randomised trial presented at ESEC/FSE 2020, Does Stress Impact Technical Interview Performance?, put 48 computer science students through the same problem either at a whiteboard in front of an interviewer or alone in a private room. Performance was reduced by more than half simply by being watched. A live whiteboard session partly measures how someone copes with an audience, which is rarely the job.
"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; when teams hire remote React developers from us, we expect exactly that. The company behind the engineer needs judging too, and what to check before hiring a React development agency goes through 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.
It is also one of the better supported findings in hiring research. Schmidt and Hunter reviewed 85 years of selection studies in Psychological Bulletin in 1998 and put the average validity of structured interviews at .51, against .38 for unstructured ones. Same questions, same order and a score written down before the debrief are most of what "structured" means in practice.
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.
Twelve more React interview questions, by level
The four above are the core. People looking for React developer interview questions usually want a longer list, and a longer list is useful as long as each question is asked about code rather than in the abstract. These are the ones we reach for when a candidate finishes early or when the role needs a specific skill checked. Pick two or three for the level you are hiring. Never all twelve.
The senior rows lean away from React itself and towards the edges where React meets a server, a second team or an old codebase. That is deliberate. It is where senior engineers spend their week. The server rendering question overlaps with React or Next.js and with our guide to React SEO, and the API contract question is the boundary described in React vs Node.js. A candidate who answers those two well is often the person you want owning both sides of it.
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 along with the vetting stages and the replacement terms behind them. Cost is a separate question: what React development costs has the drivers for a project and what it costs to hire a React developer the numbers per engineer, and teams who hire a React developer in India from us get the same process, in writing. Whatever set you use, change a question every few months, because published questions stop sorting anyone.
Sources
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.