40 React Interview Questions and Answers (2026 Edition)

React interviews in 2026 no longer stop at props, state, and the Virtual DOM. React 19 shipped Actions, useActionState, and ref as a regular prop. React 19.2 followed with useEffectEvent, the Activity component, and cacheSignal. The React Compiler went stable in October 2025, and interviewers now expect you to know what it changes about the code you write, not just what it is.

These 40 questions cover both layers: the fundamentals every candidate is still expected to know cold, and the React 19 / 19.2 specifics that separate someone reciting 2022 answers from someone who actually ships current React. If you are also interviewing for full-stack or Next.js roles, our Next.js interview questions guide pairs directly with the Server Components material here.

Fundamentals questions test whether you understand the model React is built on, not whether you've memorized API names. Expect these in every interview regardless of seniority.

React is a JavaScript library for building user interfaces out of reusable components. It is not a full framework: it handles the view layer and leaves routing, data-fetching conventions, and build tooling to the ecosystem or to a framework like Next.js.

Companies still pick it because the hiring pool is enormous, the component model scales from a single form to a full application, and the ecosystem (React Query, Zustand, React Router) covers almost every problem you'll hit. In 2026 the pitch is stronger than ever because the React Compiler removes most manual performance tuning, and Server Components let you keep data-fetching code on the server without a separate API layer.

JSX is a syntax extension that lets you write HTML-like markup inside JavaScript. It never reaches the browser as-is. A compiler (Babel or the TypeScript compiler) transforms JSX into React.createElement calls, or in newer setups, into calls against the automatic JSX runtime.

The browser only ever sees plain JavaScript function calls that build up a tree of objects describing your UI.

The Virtual DOM is a lightweight JavaScript object tree that mirrors the real DOM. When state changes, React builds a new Virtual DOM tree, diffs it against the previous one, and applies only the minimal set of real DOM operations needed. This is still exactly how React works today.

The React Compiler doesn't replace the Virtual DOM. It reduces how often components re-render and re-diff in the first place by auto-memoizing values and skipping unnecessary render calls. The two systems solve different problems: the Virtual DOM makes each render cheap, the compiler reduces how many renders happen.

Props are read-only data passed down from a parent component to a child. A component can never modify its own props. State is data owned and managed by a component itself, typically through useState or useReducer, and it can change over time in response to user actions or events.

When state changes, the component re-renders. When props change, it's because the parent re-rendered and passed new values down. Props flow down, state lives locally, and this one-directional flow is what makes React apps predictable to debug.

A controlled component has its value driven entirely by React state: you set the value prop and update it in an onChange handler. An uncontrolled component keeps its own internal DOM state and you read it out only when needed, usually with a ref.

Controlled components give you full control for validation and conditional logic, but require a re-render on every keystroke. Uncontrolled components are faster for very large forms because typing doesn't trigger React renders at all. Since React 19, this decision matters less for simple forms because Actions and the form action prop can read FormData directly without wiring up controlled state at all.

The key prop tells React's reconciler which array item is which across renders, so it can correctly match, reorder, insert, or remove DOM nodes instead of tearing everything down and rebuilding it.

Without a stable key, React falls back to matching by index position, which breaks badly the moment you insert or remove an item from the middle of a list: inputs can lose focus, and component state can attach to the wrong row. The fix is always the same: use a stable, unique identifier from your data, like a database id, never the array index unless the list is static and never reordered.

Prop drilling is passing a prop through several layers of components that don't use it themselves, just so a deeply nested child can access it. It's not wrong, just annoying to maintain.

In 2026 you have three realistic options depending on scope: useContext for values that change rarely (theme, current user, locale), a state management library like Zustand or Jotai for frequently-updating shared state, or component composition, passing already-rendered JSX as children so you skip the layers entirely. Context is not a performance tool by itself; every consumer re-renders when the context value changes, so pair it with memoization or split contexts by concern.

Reconciliation is the process React uses to figure out what changed between two Virtual DOM trees and what real DOM updates are actually needed. Instead of a full tree comparison, which would be too slow, React uses heuristics: it assumes elements of different types produce different trees and tears them down completely, and it uses the key prop to match items within a list.

This turns an expensive general tree-diff problem into a fast, linear-time comparison that's good enough for real UI trees, where siblings rarely reorder wildly and element types rarely change unpredictably.

Hooks questions test whether you understand the mental model behind them, not just which hook to reach for. Expect follow-up questions asking why a hook works the way it does, not just what it does.

Hooks must be called at the top level of a component or custom hook, never inside loops, conditions, or nested functions, and only from React function components or other hooks.

The reason is that React tracks hooks by call order, not by name: it keeps an internal list per component and matches the nth useState call on this render to the nth useState call on the last render. If a hook call is conditional, that order can shift between renders and React ends up reading the wrong stored state for the wrong hook.

The ESLint plugin for hooks catches almost all violations automatically, and it's the same plugin the React Compiler depends on to verify your code is safe to auto-memoize.

useEffect runs asynchronously after the browser has painted the screen, so the user sees the UI update first and the effect runs after. useLayoutEffect runs synchronously after DOM mutations but before the browser paints, blocking the paint until it finishes.

You reach for useLayoutEffect only when you need to measure the DOM (like an element's height) and make a visual change before the user has a chance to see a flicker: things like tooltip positioning or scroll restoration. For anything else, including data fetching, subscriptions, and logging, useEffect is the right and more performant default.

useEffectEvent, added in React 19.2, lets you pull a callback out of an effect so it always reads the latest props and state without being a dependency that forces the effect to re-run.

Before this hook, a common problem was a useEffect that connects to a chat room and also needs the current theme to show a notification. Theme has nothing to do with when to reconnect, but leaving it out of the dependency array meant reading a stale value, and including it meant reconnecting every time the theme changed.

useEffectEvent solves this cleanly: you wrap the notification logic in useEffectEvent, call it from inside the effect, and it's excluded from the dependency array by design because it's not treated as reactive.

Activity is a component that lets you keep part of your UI mounted but hidden, instead of unmounting it. In hidden mode, React unmounts the component's effects and defers its updates until the browser is idle, but keeps its state and DOM structure intact.

This is useful for tab interfaces, multi-step wizards, or side navigation panels where switching back and forth should be instant and preserve exactly what the user had typed or scrolled to, without refetching data or losing input focus. It's a direct upgrade over conditionally rendering with {isVisible && <Component />}, which fully destroys and rebuilds state on every toggle.

React batches multiple state updates that happen within the same event handler or the same tick into a single re-render, rather than re-rendering after each individual setState call.

Since React 18, this batching applies automatically everywhere: inside promises, setTimeout callbacks, native event handlers, and not just inside React's own synthetic event handlers, which was the old React 17 limitation. If you genuinely need to force a synchronous update outside of batching, flushSync from react-dom exists, but you should treat reaching for it as a signal to double check your logic first.

useReducer manages state through a reducer function that takes the current state and an action, and returns the next state, similar to Redux's core pattern but scoped to a single component or custom hook.

It's the better choice when state updates depend on multiple related fields, when the next state depends heavily on the previous state in non-trivial ways, or when you have many possible state transitions that are easier to read as named actions than as a pile of individual setState calls scattered across handlers.

useMemo caches the result of an expensive calculation between renders and only recomputes it when its dependencies change.

With React Compiler 1.0, which went stable in October 2025, the compiler automatically inserts this kind of memoization for you at build time in components that follow the Rules of React, so most new code doesn't need manual useMemo calls at all. You should still reach for it manually when a value's referential identity is a hard correctness requirement, such as an effect dependency, or when you're working with a codebase that isn't running the compiler yet.

useCallback returns a memoized version of a function itself, so the same function reference is reused across renders as long as its dependencies don't change. useMemo memoizes the return value of a computation.

They're built on the same mechanism: useCallback(fn, deps) is functionally equivalent to useMemo(() => fn, deps), but useCallback exists as a clearer, more readable API specifically for the common case of passing stable callbacks to child components or effect dependencies.

A custom hook is a plain JavaScript function that calls other hooks internally and lets you extract and reuse stateful logic across components: things like useDebounce, useLocalStorage, or useFetch.

The naming rule is strict: it must start with use so React's linter and the React Compiler can identify it as a hook and enforce the Rules of Hooks on it. A function that doesn't call any hooks internally shouldn't be named with a use prefix, because that misleads both the linter and other developers reading your code.

useRef returns a mutable object with a .current property that persists across renders without triggering a re-render when it changes.

Beyond grabbing a reference to a DOM node for focus management or measurements, it's commonly used to store any value you want to persist between renders but don't want to trigger a re-render: a previous prop value for comparison, a timer ID for cleanup, or a flag tracking whether a component has mounted yet.

useTransition lets you mark a state update as non-urgent, telling React it can be interrupted by more urgent updates like a keystroke, and can render a pending indicator (isPending) while the transition is in progress.

Debouncing delays firing an update until the user stops interacting for a set amount of time: it changes when the work happens. useTransition doesn't delay anything; it changes how the work is prioritized, letting React keep the input responsive while a lower-priority re-render, like filtering a large list, happens in the background without blocking the UI thread.

useOptimistic lets you show a temporary, optimistic state immediately in response to a user action, before the actual async operation (usually a server request) has finished. If the action succeeds, React reconciles the optimistic value with the real result. If it fails, you handle rolling it back.

It's built for exactly the kind of UI where a Twitter-style like button, a comment being posted, or an item being added to a cart should feel instant rather than waiting on a network round trip before showing any feedback.

This is the section that separates candidates who kept up with React from candidates repeating 2022 answers. Actions, Server Components, and the compiler are the organizing ideas behind everything React shipped in 2025 and 2026.

An Action is an async function passed to a transition, typically through a form's action prop, useActionState, or manually with startTransition. React takes over managing pending state, error handling, optimistic updates, and resetting uncontrolled form fields after a successful submission: all the plumbing developers used to hand-write around every onSubmit handler.

Actions are the organizing idea behind React 19: useActionState, useFormStatus, and useOptimistic are really three different views onto the same underlying mechanism.

React 19 lets you pass a function directly to a form's action prop, or to a button's formAction prop. React calls that function with a FormData object when the form submits, runs it inside a transition automatically, and resets uncontrolled inputs on success without you writing any manual reset logic.

useActionState takes an action function and an initial state, and returns the current state, a wrapped action to pass to your form, and a pending boolean.

It replaces the earlier useFormState API from the canary channel, which only returned state and the wrapped action without a built-in pending flag: you had to combine it with useFormStatus separately for that. useActionState folds both concerns into one hook.

useFormStatus reads the pending, data, method, and action of the nearest parent form, but only from a component that is rendered inside that form, not from the component that renders the form itself.

This is intentional: it lets you build a reusable SubmitButton component that shows a loading state without threading a pending prop down manually. If you call it in the same component that renders the <form> tag, it won't see that form's status, because it's designed to read from an ancestor, not a sibling.

Server Components are components that run only on the server and never ship their JavaScript to the browser at all: no hydration cost, no bundle size for that component's logic or its dependencies. Traditional server-side rendering (SSR) still sends the full component's JavaScript to the client to hydrate it into an interactive tree; the server-rendered HTML is just a head start on the first paint.

Server Components let you fetch data directly inside a component with a simple await, without exposing that logic or its dependencies to the client bundle, and they compose with Client Components (marked with "use client") for anything that needs interactivity.

The use hook lets you read the value of a Promise or a Context inside render, and unlike other hooks, it can be called conditionally, inside if statements, after early returns, even inside loops, because it isn't tied to call-order tracking the way useState and useEffect are.

When you pass it a Promise, the component suspends until that Promise resolves, integrating directly with Suspense boundaries. The catch is the Promise itself needs to be created outside of render and cached, typically via a Server Component or a caching layer, because creating a new Promise inside render on every call would cause an infinite suspend loop.

cacheSignal, added in React 19.2, gives you an AbortSignal tied to the lifetime of a server render's cache. It fires when React is done with a particular render pass and its cached data is no longer needed, letting you cancel in-flight requests or clean up resources tied to that cache scope instead of letting them run to completion for no reason after the response has already been sent.

Performance Tracks are a Chrome DevTools integration that gives React its own dedicated tracks in the Performance panel: a Scheduler track showing what priority level React is working at (blocking updates versus transitions), and a Components track showing render and effect timing per component.

Instead of guessing from a generic flame graph which component caused a slow frame, you can see directly whether a low-priority transition update is blocking a high-priority interaction, which used to require manual console.time calls scattered through your code.

The React Compiler is opt-in, not mandatory: it's a separate build-time tool you add via a Babel plugin or bundler integration, and it works with any codebase already running React 19 conventions.

What it changes practically is that you stop manually wrapping values in useMemo, functions in useCallback, and components in React.memo for performance reasons, because the compiler analyzes your component at build time and inserts equivalent memoization automatically wherever it's safe to do so, including cases hand-written hooks structurally can't handle, like memoizing a value defined after an early return.

Starting in React 19, function components can accept ref as a normal named prop, the same way they accept any other prop, without needing to wrap the component in forwardRef. This removes a common piece of boilerplate that every reusable component library had to add just to support ref passthrough.

forwardRef still works and existing code using it won't break, but the React docs mark it as a legacy pattern headed toward eventual deprecation, so new components should just declare ref as a prop directly.

These questions test judgment: knowing when to reach for an optimization technique, not just how to use it. Interviewers use these to spot candidates who over-engineer versus candidates who measure first.

Profile before optimizing, using the React DevTools Profiler to find components that re-render often and take meaningful render time, since most components don't need memoization at all.

Wrap a component in React.memo only when it receives the same props often but its parent re-renders frequently for unrelated reasons. Use useCallback and useMemo specifically to keep prop references stable so that memo comparison on the child actually succeeds. Guessing and wrapping everything "just in case" adds comparison overhead everywhere and often makes performance worse, not better.

Code splitting breaks your JavaScript bundle into smaller chunks that load on demand instead of all upfront, which speeds up initial page load. React.lazy takes a function that dynamically imports a component and returns a new component that suspends until that import resolves.

You wrap it in a Suspense boundary with a fallback, typically a loading skeleton, and React shows that fallback while the chunk downloads, then swaps in the real component once it's ready. Route-based splitting, where each page is its own lazy-loaded chunk, is the most common and highest-impact place to start.

Structurally they're the same mechanism: a component throws a Promise, the nearest Suspense boundary catches it and shows a fallback until it resolves. The difference is just what's inside: React.lazy throws a Promise for a component module import, while a data-fetching library or the use hook throws a Promise for a network request.

Because it's the same underlying primitive, a single Suspense boundary can happily coordinate both a lazy-loaded component and its data fetch at once, showing one unified loading state instead of two separate spinners.

Keep state as local as possible first: most state belongs in the component that uses it, not in a global store. For state shared across a few nearby components, lift it up to their common parent or use composition to avoid prop drilling.

For genuinely global client state like theme or auth session, a lightweight store like Zustand or Jotai avoids Redux's boilerplate while still giving you a single source of truth outside the component tree. For server data, anything fetched from an API, treat it as a separate category entirely and use React Query or SWR, since server state has different concerns (caching, revalidation, staleness) than client state and mixing the two in one store causes more problems than it solves.

Hydration is the process where React takes server-rendered HTML that's already in the DOM and attaches event listeners and internal state to it, turning static markup into an interactive app, without re-rendering everything from scratch.

A hydration mismatch happens when the HTML React generates on the client during hydration doesn't match what the server actually sent. Common causes are using Date.now() or Math.random() directly in render, checking typeof window to conditionally render different content, or relying on browser-only APIs like localStorage during the initial render. The fix is almost always to defer that logic into a useEffect, so the first client render matches the server exactly and the dynamic content applies only after hydration completes.

In development, Strict Mode intentionally renders each component twice and calls effect setup and cleanup functions twice, specifically to surface bugs where your component isn't resilient to being mounted, unmounted, and remounted: issues that would otherwise only show up in edge cases like React's concurrent features.

If your app breaks under this double-invocation, it's very often revealing a real bug, like a missing cleanup function in useEffect or state that isn't properly reset, rather than Strict Mode itself causing the problem. Production builds never do this double-render, so it's purely a development-time diagnostic tool.

These final questions test how you'd operate on a real team: testing async UI correctly, keeping tooling current, and communicating trade-offs to teammates who haven't caught up yet.

Use React Testing Library's userEvent to simulate a real form submission, then use its async utilities (findBy queries or waitFor) to wait for the pending state to resolve and the resulting UI to update, since Actions run asynchronously inside a transition.

You generally want to mock the actual async function the action calls (an API request, for example) rather than mocking React's internals, and assert on the visible outcome, the error message shown, the success state rendered, rather than reaching into implementation details like whether isPending flipped at a particular millisecond.

You install eslint-plugin-react-hooks at a recent version, since its recommended and recommended-latest presets now ship the compiler's lint rules directly: this replaced the older, separate eslint-plugin-react-compiler package once the compiler went stable.

These rules are useful even in a codebase that hasn't adopted the compiler at all, because what they're really flagging are violations of the Rules of React itself, which are worth fixing regardless of whether a compiler ever reads your code.

Server Components run once on the server, can talk directly to a database or filesystem, and ship zero JavaScript to the browser for that component, but they can't use state, effects, or any browser-only API, because they never run on the client at all. Client Components (marked with the "use client" directive) run in the browser, can use hooks and respond to events, but their code and dependencies do count against your JavaScript bundle.

The practical rule of thumb: default to Server Components for anything that's just fetching and displaying data, and only mark a component as a Client Component when it genuinely needs interactivity, state, or a browser API.

Start with measurement, not a memorized answer: open the React DevTools Profiler and find out whether the bottleneck is render count, render duration, or something outside React entirely like a huge CSS reflow.

If it's genuinely rendering too many DOM nodes at once, the real fix is virtualization: rendering only the visible rows plus a small buffer, using a library like TanStack Virtual, because no amount of memoization fixes the cost of 10,000 real DOM nodes existing at once. Only after windowing is in place does it make sense to talk about memoizing individual row components, since at that point you're rendering a few dozen rows instead of ten thousand, and that's usually the answer interviewers are actually listening for: reach for windowing before you reach for memoization.