Last updated: July 11, 2026
React Developer Interview Questions 2026
Strong React interview questions in 2026 test hooks judgment, Server Component decisions, and React 19 fluency, not memorized definitions. The sharpest signal comes from asking a candidate to critique code, defend a trade-off, and explain why their own component re-renders when it shouldn’t.
Robert Ardell here, co-founder at KORE1. I’ve spent the better part of two decades placing engineers, and React roles are the ones hiring teams misjudge most. Not because the questions are hard to find. Every question bank on the internet has them. The problem is that most of those lists were written for the person answering, not the person deciding. This one comes from the other chair. It’s built from the intake calls where a hiring manager tells me what they plan to test, and the debrief calls where they tell me why a candidate they liked still didn’t get the offer. We earn a fee when you hire through our IT staffing services practice. Read the bias into it. The failure patterns hold up either way.
Here’s the shift that changed React interviews. AI writes the boilerplate now. A candidate can ship a clean take-home with an assistant riding shotgun, and the code compiles, and the tests pass, and none of it tells you whether the person understands what they submitted. So the interview moved. It stopped rewarding syntax and started hunting for judgment.
Last quarter one of our clients ran a mid-level candidate through a paid take-home. Flawless. Genuinely clean code. In the live review the interviewer deleted a useMemo wrapper and asked what would change. The candidate said the component would break. It wouldn’t. Memoization is a performance tool, not a correctness tool, and if removing it changes behavior you’ve got a bug hiding under the optimization. The candidate had shipped the memo because an AI suggested it. He’d never asked why. That’s the whole game in 2026, compressed into one question.
What a React Interview Actually Has to Surface
React is still the center of gravity in front-end hiring. The 2025 Stack Overflow Developer Survey put React at roughly 44.7% usage across more than 49,000 respondents, with a 52.1% admiration score, which is the survey’s polite way of saying most people who use it want to keep using it. Demand tracks that. The Bureau of Labor Statistics projects 15% growth for software developers through 2034, about 129,200 openings a year. The pool is large. The pool that can reason about React under pressure is not.
That gap is what you’re paying an interview to find. Across our practice in 30+ U.S. metros, React searches that name the rendering strategy in the job description close in about 18 days. The ones that just say “React developer, 3+ years” drag past a month, because the applicant pool splinters and half the resumes look identical until someone asks a real question. A precise interview loop is the cheapest fix for a slow search that we sell. It also happens to be true.
The questions below are grouped the way I’d build a loop. Fundamentals first, because they’re the cut line. Hooks next, because that’s where most React interviews are actually decided. Then React 19, performance, and the judgment rounds that separate a coder from an engineer.
React Fundamentals That Still Separate Candidates
Don’t skip these because they sound basic. The basics are where AI-assisted candidates get exposed, because the assistant handled the fundamentals for them and they never internalized the why.
Reconciliation and keys. Ask a candidate to explain what a key does, and most will say “it helps React tell list items apart.” True and shallow. The better probe is a bug. Show them a list that re-orders and flashes or loses input focus when an item is inserted at the top, with the key set to the array index. Ask why. A candidate who understands reconciliation will tell you the index key makes React think every item after the insertion point changed, so it tears down and rebuilds DOM that should have been reused. Index keys are fine for static lists. They’re a trap for anything that reorders. The person who catches that has debugged it before. You can hear it in the specificity, the way they describe the flash and the lost focus and the rebuilt DOM as things they’ve actually watched happen in a browser at two in the afternoon while a product manager stood behind them waiting, not as facts they read on a flashcard the night before.
Controlled versus uncontrolled inputs. Here’s a scenario I’ve watched sink two senior candidates. A form drops a keystroke under load. Type fast, lose a character. Why? Usually a controlled input whose value comes from state that’s being updated asynchronously, or a parent re-render stomping the input mid-keystroke. A candidate who can walk from symptom to state timing to a fix understands the controlled-input contract. One who shrugs and says “add a debounce” is patching a wound they can’t see.
The virtual DOM question, inverted. “Explain the virtual DOM” is a junior question in 2026. Ask it to a senior and you’re testing whether they’ll give you a definition or a critique. The definition is on every flashcard. The critique is the signal. A strong senior will tell you the virtual DOM was never free, that diffing has a cost, that the whole point of the React Compiler and fine-grained reactivity elsewhere is to do less of it, and that “React is fast because virtual DOM” has been a lazy claim for years. If they defend the abstraction like it’s 2018, note it.
Hooks Questions, Where React Interviews Get Decided
If I had one round to evaluate a React developer, it would be hooks. Not trivia about hooks. The reasoning underneath them. Here’s where I’d push.
useState and batching. Give them a handler that calls setCount(count + 1) three times and ask what the count is after one click. If they say three, they’ve missed batching and stale closures. The answer is one, because all three read the same count from the render’s closure. Then ask for the fix. The functional update, setCount(c => c + 1), is the tell that they’ve actually been bitten by this. React 18 batches more aggressively than React 17 did, and a candidate who can explain that the batching now extends to promises, timeouts, and native event handlers rather than only React’s own synthetic events has genuinely kept up instead of just claiming to. Small distinction. It sorts people fast.
useEffect, and the effects you shouldn’t write. The best useEffect question isn’t about the dependency array. It’s “show me an effect you’d delete.” Strong candidates know that a lot of effects are derived state pretending to be a side effect, and that the fix is to compute during render instead of syncing with an effect. Then ask why an effect runs twice in development. If they know it’s StrictMode double-invoking to surface missing cleanup, good. If they’ve disabled StrictMode to make the “bug” go away, that’s a conversation.
Custom hooks as the live task. Skip the algorithm puzzle. Ask them to build a small custom hook on the spot. A useDebounce, or a usePrevious, or a hook that tracks whether an element is on screen. Small task. Big reveal. Do they clean up? Do they get the dependency array right? Do they understand why hooks can’t be called conditionally, that it’s about call order and the fiber that tracks it, not some arbitrary rule? You learn more from ten minutes of this than from an hour of quiz questions.
One thing I tell every hiring manager. Watch how they talk while they type. The candidate who narrates the trade-off, “I could memoize this but it’s cheap, so I won’t,” is showing you the judgment you’re actually hiring for.
React 19 and the Questions That Date a Candidate
React 19 is the fault line in 2026 interviews. A candidate who’s shipped with it talks differently than one who read about it the night before. Four areas tell you which one you’ve got.
Server Components. The theory question is table stakes. The real one is a design call. Try this: you’re building a product page that server-renders reviews from the database and needs a client-side “sort by rating” control. How do you split it? The answer you want keeps the review fetch and the initial render as a Server Component, so none of that data-fetching code or the database client ships to the browser, and pushes only the sort control behind a 'use client' boundary. The candidate who makes the whole page a client component “to keep it simple” just shipped your database query logic and 40 extra kilobytes to every visitor. Ask them what the cost was. See if they know. The one who can put a rough number on it is doing real accounting. They’ll say the database client got bundled, the review-fetching code went with it, probably an ORM too, and all of that now ships to every phone that opens the page. That’s production experience talking. Localhost never taught anybody that.
Actions and forms. React 19 folded a lot of form pain into the framework. useActionState, useFormStatus, and useOptimistic handle pending states, submission status, and optimistic UI without the tangle of state we all used to write. A candidate who’s used them will describe an optimistic “like” button in about three sentences. One who hasn’t will reach for four useState calls and a try-catch. Neither is disqualifying. But it tells you how current they are.
The React Compiler. This is my favorite 2026 question, because the wrong answer sounds smart. Ask whether the React Compiler means we can stop using useMemo and useCallback. The lazy answer is “yes, the compiler handles it now.” The real answer is more careful. The compiler auto-memoizes at build time, so in compiled code most manual memoization does become unnecessary, and that’s a genuine relief. But you still need to understand referential equality for code the compiler can’t cover, for third-party boundaries, and for reading a stack trace when something re-renders anyway. A developer who thinks the compiler means they never have to think about renders again has stopped thinking one step too early. Read the official React 19 release notes if you want the primary source to calibrate answers against.
The use hook. Lighter, but a nice tell. Ask what use does that other hooks can’t. The answer is that it can be called conditionally and reads a resource like a promise or context, which breaks the old rules-of-hooks intuition in a specific, deliberate way. Candidates who can explain why that exception is safe understand the machinery, not just the API.
Performance and Debugging Questions That Reveal Real Miles
Anybody can recite “use React.memo.” Fewer can debug a real slowdown. So make it real.
Describe a dashboard rendering 12,000 rows that stutters when you scroll. What’s the fix? The junior instinct is to memoize the row component. That barely helps, because you’re still mounting 12,000 DOM nodes. The senior answer is virtualization, rendering only the rows in view with something like TanStack Virtual or react-window, which turns twelve thousand mounted rows into the thirty or so actually on screen. If the candidate jumps straight to useMemo, you’ve learned they reach for the tool they know instead of the one the problem needs.
Follow it with process. How would they confirm the fix instead of guessing? Strong answers name the React Profiler, or the render-count tooling, or a flame graph. We had a fintech client in Orange County whose “React is slow” complaint turned out to be a context provider at the app root re-rendering the entire tree on every keystroke in a search box. The fix wasn’t more memoization. It was moving the state down. Once the search box owned its own state instead of parking it at the app root, the provider stopped handing a fresh value to every consumer on every keystroke, and the stutter three engineers had spent a week blaming on React vanished in a four-line change. The candidate who found it in the pairing round did it by measuring first. That’s the habit you’re testing for.
Suspense and transitions round it out. A candidate who can explain when to reach for useTransition or useDeferredValue, and why marking an update as non-urgent keeps an input responsive while an expensive list re-renders, has worked on something that mattered. It’s a specific kind of knowledge. You don’t pick it up from a tutorial.
The Judgment Questions Most React Loops Skip
This is the round that’s new, and the one I’d add to almost every loop I see.
Hand the candidate a small React component that’s syntactically perfect and semantically wrong. A useEffect that fetches on every render because the dependency is an object recreated inline. A click handler on a div with no keyboard support and no role, so it’s invisible to a screen reader. A form that looks fine and fails validation silently. Then ask them to review it like a teammate opened the pull request. What you’re testing is whether they can catch the failure that AI code generators produce most often, code that reads correctly and behaves wrong. In 2026 that skill is worth more than raw coding speed, because the coding speed is now partly automated and the careful reading of what the machine produced is not. Speed got cheap. Judgment didn’t.
Ask when they would not use React. It sounds like a trick. It isn’t. A senior who can say “a mostly static marketing page doesn’t need it, and a server-rendered form might not need a client bundle at all” is showing you they choose tools instead of defaulting to them. The candidate for whom every problem is a React problem will over-engineer your simple pages and under-think your hard ones.
And ask about testing. Not “do you write tests.” Ask what they test. The answer you want is behavior, not implementation. React Testing Library exists to nudge you toward testing what the user sees, and a developer who tests that a button click shows the right message, rather than that a particular state variable flipped, writes tests that survive a refactor. The other kind writes tests that break every time you rename something. Brittle by design. Nobody sets out to write them, but the habit of testing implementation instead of behavior produces them anyway, and six months later the test suite is the thing everyone on the team is quietly afraid to touch.
React Interview Questions by Seniority: Weak Answer vs Strong Answer
Same question, different bar. The point of a level rubric is that you’re not scoring whether they answer, you’re scoring how deep the answer goes. Here’s how a handful of core questions sound at each end of the range.
| Question | Weak Answer (junior signal) | Strong Answer (senior signal) |
|---|---|---|
| Why did this component re-render? | “Because the state changed.” | Names the parent re-render, the inline object prop defeating memo, and how to confirm it with the Profiler. |
| When do you use useMemo? | “For performance, to speed things up.” | Treats it as a trade-off, notes the compiler now covers most cases, and can say when it hurts. |
| Server or client component? | “Client, it’s more flexible.” | Splits the boundary by interactivity, keeps data fetching on the server, quantifies the bundle cost. |
| How do you handle a slow list? | “Memoize the rows.” | Reaches for virtualization first, measures before and after, knows memo is secondary. |
| Why not call hooks conditionally? | “It’s a rule, React doesn’t allow it.” | Explains call-order and the fiber that tracks hook state between renders. |
Notice what the strong column has in common. It’s never just the answer. It’s the answer plus the cost plus how they’d check. Calibrate the bar to the level and the comp band you’re paying for, and if you want a sanity check on that band before you interview, our salary benchmark assistant will give you a range by role and market.
How to Structure the React Interview Loop
Good questions in a bad loop still miss. A few things I’d hold to.
Kill the cold whiteboard algorithm round for React roles. It tests a skill the job barely uses. Replace it with a short, paid take-home that mirrors your actual stack, two to three hours, no trick requirements, followed by a live review of what they built. The take-home shows you their code. The review shows you their understanding, which is the part you can’t fake, the part an assistant can’t sit in for, and the part that matters most now that the first draft of almost everything arrives half-written by a model. Ask them to change something during the review. Watch how they move around their own codebase.
Keep it to four rounds. A recruiter screen, the take-home review, an architecture or system conversation for mid and senior, and a team-fit round. More than that and your best candidates take the competing offer while you’re still scheduling. If speed is the constraint and you want to see someone in the actual codebase before committing, a contract-to-hire arrangement lets you evaluate on real work, and a direct hire makes more sense once you’re certain. For the full cost picture on either path, we broke the numbers down in our guide to what it costs to hire a React developer.
If your loop also covers broader front-end or full-stack scope, the same house style carries over. We keep companion guides for front-end developer interview questions and full-stack developer interview questions, and if you’re earlier in the process and still writing the req, start with how to hire React developers.
What Hiring Managers Ask Us Before Building a React Loop
Should we still ask about class components in 2026?
Briefly, and mostly as a maintenance signal. Most modern React is hooks and function components, so a candidate who reaches for class components by default is a small yellow flag. But if your codebase still has legacy class components, you need someone who can read them without flinching, so ask whether they can, not whether they prefer them.
How do we test React skills without a whiteboard?
A paid take-home plus a live code review beats a whiteboard for React roles almost every time. The take-home mirrors real work and respects the candidate’s time. The review is where you probe. Have them explain a decision, change a requirement mid-call, and debug something small. You’ll see more real skill in that half hour than in any amount of marker-on-glass.
Our candidate leaned on AI for the take-home. Is that disqualifying?
No, and pretending otherwise is a losing battle. Every working developer uses AI now. What matters is whether they understand what it produced. The move is to review the submission live and ask them to defend and modify it. Someone who used AI as a tool can explain every line. Someone who used it as a crutch can’t, and that’s the distinction you actually care about.
Do we need someone who knows Next.js specifically, or is React enough?
Depends on your stack, but the honest answer for most teams is that Next.js fluency matters more than it did two years ago. Server Components, routing, and rendering strategy now live at the framework layer, so a “pure React” candidate may not have made the server-versus-client calls your app requires. If you’re on Next.js, test the framework decisions, not just the library.
How many rounds should a React interview be?
Four is the number I’d defend. A recruiter screen, a take-home review, an architecture conversation, and a team-fit round cover skill, judgment, and collaboration without dragging. Six-round loops mostly lose you the strong candidates, who have other offers moving faster than your calendar does.
Is contract-to-hire a smart way to de-risk a React hire?
Often, yes, especially for a first senior hire on a new team. Contract-to-hire lets you evaluate someone on real tickets in your real codebase before you commit to a full-time offer. It’s not the right fit for every candidate, since the strongest people sometimes want direct-hire security, but as a de-risking tool on an ambiguous role it works. We place both ways and can tell you which the market will bear for your role.
Hire React Developers Who Actually Understand React
The questions on this page won’t help if the loop feels like a trap. Use them to open a real conversation, not to spring a trap on a nervous candidate. The developers you want will light up when you ask them to defend a trade-off, because that’s the part of the job they enjoy. The ones who go quiet were always going to go quiet in your codebase too. Just later. And more expensively, once the offer’s signed and the onboarding’s done and some production incident lands on a Friday afternoon with nobody left in the room who can explain why the dashboard keeps re-rendering itself into the ground.
If you’d rather not build the whole loop yourself, that’s what we do. We’ve spent 20+ years placing engineers across 30+ U.S. metros, and we can hand you a shortlist that’s already been through a version of the interview above. Talk to a KORE1 recruiter and tell us what you’re building. We’ll bring you people who understand React, not just people who use it.