30 Advanced React Interview Questions for Experienced Developers (2026 Edition)

React is used by 44.7% of all professional developers, the most-used frontend framework for six straight years (Stack Overflow Developer Survey 2025). Senior React developer roles in the US now command average salaries between $128,400 and $145,000, with top earners exceeding $223,718 (ZipRecruiter, February 2026). That compensation reflects real complexity: senior interviews don't test whether you can use useState - they test whether you understand why the reconciler works the way it does, when Server Components eliminate client-side JavaScript entirely, and how to architect a React application that scales across a team of 20+ engineers.

Key Takeaways

• React 19 (stable since December 2024) is already adopted by 48.4% of daily React users - expect React 19 questions at every senior interview (State of React 2025)

• Fiber's two-phase architecture (render phase + commit phase) underpins every performance question - understand it cold

• React Server Components ship zero client JavaScript for server-rendered subtrees; the RSC payload is a JSON-like stream, not HTML

• useTransition, useDeferredValue, and Suspense are the concurrent rendering APIs every senior candidate must explain with code

Looking to brush up on hooks fundamentals first? See the 40+ React Hooks Interview Questions and Answers (2026) guide for useState, useEffect, and custom hook patterns.

Fiber is the engine behind everything React does. Experienced developers get asked Fiber questions not because interviewers want trivia, but because understanding how the reconciler works explains why useEffect runs after paint, why concurrent updates can be dropped and restarted, and why your component function can be called multiple times before its output reaches the DOM. If you've only used React without reading the source, this section is where senior interviews create distance between candidates.

React Fiber is the complete rewrite of React's reconciler, shipped in React 16. Before Fiber, reconciliation was a single synchronous recursive call-stack walk - it couldn't be paused, so complex UI updates caused jank. Fiber replaced that recursive stack with a linked list of fiber nodes (plain JavaScript objects), each representing one unit of work. The reconciler processes one fiber at a time, can yield to the browser's event loop after any node, and resume later - enabling time-slicing and priority scheduling.

Interview tip: Interviewers want to know why Fiber exists - not just that it's a rewrite. Lead with "the original synchronous stack reconciler couldn't be interrupted," then explain how the linked-list structure enables concurrent rendering.

These two phases are distinct in React's architecture. Reconciliation (the render phase) is purely computational: React traverses the fiber tree, calls your component functions, diffs the new output against the previous tree, and builds a list of effects. This phase is pure - no DOM mutations happen - and in Concurrent Mode it can be interrupted and restarted.

Rendering (the commit phase) applies those effects to the real DOM. It runs synchronously and can't be interrupted, because partially updating the DOM would leave the UI in an inconsistent state. The commit phase also fires useLayoutEffect callbacks (after DOM mutation, before browser paint) and useEffect callbacks (after browser paint).

Interview tip: Most candidates know "diffing" happens but can't name the two phases or explain what "interrupt-safe" means. Mentioning that the render phase can run multiple times before a single commit (due to Concurrent Mode) is what separates senior-level answers.

In legacy (blocking) mode, React processes the entire fiber tree in one synchronous pass. If that pass takes 200ms, the main thread is blocked for 200ms - no user input, no animations, no paint. Concurrent Mode breaks work into interruptible units, scheduled against the browser's idle capacity. React uses its internal scheduler to assign priorities: user input gets the highest priority, background data fetching gets the lowest.

Interview tip: If asked "what does Concurrent Mode enable?", name three concrete features: useTransition for non-urgent updates, useDeferredValue for deferring stale data display, and Suspense for streaming SSR. Abstract answers about "better performance" won't pass a senior screen.

Both APIs mark updates as non-urgent so React can prioritize user-critical interactions, but they operate on different targets. useTransition wraps a state setter call - it marks the resulting update as low-priority while React keeps the previous UI visible. useDeferredValue wraps a value - it returns a lagged copy of that value during urgent updates.

Use useTransition when you control the trigger (you write the setState call). Use useDeferredValue when you receive a value you don't control - a prop or a value from a third-party store.

Interview tip: The isPending flag from useTransition lets you show a loading indicator without a Suspense boundary. That's the practical win senior interviewers look for - not just "it defers work."

Suspense catches promises thrown during rendering. When a component "suspends," it throws a Promise. React catches it at the nearest boundary, renders the fallback UI, watches the thrown promise, and when it resolves, re-renders the suspended subtree. In React 19, Suspense is deeply integrated with Server Components and streaming SSR - the server flushes the HTML shell immediately and streams suspended subtrees as they resolve.

Interview tip: Most candidates describe Suspense as "for lazy loading components." At the senior level, you need to know it's a general mechanism for any asynchronous value - data, images, code - and that React 19's use() hook is the clean way to throw promises inside components without manual boilerplate.

React Server Components are the most architecturally significant React feature since hooks. By early 2026, 48.4% of daily React users are already on React 19, where RSC is a first-class primitive (State of React 2025). Senior engineers are expected to understand the boundary between server and client execution - not just how to use the 'use client' directive, but why it exists and what it means for the JavaScript payload that ships to the browser.

Server-Side Rendering (SSR) renders your component tree to HTML on the server, sends that HTML to the browser, then ships the same JavaScript bundle to "hydrate" the HTML into a live React tree. Both server and client run the same component code. React Server Components (RSC) are fundamentally different: Server Components run only on the server and are never hydrated. Zero JavaScript is sent to the client for them - they can import a 200KB Markdown parser, use it, and return rendered output without shipping the parser to the browser.

Interview tip: The key differentiator is hydration. SSR hydrates everything; RSC means Server Components are never hydrated. If you can also explain what the "RSC payload" is (a serialized stream of React element descriptions, not HTML), you've demonstrated understanding above the marketing layer.

'use client' at the top of a file marks it as a Client Component boundary. Everything imported into that file becomes part of the client bundle too - the label propagates down the import tree. Across this boundary, you can only pass serializable props: strings, numbers, booleans, plain objects, arrays, and null. You cannot pass functions, class instances, Map, Set, or non-serializable values from a Server Component to a Client Component as props.

Interview tip: A common mistake - passing a Server Component function reference as a prop to a Client Component. You can't. Instead, pass the rendered output (JSX) as children. JSX is serialized in the RSC payload and can safely cross the boundary.

Server Actions are async functions marked 'use server' that execute exclusively on the server but can be called from Client Components as if they were regular functions. Next.js generates a POST endpoint for each action; when a Client Component invokes it, the framework makes a network request, runs the function server-side with full access to databases and environment variables, and returns the result. They replace manually written API routes for mutations and form submissions.

Interview tip: Interviewers at security-conscious companies check whether you know the implication: Server Actions run with full server privileges. Always validate and sanitize inputs inside the action - never trust the incoming FormData payload.

The RSC payload is a line-delimited JSON stream that describes the React element tree produced by Server Components. It's neither HTML nor a JavaScript bundle - it's a compact serialized representation that React's client runtime reassembles into a fiber tree. Each line represents a component, its props, or a "hole" where a suspended subtree will stream in later.

In Our finding: Teams that misunderstand the RSC payload often try to "inspect" it with browser devtools looking for HTML - it appears as raw text. Knowing it's a fiber-tree description (not HTML) explains why Server Components can be updated independently without a full page re-render.

Interview tip: Many candidates know RSC "ships less JavaScript" but can't explain the mechanism. Saying "the RSC payload is a JSON stream React's client runtime uses to reconstruct the fiber tree without re-running Server Components" demonstrates genuine depth.

You can pass serializable data as props: strings, numbers, booleans, plain objects, arrays, and null. For complex shared state, the cleanest production pattern is to fetch server-side data in a Server Component, then hydrate a Client-side context provider so Client Components below can subscribe.

Interview tip: A tricky follow-up: "Can you pass JSX as a prop to a Client Component from a Server Component?" Yes - JSX is serialized as part of the RSC payload, and children is JSX. This is exactly how "Server Component as children of Client Component" works.

Choose useReducer when state transitions are complex (multiple sub-values that change together), when the next state depends on the previous in non-trivial ways, or when you want to centralize and test update logic in isolation - the reducer is a pure function, no React dependency needed. useState is better for simple, independent values. The crossover point: if you find yourself writing three or more related useState calls that all update together, consolidate them into a reducer.

Interview tip: If asked to compare useReducer to Redux, the answer is: useReducer is component-scoped; Redux is global. Use useReducer for local complex state, Zustand or Redux when multiple components across the tree need the same state.

React Context re-renders every component that calls useContext whenever the context value changes - even if that component only uses one field of the value object. The four main strategies at scale: (1) split contexts by update frequency - user data context separate from auth methods; (2) memoize the value object with useMemo so reference equality prevents spurious re-renders on parent re-renders; (3) use a selector-based library like Zustand or Jotai where components only re-render when their subscribed slice changes; (4) memo + context - wrap stable children in React.memo.

Interview tip: If asked "how do you share state efficiently across 50 components?", the answer isn't "one big context." It's Zustand or Jotai with subscriptions - they only re-render components subscribed to the exact slice of state that changed.

Both are production-quality, but Zustand's API is dramatically simpler - a complete store in ~10 lines versus Redux Toolkit's slices, actions, and selectors. Zustand stores are plain JavaScript closures, so they work outside React (in WebSocket handlers, utility functions, or API clients) without the useDispatch/useSelector overhead. It also doesn't require a Provider wrapper. Redux Toolkit remains the right choice when teams need strict action traceability, Redux DevTools time-travel debugging, or have existing Redux infrastructure.

Interview tip: Mention that Zustand subscriptions are selector-based - useAuthStore(state => state.user) only re-renders when user changes, not on any store update. That's the key performance advantage over plain Context at scale.

An optimistic update immediately reflects the expected result in the UI before the server responds, then rolls back if the server returns an error. The three-step pattern: update local state immediately, fire the API call, and on error revert state and surface the failure. React 19 ships useOptimistic as a first-class primitive - React handles the automatic revert when the wrapping async function throws.

Interview tip: With useOptimistic, React handles rollbacks automatically when the Server Action throws - the optimistic state reverts to initialLikes. With manual useState, you have to save the previous value and restore it in a catch block. Interviewers want to know you've handled the failure path.

A stale closure happens when a useEffect, useCallback, or setTimeout callback captures a state variable at the time the component renders, and never sees updated values. The closure closes over the initial snapshot. Three fixes: (1) dependency array - add the variable so React re-creates the callback on change; (2) functional setter - setCount(c => c + 1) reads the current value inside React's update queue, bypassing the closure; (3) useRef - store the latest value in a ref and read ref.current inside long-lived callbacks.

Interview tip: The useLatest pattern - a ref that always holds the most recent value - is a production staple. Libraries like ahooks ship it as useLatestValue. If asked "how do you read the latest state inside a setInterval without adding it to deps?", useRef is the answer.

Performance questions at the senior level aren't "what is React.memo?" - they're "when does React.memo hurt you?" and "what does the Profiler's actualDuration / baseDuration ratio tell you?" Experienced developers know that premature optimization is as harmful as no optimization. These questions test whether you can diagnose before you optimize. The React core team's own guidance: profile first, memo second.

Note from practice: 40% of frontend developers report performance work as their primary focus (State of Frontend 2024), yet most memoization in production codebases is speculative - added without a Profiler measurement. The pattern that consistently helps: wrap Profiler around suspect subtrees for one release cycle before reaching for memo.

React.memo wraps a component in a shallow equality check - it only re-renders if props changed. It hurts when: (1) the component is cheap to render (a or a simple list item), so the comparison costs more than the skipped render; (2) props are objects or arrays recreated on every parent render, causing the equality check to always fail; or (3) function props aren't wrapped in useCallback, so they're new references on every render. In those cases, you pay the comparison overhead and re-render anyway.

Interview tip: The React core team's rule of thumb: profile first, memo second. React DevTools Profiler shows exactly which renders are expensive. Don't memo speculatively - it adds cognitive overhead and can introduce stale data bugs when deps are wrong.

The Profiler component wraps a subtree and calls an onRender callback with timing data on every commit. In production, Profiler is a no-op by default - you need the react-dom/profiling bundle and ReactDOM.createRoot with profiling enabled. For real production monitoring, combine Profiler with an observability service (Sentry, Datadog) to capture actualDuration for your slowest components over real user sessions.

Interview tip: The ratio actualDuration / baseDuration tells you how effective your memoization is. If actualDuration ≈ baseDuration, memoization isn't helping. If actualDuration << baseDuration, it's working. Most candidates don't know this ratio exists - mentioning it is a strong signal.

Virtualization renders only the DOM nodes visible in the viewport, recycling a fixed number of nodes as the user scrolls. Without it, 10,000 list items create 10,000 DOM nodes - slow initial render, high memory, janky scrolling. The two main libraries: react-window (< 5KB, FixedSizeList and VariableSizeList) and TanStack Virtual (zero dependency, framework-agnostic).

Interview tip: Virtualization is necessary at ~500+ dynamic items and ~2,000+ static items. Below those thresholds, the added complexity (scroll math, inaccessible jump-scroll behavior, tricky dynamic heights) rarely pays off. Measure scroll performance with Lighthouse before reaching for a virtualization library.

Route-level splitting is the baseline - each page bundle loads only when the user navigates to that route. In Next.js App Router this is automatic per route segment. In Vite/Webpack apps you use React.lazy with Suspense. Component-level splitting targets heavyweight dependencies (rich text editors, chart libraries, map SDKs) that aren't needed for first paint. The rule: split when a component adds > 30KB gzipped to the initial bundle.

Interview tip: In Next.js App Router, route segments split automatically. But heavy client-side libraries (Monaco Editor, Mapbox GL) still need explicit dynamic(() => import(...), { ssr: false }) to exclude them from SSR and defer them to the client.

Hydration errors occur when the HTML the server rendered doesn't match the React tree the client generates during hydration. React expects identical output so it can attach event listeners without rebuilding DOM nodes. Common causes: window, localStorage, or Date.now() in the render body (browser-only), random or time-based values, locale-dependent number/date formatting, and browser extensions that mutate the DOM before hydration.

Interview tip: React 18 improved hydration error messages to show the specific attribute or text node that mismatched. In Next.js App Router, the error overlay highlights the exact component. Use suppressHydrationWarning sparingly and only when you own and understand the mismatch reason.

Compound Components share implicit state between a parent and its children via context, letting consumers compose UI without prop drilling through multiple layers. It's ideal for complex UI widgets - tabs, accordions, dropdowns, command palettes - where the parts always appear together but the layout should remain flexible. The pattern replaces long prop lists (), with a declarative composition model.

Interview tip: Compound Components is a frequent live-coding prompt at senior interviews. Know it well, but also know its limit: if children are ever used independently outside the parent, plain props are simpler. The pattern only pays when the parts are always used together.

Interview tip: If asked "are HOCs dead?", the nuanced answer is: HOCs are still the right tool for wrapping render output (auth gates, error boundaries, analytics). For logic reuse, custom hooks are always cleaner. The React team's own codebase uses both - the choice depends on whether you're sharing logic or wrapping JSX.

A well-designed hook has a single named responsibility, returns a stable interface that doesn't change shape between renders, accepts an options object rather than multiple positional arguments for extensibility, and is testable in isolation without mounting a component. The return value should use primitive types where possible (easier to memoize in consumers) and expose stable function references via useCallback.

Interview tip: A senior interviewer will catch a hook that returns a new object on every render, forcing consumers to use useMemo. Use useCallback for function values inside hooks. Better yet, return primitives and stable refs so consumers don't need any extra memoization.

Interview tip: singleton: true in the shared config is critical - it ensures only one copy of React runs on the page. Without it, you'll see "Hooks can only be called inside a function component" because two React instances have separate internal registries. This is the most common production bug with Module Federation.

A single top-level error boundary isn't enough in production - one feature crash shouldn't take down the entire app. The pattern: wrap each major feature area (sidebar, main content, individual widgets) in its own boundary. Each boundary reports to your error monitoring service with component stack and user context, then renders a contextual fallback. React 19 added onCaughtError and onUncaughtError root-level callbacks to complement boundaries for observability.

Interview tip: Error boundaries don't catch errors in event handlers (use try/catch there), async code outside render, or server-side code. Interviewers at FAANG often ask this follow-up specifically - it reveals whether you've actually shipped error boundaries in production or just read the docs.

React 19 is the most consequential React release since hooks. Senior candidates are expected to know what changed, why it matters, and what deprecated APIs to stop using. SPAs still dominate at 84.5% of React usage patterns (State of React 2025), but the Server Actions and use() primitives introduced in React 19 are already reshaping how experienced teams write data-fetching and mutation code.

React 19 stable (December 5, 2024) introduced: Actions - async functions that handle pending, error, and optimistic states automatically; useActionState - manages action return state in forms; useFormStatus - lets child components read parent form submission state without prop drilling; useOptimistic - first-class optimistic UI; use() - reads Promises and Context inside render (conditionally); ref as prop - ref is now a regular prop, forwardRef is deprecated; and improved hydration error diffs showing the exact mismatch.

Interview tip: The removal of forwardRef is the React 19 change that catches experienced devs off-guard - it was required in React 17/18 but is now deprecated. Mentioning this unprompted signals you've shipped React 19 code, not just read the release notes.

Generic components accept a type parameter that flows through props, enabling type-safe composition without losing flexibility. The most common use cases: data tables where columns and data must match, Select inputs where the option type should be inferred, and list components where renderItem type depends on items type.