A React question bank sorted by what the interviewer is actually checking

On 6 September 2026 I opened the official React 19 release notes at react.dev and counted the headline changes: Actions, the new use API, ref as a prop on function components, and Server Components moving from experimental to documented. Most React interview questions floating around the internet still test for class components and componentDidMount, which tells you those lists were written for 2019, not for a codebase anyone is actually shipping now.

This is a bank of React interview questions sorted by what the interviewer is actually probing, not by topic labels that sound good in a table of contents. Each one comes with a short model answer and the follow-up question that usually comes next, because the follow-up is where candidates who memorized an answer fall apart. No fluff. Just questions, answers, and the traps.

React interview questions on rendering and reconciliation

Q: How does React decide whether to re-render a component?
A parent re-rendering re-renders its children by default, regardless of whether their props changed, unless the child is wrapped in memo or the parent’s render is skipped some other way. React then diffs the returned element tree against the previous one using its reconciliation algorithm, which compares elements by type and key at each level rather than doing a full tree comparison.

Follow-up: Why does changing a list item’s key from an index to a stable ID matter? Because index-based keys tell React two different pieces of data are “the same” component instance across a reorder, which causes state to attach to the wrong row. A stable ID keeps the identity correct even when the array shuffles.

Q: What’s the difference between the virtual DOM and the real DOM update?
The virtual DOM is a plain JavaScript object tree describing what the UI should look like. React computes the difference between two virtual DOM snapshots, then applies only the minimal real DOM mutations needed. It’s a batching and diffing strategy, not magic, and it exists because direct DOM manipulation is expensive relative to comparing objects in memory.

React interview questions on hooks and their traps

Hooks are where most React interview questions live these days, and they’re also where the shallow-looking bugs hide. Here are the two that trip up candidates who’ve only skimmed the docs.

Q: Why does this useEffect run twice in development?
React 18 and 19 intentionally mount, unmount, and remount components once in Strict Mode during development to surface effects that aren’t properly cleaned up. If your effect breaks under that double-run, it would have broken in production too under concurrent rendering. It’s not a bug in React. It’s React telling you your cleanup function is missing or wrong.

Follow-up: When would you reach for useLayoutEffect instead of useEffect? When you need to read layout (like an element’s measured height) and synchronously mutate the DOM before the browser paints, to avoid a visible flicker. Almost everything else belongs in useEffect.

Q: What’s the stale closure problem, and how do you fix it?
A callback or effect captures a variable’s value at the time it was created, and if that callback runs later without the dependency array updating, it reads an outdated value. Fixing it means either adding the missing dependency, using a functional state update (setCount(c => c + 1) instead of setCount(count + 1)), or reaching for a ref when you deliberately want to read the latest value without re-triggering the effect.

Plenty of candidates fix this correctly and still stumble on the follow-up, because they can’t explain why the bug happened in the first place. Knowing the fix isn’t the same as understanding the closure.

State management React interview questions

Q: When do you reach for Context instead of a state library?
Context works well for low-frequency updates, like theme or authenticated user, where every consumer re-rendering on every change isn’t a real cost. It gets expensive fast for high-frequency state, like form input or a live cursor position, because every component reading that context re-renders on every update with no built-in way to select a slice of it.

Follow-up: How would you avoid that re-render cost while still using Context? Split the context into smaller providers scoped to what actually changes together, or pair Context with a reducer and memoize the consumers, or just accept that this is the exact case a dedicated state library like Zustand or Redux Toolkit was built to solve.

Q: What’s actually different about React 19’s Actions and useActionState?
The official React 19 notes describe Actions as automatically managing “pending state, error handling, forms, and optimistic updates,” replacing a pattern that used to require three or four separate useState calls wired together by hand. useActionState wraps a function and returns the pending state and result alongside it, which collapses form-submission boilerplate that used to be a common interview pain point in itself.

Performance

Q: A list of 2,000 rows is janky on scroll. Walk me through how you’d diagnose it.
Open the Profiler first, not the code. Check whether every row re-renders on state changes unrelated to that row, which usually points to missing memoization or a parent passing a new inline object or function as a prop on every render. Then check whether you’re rendering all 2,000 DOM nodes at once instead of only the visible slice.

Follow-up: What’s the actual fix, in order of effort? Cheapest first: stop creating new object or array literals inline in JSX. Next: wrap the row component in memo, with a custom comparison if the default shallow check isn’t enough. Last resort, and often the real fix at 2,000 rows: windowing, rendering only what’s visible with something like react-window.

React interview questions on memoization

Q: What does useMemo actually save you, and when is it a net loss?
It skips recomputing an expensive value between renders when its dependencies haven’t changed. It’s a net loss when the computation is cheap, because the memoization bookkeeping (dependency comparison, cache storage) costs more than just recalculating a simple value. Overusing useMemo everywhere is its own interview red flag. It says you’ve memorized the hook, not the tradeoff.

Q: What does React Compiler change about how you’d answer the last two questions?
React’s compiler, stable as of the React 19 cycle, auto-memoizes components and values where it can prove it’s safe, which means a codebase that adopts it needs far fewer manual memo and useMemo calls. It doesn’t remove the need to understand why memoization exists. It just moves the mechanical part of applying it out of your hands, so the interview question shifts from “how do you memoize this” to “why would the compiler not be able to memoize this safely.” Closures over mutable values and conditional hook calls are the usual answers.

React interview questions on testing

Q: Why does React Testing Library push you toward querying by role and text instead of by class name or test ID?
Because tests that query implementation details break when you refactor markup without changing behavior, and tests that query by what a user actually sees or clicks keep passing through refactors while still catching real regressions. The library’s own query priority guide ranks getByRole above every other query for exactly this reason, and it forces the test to mirror how someone using assistive technology would find the element, which is a genuine accessibility check disguised as a testing convention.

Follow-up: How do you test a component that fetches data on mount? Mock the fetch layer, render the component, then use findBy queries (which wait for an element to appear) rather than getBy queries (which throw immediately), because the loading state genuinely exists between mount and the data arriving.

One question that separates a strong candidate from a memorized one

Q: If you were starting a new mid-sized app today, would you reach for Redux? There’s no single correct answer, and a good interviewer knows it. What they’re checking is whether you can reason about scale rather than repeat a framework’s marketing copy. My honest take: for most apps under maybe fifteen or twenty screens, Context plus a couple of well-placed reducers gets you further than Redux Toolkit does, and I’d rather defend that opinion in an interview than recite “it depends” and say nothing else. Somebody will disagree with me on this, and that’s fine. A confident, specific, defensible opinion beats a hedge every time in this particular question.

If you want the broader loop this question bank sits inside, our frontend developer interview questions guide covers CSS, browser fundamentals, and the parts of a frontend loop that never touch React at all. For the systems-level questions that show up once a role expects you to design the app’s data layer, not just write components, see our system design interview guide.

What I don’t have a good answer for yet: how much React Server Components knowledge shows up in a typical mid-level interview loop right now, versus how much is still Next.js-specific trivia that only matters at companies already on the App Router. If you’ve been asked about it recently, I’d genuinely like to know which side of that line it fell on.