React Interview Questions for 2026: Hooks, Reconciliation, Keys, Controlled Inputs, and the Render-Performance Traps Interviewers Actually Probe

What React interview questions cover in 2026

React interview questions in 2026 cover four things in roughly this order: whether you understand the core hooks deeply enough to explain when they re-run, whether you can describe the rendering model (virtual DOM, reconciliation, keys) without hand-waving, whether you reason correctly about state and data flow (controlled vs uncontrolled inputs, Context vs an external store), and whether you can talk about render performance and SSR/hydration like someone who has shipped a slow page and fixed it. The hooks floor is non-negotiable. The trade-off layer is where the round is won or lost.

Here is the thing most new grads miss. The interviewer is not testing whether you can list what useEffect does. They are testing whether you know what breaks when you get it wrong. A candidate who can recite the hook signature but freezes on "what happens if you leave a value out of the dependency array" reads as someone who studied the docs but never shipped a bug and fixed it. That gap is the single biggest filter at the entry-level React interview.

What React interviews test in 2026

The 2025-2026 hiring cycle tightened, and frontend interviews tightened with it. React is still the dominant library for new-grad frontend and full-stack roles, which means the question bank is well-worn and interviewers have heard every memorized answer. The way you stand out is not by knowing more definitions. It is by reasoning about trade-offs out loud.

Distribution of React question types most new-grad candidates report seeing in their loops:

• 35-45% hooks (useState, useEffect, useMemo, useCallback, custom hooks, the rules of hooks)
• 20-30% rendering model (virtual DOM, reconciliation, keys, why a component re-renders)
• 15-25% state and data flow (controlled vs uncontrolled, lifting state, Context vs external store)
• 10-20% performance and SSR/hydration (wasted renders, memoization, hydration mismatch, code splitting)

Two patterns to notice. First, hooks dominate every loop, so the dependency-array and stale-closure failure modes are the highest-leverage thing to drill. Second, the performance and SSR slice is the one most candidates under-prepare, and it disproportionately decides senior-leaning rounds. A candidate who nails twelve hooks questions but cannot explain a hydration mismatch usually caps out at the entry tier. A candidate who reasons cleanly about wasted renders and measurement-first memoization reads as someone ready for real production work.

React is, at heart, a UI library that maps your application state to a description of the DOM, and then efficiently updates the real DOM to match. Almost every interview question is a different angle on that one sentence: how do you hold state (hooks), how does React turn state into DOM (reconciliation), how do you keep that mapping correct (keys, controlled inputs), and how do you keep it fast (memoization, SSR/hydration).

Key terms

Get these terms exactly right before the interview. Interviewers use precise definitions as a litmus test, and a fuzzy answer on any of these signals that you learned React by copying snippets rather than understanding the model.

Virtual DOM

A lightweight in-memory tree of plain objects describing what the UI should look like, which React diffs against the previous tree to compute the minimum real-DOM changes.

Reconciliation

The algorithm React runs to compare the new virtual DOM tree against the previous one and apply only the necessary mutations to the real DOM.

Key

A stable identifier on a list item that tells React which element is the same item across renders, so it can reorder and reuse DOM nodes instead of recreating them.

Controlled component

A form input whose value is driven by React state, making the component the single source of truth and re-rendering on every keystroke.

Stale closure

A bug where a function (often inside an effect or callback) captures an outdated value from an earlier render because that value was left out of the dependency array.

Hydration

The client-side step that attaches event listeners and state to server-rendered HTML, turning static markup into an interactive app without re-creating the DOM.

Three more terms you will need in the prose of your answers. Memoization is caching the result of an expensive computation or a function reference so it is reused across renders unless its inputs change, which is the job of useMemo and useCallback. Referential equality is whether two values are the same object in memory (===), which matters because React.memo and dependency arrays compare props and dependencies by reference, so a freshly created object or array counts as changed even when its contents look identical. Lifting state up is moving shared state to the closest common ancestor of the components that need it, so they read from one source of truth instead of holding diverging copies.

React hooks interview questions

Hooks are the bulk of any modern React loop. The questions below cover the four core hooks plus the failure modes interviewers love. Memorize the answer outlines, then say them in your own words.

Q1. What does useState return, and why are updates asynchronous?

useState returns a pair: the current state value and a setter function. Calling the setter schedules a re-render with the new value; it does not mutate the variable in place. Updates are batched and applied asynchronously, so reading the state variable immediately after calling the setter gives you the old value, not the new one. When the next value depends on the previous one, use the functional update form, which passes you the latest state, instead of reading the closed-over variable. The interview signal is knowing that React batches multiple setter calls in the same event into one render.

Q2. Walk me through useEffect: when does it run, and what is cleanup for?

useEffect runs a side effect after the component renders and commits to the DOM. The dependency array controls re-runs: the effect runs after every render with no array, once after mount with an empty array, and after any render where a listed dependency changed. The optional function you return from the effect is the cleanup; React calls it before the next run of the effect and on unmount. Cleanup is how you cancel a subscription, clear a timer, or abort a fetch so you do not leak resources or update an unmounted component. The classic mistake is forgetting cleanup on a subscription, which leaves listeners attached after the component is gone.

Q3. What is useMemo and when is it worth using?

useMemo memoizes the result of a computation. You pass a function and a dependency array, and React recomputes the value only when a dependency changes; otherwise it returns the cached value. Use it for a genuinely expensive calculation (sorting or filtering a large list, a heavy transform) or to keep a stable object or array reference so a memoized child or a dependency array downstream does not see a new reference every render. The honest framing: do not wrap every value in useMemo. The memoization itself has a cost, and for cheap computations it is slower than just recomputing. Measure, then memoize the proven hot path.

Q4. What is useCallback and how is it different from useMemo?

useCallback memoizes a function reference instead of a computed value. useCallback(fn, deps) is equivalent to useMemo(() => fn, deps). The point is referential stability: if you pass a callback down to a child wrapped in React.memo, a new function reference on every parent render would defeat the memoization and re-render the child anyway. useCallback keeps the reference stable across renders unless a dependency changes, so the memoized child correctly skips re-rendering. The interview signal is knowing that useCallback is pointless unless the function is a dependency somewhere or a prop to a memoized child; otherwise it adds cost for nothing.

Q5. What are the rules of hooks and why do they exist?

Two rules. Call hooks only at the top level of a component or a custom hook, never inside loops, conditions, or nested functions. And call hooks only from React function components or custom hooks, never from regular JavaScript functions. The rules exist because React tracks hook state by call order, not by name. If a hook is called conditionally, the order shifts between renders and React associates state with the wrong hook. The follow-up is usually "how would you do something conditionally then?" The answer is that the condition goes inside the hook, not around it.

Q6. How do you write a custom hook, and what makes it a hook?

A custom hook is a function whose name starts with use and that calls other hooks. It lets you extract and reuse stateful logic (a data fetch, a subscription, form handling) across components without a wrapper component. What makes it a hook is that it calls hooks and follows the rules of hooks; the use prefix is the convention that lets tooling enforce those rules. The interview signal is understanding that a custom hook shares logic, not state: two components calling the same custom hook each get their own independent state.

Q7. What is the difference between useMemo, useCallback, and React.memo?

useMemo caches a value. useCallback caches a function reference. React.memo is a higher-order component that wraps a component so it skips re-rendering when its props are referentially equal to the previous render. They work together: React.memo on the child, useCallback and useMemo on the parent to keep the props passed to that child referentially stable. Using React.memo without stabilizing the props is a common no-op, because the parent hands the memoized child fresh object and function references every render.

React rendering model questions: virtual DOM, reconciliation, keys

This bucket tests whether you understand how React turns state into DOM. Get the vocabulary precise; interviewers can tell memorized answers from understood ones in one follow-up.

Q8. What is the virtual DOM and why does React use it?

The virtual DOM is an in-memory tree of plain JavaScript objects describing what the UI should look like. When state changes, React builds a new virtual DOM tree, diffs it against the previous one, and computes the minimal set of real DOM operations to make the actual DOM match. Direct DOM manipulation is expensive because the browser may recalculate layout and repaint; batching changes through a diff lets React touch the real DOM as little as possible. The nuance worth stating: the virtual DOM is not automatically "fast," it is a way to make declarative UI updates manageable and usually-fast, and you can still write slow React by causing huge subtrees to re-render.

Q9. Explain reconciliation. How does React decide what to update?

Reconciliation is the diffing algorithm. React compares the new tree to the old one node by node. Two heuristics make it efficient. First, elements of different types produce different trees, so when an element's type changes React tears down the old subtree and builds a new one rather than trying to diff across types. Second, keys identify which children in a list are stable across renders, so React can match, reorder, and reuse them. Without these heuristics a general tree diff would be far more expensive. The interview-relevant takeaway is that you help reconciliation by keeping element types stable and giving list children stable keys.

Q10. Why do keys matter, and why is the array index a bad key?

Keys tell React which list items are the same item across renders. With stable keys (a unique ID from your data), React moves and reuses DOM nodes when a list reorders instead of recreating them, which preserves component state and DOM focus. Using the array index as a key breaks the moment the list can reorder, insert, or delete, because an item's index changes while its identity does not. The textbook bug: a list of inputs keyed by index keeps the wrong typed value after you delete or reorder a row, because React matched each input to a position, not to an item. Use a stable unique ID; reserve the index for a list that is static and never reorders.

Q11. What actually causes a component to re-render?

A component re-renders when its state changes, when its parent re-renders, or when a Context it consumes changes value. The one that surprises new grads is the parent case: when a parent re-renders, all of its children re-render by default, regardless of whether their props changed, unless they are wrapped in React.memo. Props changing is not what triggers a child re-render; the parent rendering is. This is why passing a fresh object or function to a memoized child still re-renders it, and why the fix involves referential stability, not just memoizing the child.

React state and data flow questions

This bucket separates candidates who learned React as "components and props" from those who understand where state should live.

Q12. Controlled vs uncontrolled components: what is the difference and when do you use each?

A controlled component drives its value from React state: the input reads value from state and writes to state in onChange, so React is the single source of truth. An uncontrolled component lets the DOM own its value, and you read it through a ref when you need it, typically on submit. Use controlled inputs when you need instant validation, conditional disabling, formatting as the user types, or to keep multiple fields in sync. Use uncontrolled inputs for simple forms, file inputs (which are always uncontrolled), or when re-rendering on every keystroke is a measurable cost. In 2026 most production forms use a controlled approach through a form library that manages the state and validation for you, so you get controlled behavior without re-rendering the whole form on every keystroke.

Q13. Context vs an external state library: how do you choose?

Context is dependency injection for the component tree. It is ideal for low-frequency, broadly-read values: theme, current user, locale, feature flags. The catch is that every consumer re-renders when the Context value changes, with no built-in way to subscribe to just a slice. An external store is built for frequent updates and selective subscription: components subscribe to the specific slice they read through a selector, so only the components that depend on a changed slice re-render. Choose Context when the value changes rarely and is read widely. Choose an external store when state changes often, when many components read different slices, or when you need selectors to avoid re-rendering the whole subtree on every change.

Here is the scenario table interviewers reason through, mapping a concrete state shape to the right tool:

The pattern: rarely-changing and widely-read goes in Context; fast-changing goes local or in a store with selectors; server data belongs in a cache library that handles loading, caching, and refetching for you.

Q14. What does "lifting state up" mean and when do you do it?

Lifting state up means moving shared state to the closest common ancestor of the components that need it, then passing it down as props (and passing setters down too). You do it when two sibling components must stay in sync, for example a search box and a results list that both depend on the same query. The opposite move, pushing state down, is the performance fix: if only one small subtree uses a piece of state, keep that state inside that subtree so changing it does not re-render the whole page. Knowing both directions, and that "where does this state belong" is a design decision, is the senior signal here.

React performance interview questions

Performance is the bucket that separates entry-tier from mid-level. The grading is on judgment: do you measure before you optimize, and do you understand why a memoization helps or does not.

Q15. How do you find and fix unnecessary re-renders?

Measure first. Use the profiler to find which components render most often and why. The most common cause is a parent passing a new object, array, or function reference to a child every render, which defeats React.memo on that child. Fixes in order: push state down so fewer components re-render, stabilize callbacks with useCallback and objects with useMemo, wrap genuinely pure children in React.memo, and use a selector so a component subscribes only to the slice it reads. The honest answer that lands in interviews: you do not memoize everything by reflex, because the memoization has overhead. You profile, find the hot path, and memoize that.

Q16. When is React.memo a no-op or even harmful?

React.memo skips a re-render only when the new props are referentially equal to the previous ones. If the parent passes a fresh inline object, array, or arrow function every render, the props are never referentially equal, so the memoized child re-renders anyway and you have paid the comparison cost for nothing. It is also wasteful on components that almost always receive changed props, or on trivially cheap components where the prop comparison costs more than the render it is trying to skip. The interview-relevant rule: React.memo pays off on an expensive child whose props are usually stable; pair it with useCallback and useMemo on the parent or it does nothing.

Q17. What is code splitting and why does it help frontend performance?

Code splitting breaks your bundle into smaller chunks that load on demand instead of shipping the entire app in one file. React supports it through lazy-loaded components and a fallback while a chunk loads, typically split by route so a user only downloads the code for the page they are on. It helps because the biggest frontend performance lever for a new grad is usually not render speed; it is how much JavaScript the browser has to download, parse, and execute before the page is interactive. Splitting the bundle shrinks that initial payload and improves time-to-interactive, which is the metric hiring teams increasingly ask about.

React useEffect dependency pitfalls

This deserves its own section because it is the single most-tested failure mode in React interviews and the one new grads get wrong most often.

Q18. What goes wrong with an incomplete dependency array?

The effect captures values from the render in which it was created. If you omit a value the effect reads, the effect keeps using the stale value from an earlier render even after that value changes; this is a stale closure. A timer that reads a count but lists no dependencies will forever log the count from mount. The fix has three flavors: list every value the effect reads, use the functional updater form of a setter so you do not need to read the current state at all, or restructure so the effect does not depend on the changing value. The wrong fix, which interviewers will catch, is silencing the lint warning instead of addressing why the value is missing.

Q19. Why does my effect run twice, and what should I do about it?

In development, React intentionally mounts, unmounts, and remounts a component once to surface effects that are not resilient to being run twice; this is a development-only check and does not happen in production. The right response is not to suppress it, but to write effects that clean up properly so running twice is harmless: cancel the in-flight fetch, clear the timer, unsubscribe. An effect that breaks when run twice in development is an effect that will break in production when a dependency changes and the effect re-runs for real. The double-run is a free test, not a bug to hide.

Q20. When should logic not be in an effect at all?

A common new-grad anti-pattern is using useEffect to transform props into state, or to respond to a user event. If a value can be computed during render from existing props or state, compute it during render instead of storing it in state and syncing it with an effect. If something should happen in response to a click, put it in the event handler, not in an effect that watches for the change. Effects are for synchronizing with systems outside React (the network, the DOM, a subscription, a timer), not for reacting to your own state changes. Knowing this trims half the effects out of a typical new-grad codebase and is a strong signal in an interview.

React SSR and hydration interview questions

Server-side rendering is increasingly part of frontend loops because the dominant React frameworks render on the server by default. You do not need to be an expert, but you need to explain hydration and its failure mode.

Q21. What is SSR and why do teams use it?

Server-side rendering generates the HTML for a page on the server and sends it to the browser fully formed, instead of sending a near-empty HTML file and building the page entirely with client JavaScript. Teams use it for two reasons: the user sees content sooner because the markup arrives ready to display, and crawlers and link previews get real HTML instead of an empty shell, which matters for SEO. The trade-off is server cost and complexity, plus the hydration step on the client. The interview signal is knowing that SSR sends HTML first and interactivity second, and that the gap between those two is where most SSR bugs live.

Q22. What is hydration and what is a hydration mismatch?

Hydration is the client-side step where React takes the server-rendered HTML and attaches event handlers and state to it, making it interactive without re-creating the DOM. A hydration mismatch happens when the markup React produces on the client during that first render does not match the HTML the server sent. React detects the mismatch, discards the server markup for that subtree, re-renders it on the client, and logs a warning. Common causes: rendering a timestamp, a random value, or anything based on Date.now() on first render; reading window, document, or localStorage during the initial render when they do not exist on the server; or branching output on whether code runs on the server vs the client.

Q23. How do you fix a hydration mismatch?

Make the first client render produce byte-identical output to the server, then change it after mount. For browser-only values, render a neutral placeholder on the server and the first client render, then read the real value in a useEffect (which runs only on the client, after hydration) and update. For values that are inherently different between server and client, defer them until after mount so they never participate in the hydration comparison. The principle interviewers want: the server render and the first client render must agree; anything that can only be known in the browser happens after hydration, not during it.

How to prepare for React interview questions

A focused two-to-three-week plan, calibrated for a CS new grad who has built React side projects but never shipped a production frontend. The steps match the structured plan in this guide's summary.

1. Build one small app that touches every core concept. A list with stable keyed items, a controlled form with validation, a useEffect that fetches with cleanup, one useMemo for a genuinely expensive computation, and a Context provider for theme or user. The point is not the app; it is that every answer becomes a thing you shipped instead of a thing you read.

2. Drill the useEffect dependency array and stale closures cold. Write an effect that omits a dependency it reads, watch the stale value, then fix it three ways: add the dependency, use the functional updater form of the setter, and move the logic out of the effect. If you can teach this to a rubber duck without notes, you have covered most hooks follow-ups.

3. Master the rendering model. Read one clear explanation of reconciliation, then prove it: render a list with index keys, reorder it, watch a controlled input keep the wrong value, swap to stable ID keys, watch the bug vanish. Write a paragraph on why the virtual DOM diff beats touching the real DOM directly.

4. Rehearse performance and SSR/hydration trade-offs out loud. When you reach for React.memo, useMemo, and useCallback, and why measuring beats memoizing by reflex. What a hydration mismatch is, what causes it, and how you fix it. Lead with the decision, then the reason.

5. Drill controlled vs uncontrolled and Context vs external state. Build both form versions. Take one fast-changing value and one slow-changing value and decide where each belongs. Be ready to explain why keystrokes do not go in Context.

6. Run one timed mock interview and narrate your reasoning. Forty-five minutes mixing a hooks bank, one rendering-model question, one controlled-input question, and one performance or hydration question. Narrate the whole time, because frontend interviews grade how you think. If you want to rehearse these out loud against live follow-ups and hear an answer outline you can then say in your own words, run a mock React round in the live interview assistant before the real one.

The non-negotiable step is the first one. Interviewers can tell within a couple of follow-ups whether you have shipped React or only read about it, and the fastest way to sound like you have shipped it is to have actually built the small app you are describing.

Common React interview mistakes

The mistakes that sink the most new-grad React interviews in the 2025-2026 hiring cycle, in roughly the order of frequency:

• Reciting what a hook does without explaining when it re-runs. "useEffect runs side effects" is a definition, not an answer. The fix: always pair the definition with the dependency-array behavior and the stale-closure failure mode, because that is what the follow-up will probe.
• Using the array index as a key. It works in a demo and breaks the moment the list reorders or items are deleted. The fix: use a stable unique ID from your data, and be ready to explain the input-keeps-wrong-value bug that index keys cause.
• Memoizing everything by reflex. Wrapping every value in useMemo and every function in useCallback adds overhead and signals that you do not understand referential equality. The fix: say you profile first, then memoize the proven hot path, and that React.memo is a no-op without stable props.
• Putting fast-changing state in Context. Treating Context as "global state" for everything re-renders the whole subtree on every keystroke. The fix: Context for rarely-changing, widely-read values; local state or a store with selectors for anything that updates often.
• Treating useEffect as a catch-all. Using effects to derive state from props or to respond to clicks. The fix: compute derived values during render, handle events in handlers, and reserve effects for synchronizing with systems outside React.

One thing I would add from watching new grads run React rounds: do not try to memorize all five fixes the night before. Pick the two that match your weak spots (almost always the dependency array and the Context-overuse trap) and close those. Walk into your React round able to say the answer to those two cold, and the rest follows from the small app you built. If you want on-demand React scenarios with a quiet answer outline to react to so the rep cost is a coffee instead of a friend's afternoon, a live interview assistant you can start for a $3 trial gives you exactly that.

Related guides

• Angular interview questions: the other dominant frontend framework, useful if you are interviewing across both ecosystems or want to contrast the component models.
• Python interview questions: the language most React backends and full-stack roles pair with, and a common second round in full-stack loops.
• System design basics for new grads: the framework for the frontend-system-design and architecture rounds that sit alongside React component questions.
• Technical phone screen tactics: the round that tests React knowledge under live observation, where narrating your reasoning matters as much as the answer.

About the author: Sam K. is the founder of InterviewChamp.AI, building AI interview prep for the new-grad CS market and writing about the modern interview gauntlet from the inside.