React Rendering Deep Dive: What Interviewers Actually Test

The React rendering deep-dive round separates frontend candidates who use React at a surface level from candidates who genuinely understand it. Senior interviews probe what happens when a state update fires, how React decides what to re-render, what concurrent rendering enables, and where the common performance pitfalls hide. Candidates who can articulate “render produces VDOM, reconciliation diffs it, commit applies the diff” get partial credit; candidates who can explain Fiber, the priority lanes system, the difference between rendering and committing, and how concurrent rendering changes the model get full credit.

This piece covers what interviewers actually test on React rendering, with depth calibrated for senior+ frontend interviews in 2026.

The mental model

React’s rendering is a three-stage process:

1. Render phase. React calls your component functions, builds a Virtual DOM tree, compares it to the previous tree (reconciliation), and computes a list of effects (DOM mutations, lifecycle calls). The render phase is pure — no DOM mutations happen yet, no effects fire.
2. Commit phase. React applies the computed mutations to the actual DOM and runs lifecycle effects (useEffect cleanups + new effects, useLayoutEffect, etc.).
3. Browser paint. The browser renders the new DOM.

The render phase can be interrupted (with concurrent rendering) and re-attempted; the commit phase cannot. Understanding this is the foundation of most senior-level React rendering questions.

Fiber and how reconciliation works

React’s reconciliation walks the component tree and decides what changed. Pre-React-16 reconciliation was synchronous and recursive; the entire tree had to be processed in one go. React 16+ introduced Fiber, which represents the tree as a linked list of fiber nodes that can be traversed iteratively and paused mid-traversal.

What this enables:

• Time-slicing. React can render a piece of the tree, yield to the browser, and resume.
• Priority lanes. Different updates have different priorities (urgent user input vs background data fetches). High-priority updates can interrupt low-priority ones.
• Suspense. Components can declaratively suspend during render, and React shows a fallback while waiting.

Senior interviewers test whether the candidate understands that Fiber is the underlying mechanism, not just a buzzword. A candidate who can explain “Fiber lets React build the tree iteratively, which means rendering can be paused and prioritized” answers strongly. A candidate who says “Fiber is React’s new architecture” without specifics signals shallow understanding.

What triggers a re-render

The default rules:

1. State change. A component re-renders when its state changes via setState, useState setter, useReducer dispatch, etc.
2. Parent re-render. A child component re-renders when its parent re-renders, regardless of whether props changed.
3. Context change. A component re-renders when a context it consumes changes.

The third rule has a subtle trap: a context value that is recreated each render (e.g., an object literal in JSX) will trigger re-renders of all consumers even if the underlying values are unchanged. This is one of the most common performance pitfalls.

What does NOT trigger a re-render:

• Mutating state directly (this is a bug; React does not detect it).
• Refs changing (refs do not trigger re-renders by design).
• Module-level variables changing (React does not subscribe to those).

Memoization: what it actually does

The big three: React.memo, useMemo, useCallback.

• React.memo wraps a component so that it skips re-rendering if its props are referentially equal to the previous render’s props. Default comparison is shallow.
• useMemo caches a computed value across renders if its dependencies have not changed. Useful for expensive computations.
• useCallback caches a function reference across renders if its dependencies have not changed. Useful for passing stable callbacks to memoized children.

The interview pitfall: memoization is not free. The cache itself takes memory, the dependency comparison takes time, and the wrapping adds complexity. Senior candidates know when memoization helps (passing stable references to memoized children, expensive computation) and when it hurts (every primitive value, simple components that re-render fast anyway).

Concurrent rendering: what it changes

React 18 introduced concurrent rendering as the default mode. Concrete differences:

• Automatic batching. Multiple state updates within a single event handler or async block are batched into one render. In React 17 and earlier, only updates within React event handlers were batched.
• Transitions. useTransition marks updates as non-urgent. React can interrupt these to handle higher-priority updates (like user input).
• Suspense for data fetching. Components can declaratively suspend during render. React shows a fallback and resumes when data is ready.
• Streaming server rendering. Content can render and ship to the client as soon as it’s ready, not waiting for the entire page.

Senior interviewers expect candidates to articulate at least the first two changes precisely.

Server components

React Server Components (RSC) introduced a new dimension. RSCs run on the server, can fetch data directly, and produce a serialized format that the client renders alongside its own client components. Key interview points:

• RSCs cannot use state (no useState) or lifecycle effects (no useEffect).
• RSCs can be async functions that await data.
• The client/server boundary is explicit (the “use client” directive marks client components).
• RSCs reduce client-side JavaScript bundle size.

Frameworks (Next.js App Router most prominently) implement RSC. The interview question is usually less about implementation details and more about when to use RSC vs traditional client components.

Common interview questions

“What happens when I call setState?”

Strong answer: schedules a re-render of the component. React adds the update to a queue, picks a priority lane based on the context (event handler, transition, etc.), and at some point processes the queue, calls the component function, reconciles the new tree against the previous tree, and commits the changes. If multiple setState calls happen within the same event handler, they are batched into a single render.

“Why is this component re-rendering?”

The interviewer shows code with a performance issue. Strong candidates use React DevTools Profiler to diagnose, identify the cause (parent re-render, prop reference change, context change), and propose a fix (memoization, context split, lifting state).

“How does Suspense work?”

Strong answer: a component can suspend rendering by throwing a Promise. React catches the Promise, shows the nearest Suspense boundary’s fallback, and tries to render again when the Promise resolves. Suspense is the foundation for streaming SSR, data fetching with libraries like React Query in suspense mode, and code-split components.

“What’s the difference between useEffect and useLayoutEffect?”

Strong answer: useEffect runs after the browser paints; useLayoutEffect runs after DOM mutations but before paint. Use useLayoutEffect when you need to read DOM measurements or synchronously apply changes that the user should not see in an intermediate state. Use useEffect for everything else (async work, subscriptions, side effects that don’t affect layout).

What scores poorly

• Confusing reconciliation with the commit phase.
• Saying “React does its magic” without specifics.
• Treating memoization as a default best practice (it has costs).
• Confusing useMemo with useCallback.
• Not knowing what changed in React 18 (concurrent mode, automatic batching).
• Confidence about RSC details that contradict the actual semantics (e.g., claiming RSC can use useState).

How to prepare

1. Read the React documentation deeply. The “Behind the Scenes” section is gold.
2. Read at least one Fiber explainer. Andrew Clark’s original Fiber notes and the React core team’s blog posts are canonical.
3. Use React DevTools Profiler on a real app. The visual record of renders is the best teacher.
4. Build a small project that uses concurrent features (Suspense, transitions). The hands-on understanding solidifies what the API actually does.
5. For RSC: build a small Next.js App Router project to internalize the client/server boundary.

Frequently Asked Questions

Do all senior frontend interviews test Fiber?

Not always at the level of “explain the linked list traversal.” Many senior interviews test the consequences of Fiber (priority lanes, time-slicing) without demanding the implementation details.

Is class components vs functional components still relevant?

Functional components are the default in 2026. Class components still exist in legacy codebases. Senior interviews may ask about the differences or about migration; they do not generally require deep class-component knowledge.

How important is RSC knowledge in 2026?

For Next.js-using companies (Vercel, Linear, many modern startups) very important. For companies on Vite + traditional client-side React, less so. The trend line is toward RSC adoption.

What about React Compiler?

React Compiler is the optimizing compiler shipped in React 19+. Senior frontend candidates should be conversant with what it does (auto-memoizes components, eliminates need for manual useMemo/useCallback in many cases) and what it does not (it does not change the rendering model, it does not eliminate the need to understand reconciliation).

Should I memorize the React source code?

No. Understanding the model is what matters. The source is a useful reference but not study material for an interview.