React Developer Interview Questions and Answers 2026

React interviews have quietly moved on. A decade of tutorials taught everyone to recite the difference between props and state, and interviewers stopped finding that useful somewhere around 2021. What they ask now is harder and more honest: what does React actually do when you call a setter, why is this list re-rendering, where does this data belong, and what breaks when you put it in the wrong place. Here are the questions you will genuinely face, what each is probing, and how a strong answer is built.

These are the patterns for the role in general; if you want the shortlist for one specific interview, paste the actual job posting into the free Question Predictor and it returns the twenty questions that posting is most likely to produce.

What do React interviews actually test in 2026?

Four things, in roughly this order: whether you understand the rendering model rather than the API surface, whether you put state in sensible places, whether you can find a performance problem with evidence instead of guesswork, and whether you write code someone else can test. Trivia has largely been replaced by tradeoff reasoning, because tooling writes the boilerplate either way.

• Hooks under scrutiny: the closure behaviour that trips people up, and knowing when an effect is the wrong tool.
• The rendering model: what triggers a render, what reconciliation does with the output, why keys matter.
• State architecture: local versus lifted versus context versus a store, and the split between server state and client state.
• Performance with measurement: diagnosing in the Profiler rather than sprinkling memoisation and hoping.
• Testing sense: what you test, at what level, and whether you handle loading, empty, and error states unprompted.

Seniority changes the weighting, not the topics. Mid-level candidates reason correctly about one component. Senior candidates reason about a codebase: conventions, boundaries, migration paths, and what they would refuse to do.

What does the React developer interview process look like?

Four or five stages: a recruiter screen, a technical screen with live coding, a longer build round, a React deep dive, and a behavioural round. Larger companies add frontend system design. The build round and the deep dive decide the offer, so weight your preparation there rather than spreading it evenly.

1. Recruiter screen (20 to 30 minutes). Availability, salary, a summary of your last two roles.
2. Technical screen (45 to 60 minutes). A shared editor, a small component or a debugging exercise, sometimes plain JavaScript to check the foundation underneath the framework.
3. Build round (60 to 90 minutes). Something real: a filterable table, an autocomplete, a multi-step form against a fake API. Scored on state placement, edge cases, and whether you talk while you work.
4. React deep dive (45 to 60 minutes). Rendering, hooks internals, state choices, performance, and increasingly server components.
5. Behavioural round (45 minutes). Disagreements, code review, mentoring, and how you handle a spec that makes no sense.

Take-homes are declining, largely because interviewers know they get completed with AI assistance. Where one survives, it is nearly always followed by a live session extending your own submission, which is the part worth preparing for.

Which React hooks questions come up in almost every interview?

Four recur constantly: stale state in a closure, what the dependency array controls, the difference between the memoisation tools, and writing a custom hook on the spot. All four test the same underlying thing, which is whether you know that a component function runs many times and each run captures its own values.

1. "This click handler logs the old count. Why?" What it probes: whether you understand that each render closes over that render's values, and that a setter does not mutate a variable in place. Name the closure explicitly, then show both fixes: the functional updater setCount(c => c + 1), and a ref when you genuinely need the latest value inside a long-lived callback.

2. "What does the dependency array control, and when should you not use an effect at all?" What it probes: whether you treat effects as a general lifecycle hook (the junior tell) or as synchronisation with something outside React. The array decides when the effect re-runs; the cleanup runs before the next run and on unmount. Then name what should not be an effect: derived values (compute during render), state that resets on a prop change (a key on the child), and event responses (handle them in the handler).

3. "useMemo, useCallback, React.memo: what is the difference?" What it probes: whether your memoisation is measured or superstitious. useMemo caches a value, useCallback caches a function reference, React.memo skips a child re-render when props are shallow-equal, and the first two are pointless unless a memoised child or another dependency list consumes the reference. Add that memoisation has its own cost, so you profile first.

4. "Write a hook that debounces a value." What it probes: composition, cleanup, and dependency discipline in about ten lines. State for the debounced value, an effect that sets a timer, a cleanup that clears it, dependencies on the value and the delay. The part most candidates miss: the cleanup is what makes it a debounce rather than a queue of pending updates.

How do interviewers test rendering and reconciliation?

By asking what happens after a state update, not before it. A strong answer separates three phases: React re-runs the component to produce an element tree, reconciliation diffs that tree against the previous one, and the commit phase applies the minimum set of DOM mutations. Candidates who blur those phases cannot explain keys, effect timing, or concurrent features.

5. "Walk me through what happens when I call a state setter." What it probes: mental model depth. The update is queued and batched with others in the same tick, React schedules a render, the component and its children re-run, the new tree is reconciled with the old, previous effects are cleaned up, DOM mutations are committed, then layout effects run synchronously and passive effects after paint. Add that Strict Mode double-invokes in development to expose effects that are not cleanly reversible.

6. "Why do keys matter, and what goes wrong with array indexes?" What it probes: whether you have actually debugged a list. Keys tell reconciliation which element corresponds to which item across renders. With index keys, deleting or reordering makes React match the wrong items, so component state and DOM state (a focused input, a half-typed value) attach to the wrong row. Add the flip side: changing a key deliberately is a legitimate way to reset a subtree.

7. "What are useTransition and useDeferredValue for?" What it probes: awareness that rendering can be interruptible. Both keep an urgent update (typing) responsive while a heavy update renders at lower priority: useTransition marks the state update as non-urgent and gives you a pending flag, useDeferredValue lets a value lag behind. Say plainly that neither makes slow rendering fast, they only change what the user waits on.

What state management questions should I expect?

Two, reliably: where a piece of state belongs, and how you treat server data differently from client data. The expected answer starts from local state, treats context as a delivery mechanism for low-frequency values rather than a store, and puts anything that came from an API behind a caching layer.

8. "Context or a state library, and how do you choose?" What it probes: whether you know what context costs. Local state first, lift only as far as the nearest common parent, context for values that change rarely and are read widely (theme, locale, the current user), and a store when updates are frequent or read across unrelated subtrees. The reason matters: every consumer re-renders when the context value changes, so a fast-moving value in context is a performance bug waiting to be filed.

9. "How do you handle server state?" What it probes: whether you have shipped anything with real data. Server data is a cache of something you do not own, so it needs deduplication, staleness rules, background revalidation, and invalidation after a mutation, and hand-rolling that in effects goes wrong slowly. Name the pattern rather than only the library: fetch on the server where the framework allows, cache on the client, keep local UI state separate.

How are React performance questions asked in practice?

As a scenario with a symptom, not as a definition. You get "typing in this filter box is laggy" or "this page takes four seconds to become interactive", and the interviewer watches whether you measure before changing anything. Reaching straight for useMemo is the wrong opening move; opening the Profiler and asking what is re-rendering is the right one.

10. "Typing in a search box that filters ten thousand rows is janky. Diagnose it." What it probes: method. Record with the React Profiler and the browser performance panel, and establish whether the cost is many components re-rendering or one component rendering many nodes. If it is node count, virtualise; if it is re-render breadth, colocate the input's state so the tree above it stays put, then memoise the row; if the filter itself is expensive, memoise or defer it.

11. "The bundle is too big. What do you do?" What it probes: whether you have ever opened a bundle analyser. Measure first, then route-level splitting with lazy and Suspense, dynamic imports for heavy widgets (editors, charts, date pickers), replacing an oversized dependency, and moving work to the server where the framework supports it. Tie it to a metric the business cares about, usually LCP or interaction latency, rather than to kilobytes for their own sake.

12. "Does the React compiler make manual memoisation obsolete?" What it probes: whether you follow the ecosystem and can hold a nuanced position. Automatic memoisation removes most of the routine useMemo and useCallback noise, which is a genuine improvement, but it does not fix state placed too high, a context that is too broad, an unvirtualised list, or an expensive effect. Say what you would still do by hand and what you would happily delete.

What do React testing questions look like?

Usually one scenario plus a question about proportion. Interviewers want tests that exercise behaviour through the surface a user touches, the network mocked at the boundary rather than by stubbing your own modules, and an honest split: unit tests for pure logic, component-level integration tests for the bulk of the UI, and a thin layer of end-to-end tests over the flows that lose money when they break.

13. "How do you test a component that loads data and shows a list?" What it probes: whether your tests survive refactors. Render the component, mock at the network layer, query by accessible role and name, then assert the loading state, the loaded rows, the empty state, and the error state. Avoid asserting on props or hook internals, and mention flakiness: awaited queries rather than arbitrary timeouts.

Do interviewers ask about React Server Components?

Increasingly, yes, mostly to check you understand the boundary rather than to test framework trivia. You should be able to say what runs where, what a server component cannot do, and where the common hydration and caching mistakes come from. Being honest about limited hands-on experience is fine; pretending is not, because the follow-up will find you out.

14. "What is the difference between a server component and a client component?" What it probes: the boundary. Server components run on the server, await data directly, never ship their code to the browser, and cannot use state, effects, or event handlers; client components hydrate in the browser and can do all three. The "use client" directive marks an entry point into client territory, so everything imported below it goes client-side too, which is why one careless directive near the top of a tree wipes out the benefit.

15. "Where do you fetch data, and what are the caching gotchas?" What it probes: production scars. Fetch on the server, close to where the data is rendered, and let the framework deduplicate identical requests within a render. The gotchas worth naming: accidental static rendering of something that should be dynamic, stale data after a mutation because nothing revalidated, and hydration mismatches from rendering a timestamp during the server pass.

What mistakes get React candidates rejected?

Mostly process failures rather than knowledge gaps. Interviewers rarely reject someone for not knowing a hook; they reject the candidate who worked in silence, guessed at a fix, and left the error state unhandled. These six account for most of the no-hire feedback in React loops.

• Coding in silence. In the build round the running commentary is most of the signal.
• Reaching for an effect first. Fetching, deriving, and syncing state in effects when something simpler exists is the commonest architectural tell.
• Memoising without measuring. Interviewers ask "what did that improve" precisely because most candidates cannot answer.
• Ignoring the unhappy path. Loading, empty, and error states are what gets poked at. Cover them unprompted.
• Stopping at the definition. "useCallback memoises a function" is where the interesting half of the answer starts.
• Overclaiming on server components. Stumbling on the client boundary costs more than admitting you have shipped one project.

How should I prepare for a React interview?

Build two things rather than reading about ten. A filterable, sortable table with server-side pagination forces you through state placement, caching, keys, and virtualisation. A multi-step form with validation and a real submission forces you through uncontrolled inputs, error handling, and focus management. Between them they generate honest answers to most of the questions above, and honest answers survive follow-ups.

Then profile something real. Open the Profiler on an app you work on, find the component that re-renders most, and fix it properly, because that gives you a story with numbers in it. For the fundamentals underneath the framework, the frontend developer interview questions guide covers the JavaScript and browser material the technical screen still gates on, and at a large employer their company question bank is worth a skim for house patterns.

Then rehearse against the right list: run the job posting through the free Question Predictor so the twenty questions you practise aloud are the ones that team is likely to ask, rather than a generic set.

Where a live copilot fits

Preparation covers most of it, and then a question lands sideways at minute forty and your mind goes flat. GhostPilot AI is a real-time copilot for that moment: it runs in a Chrome extension side panel or as a Windows desktop app, listens to the call, catches the question, and has a structured answer ready about two seconds later, which is usually all it takes to turn a blank pause into a clean opening sentence. The free tier includes 10 minutes of live session a week, no card. It is a backstop for a memory blank, not a replacement for knowing your own work.

FAQ

How long should I prepare for a React developer interview? Two to three weeks of focused practice if you write React daily. If you have been maintaining a legacy class-component codebase, budget four to six weeks, mostly to get comfortable with hooks-era patterns, server state, and the current rendering vocabulary.

Do React interviews still include algorithm questions? Some do, particularly at large companies with a standardised loop. The trend at product companies is firmly towards building and debugging real components. Keep basic data structures warm, but spend the bulk of your time on practical UI work.

How much do I need to know about React Server Components? Enough to explain the boundary confidently and name the common mistakes. Deep hands-on experience is a bonus for most roles rather than a requirement, unless the posting centres on a framework built around them.

Should I mention that I use AI tools to write React? Yes, if asked, and say how you review the output. Interviewers assume it. What they are checking is whether you can defend and debug the code, which is exactly why the deep-dive follow-ups have got harder.