Senior React Developer Interview Questions (2026)

Senior React developer interviews in 2026 focus less on "what does useState do" and more on judgment: how rendering works, when an Effect is the wrong tool, how Server Components change the architecture, how you find and fix a slow interaction, and how you guide a team. Below are the questions I consider most useful at senior level, each with what a strong answer covers. The answers reflect current stable releases (React 19.3 and Next.js 16.4 as of October 2026).

I lead a team at AITC International, and these are the areas I care about when deciding whether someone can own features end to end. Use them to prepare, or as a starting bank if you are on the other side of the table.

#Key takeaways

• Strong answers explain why, give a trade-off, and mention a failure mode.
• Expect React 19 topics: Actions, useActionState, useOptimistic, use, and Server Components.
• Performance questions are about measuring first (Profiler, INP), not reciting useMemo.
• Know what the React Compiler does and what it cannot fix.
• Senior interviews always include a people question: code review, mentoring, disagreeing with a decision.

#React rendering and reconciliation questions

#1. What triggers a re-render, and what does "render" actually mean?

Strong answer: A component re-renders when its state changes, when its parent re-renders (unless it is memoized and props are equal), or when a context it reads changes. "Render" means React calls the component function to get new JSX. It is not the same as a DOM update. React compares the new tree with the previous one and commits only the differences. So a re-render is often cheap; it becomes a problem when it is frequent and the subtree is large, or when render does expensive work.

Bonus point: mention that a state update with the same value (by Object.is) bails out, and that the React Compiler can skip re-rendering children whose inputs have not changed.

#2. Why do keys matter, and why is using the array index risky?

Strong answer: Keys tell React which item is which between renders. With index keys, inserting at the top shifts every key, so React reuses the wrong component instances. State (like an input's text or a checkbox) ends up attached to the wrong row. Use a stable ID from the data. Index is acceptable only for static lists that never reorder.

Extra credit: changing a key on purpose is the cleanest way to reset a component's state.

#3. Explain batching and how React 18+ changed it.

Strong answer: React groups multiple state updates into one render. Since React 18, this applies everywhere (promises, timeouts, native event handlers), not just React event handlers. That is why setA(1); setB(2) causes one render. If you need to read the DOM synchronously after an update, flushSync exists, but it is rarely the right call.

#Hooks and effects questions

#4. When should you not use useEffect?

Strong answer: When the logic is not synchronizing with an external system. Derived values should be computed during render. Logic caused by a user action belongs in the event handler. Resetting state on prop change is better done with a key. Subscriptions to external stores should use useSyncExternalStore. Effects are for things like connecting to a socket, syncing a third-party widget, or setting up a timer, and they need cleanup.

I wrote a full breakdown in Common useEffect mistakes and when you don't need an effect.

#5. What is a stale closure and how do you fix it?

Strong answer: A function captures the variables from the render it was created in. If an interval or listener set up once keeps calling that function, it sees old state. Fixes, from best to worst: use an updater function (setCount(c => c + 1)), include the value in the dependency array and re-subscribe, or, for logic that should read the latest values without re-running the effect, use useEffectEvent (stable since React 19.2).

const onTick = useEffectEvent(() => {
  console.log('latest count', count);
});

useEffect(() => {
  const id = setInterval(() => onTick(), 1000);
  return () => clearInterval(id);
}, []);

#6. Why does an Effect run twice in development?

Strong answer: StrictMode mounts, unmounts and remounts components once in development to surface missing cleanup. If the Effect breaks, the cleanup is wrong. It does not happen in production. A senior candidate should not suggest removing StrictMode to "fix" it.

#React 19 questions

#7. What are Actions, and how do useActionState and useOptimistic fit in?

Strong answer: An Action is a function, often async, that React runs inside a Transition: passed to <form action>, a formAction prop, or startTransition. React tracks pending state, and forms reset uncontrolled fields after success. useActionState(action, initialState) returns [state, dispatch, isPending], where the action receives (previousState, payload). useOptimistic(value, reducer?) returns a temporary value shown only while an Action is pending, which automatically reverts to the real value afterwards.

Gotchas worth naming: dispatching from onClick needs startTransition, and useFormStatus only reads a parent form. Examples are in React 19 hooks explained.

#8. What does use() do, and what is the catch?

Strong answer: use reads a Promise or a context during render. With a Promise, the component suspends until it resolves, so you need a Suspense boundary and an Error Boundary. Unlike hooks, it can be called inside conditions. The catch: the Promise must be stable across renders. Creating fetch() inside a client component's render gives a new Promise each time. Create it in a Server Component and pass it down, or cache it.

#9. What does the React Compiler change about memoization?

Strong answer: It is a build-time tool (stable since v1.0, October 2025) that memoizes components and hooks automatically, including cases useMemo cannot handle, like values after an early return. It assumes the Rules of React; components that break them are skipped. The React team recommends relying on it for new code, keeping useMemo/useCallback as escape hatches (for example, a value used as an effect dependency), and not mass-deleting existing memoization without tests.

#Server Components and Next.js questions

#10. Explain the server and client component boundary.

Strong answer: In an RSC framework like the Next.js App Router, components are Server Components by default. They can be async, access the database, and ship no JavaScript for themselves. 'use client' marks a boundary in the module graph: that module and everything it imports become client code, which is still server-rendered to HTML and then hydrated. Props crossing from server to client must be serializable: primitives, plain objects, arrays, Date, Map, Set, Promises, JSX, and Server Functions, but not regular functions or class instances.

Follow-up I like: "How would you put a Server Component inside a client modal?" Answer: pass it as children. Details in React Server Components explained.

#11. What is the difference between 'use client' and 'use server'?

Strong answer: 'use client' marks client modules. 'use server' marks Server Functions: async functions the client can call over the network, used for mutations and form actions. Server Components themselves need no directive. Because every exported Server Function is effectively a public endpoint, it must validate input and check authorization on its own.

#12. How would you choose between static, dynamic and streamed rendering for a page?

Strong answer: Ask how fresh the data must be and whether it is per-user. Shared content that changes occasionally can be pre-rendered and revalidated in the background. Per-user or per-request data must be dynamic. Streaming with Suspense lets a fast shell show first while slow parts load. Most real pages mix all three. Mercury 360, an AI HR platform I built on Next.js, uses pre-rendering with background revalidation, and a concrete example like that from your own work makes this answer much stronger.

#Performance questions

#13. A list page feels slow when typing in its filter. How do you investigate?

Strong answer: Measure first. Record in the React DevTools Profiler to see which components render and how long they take, and in the browser Performance panel to see long tasks. Check INP in field data if available. Then fix the actual cause, which is usually one of these:

A strong candidate names a tool, a metric, and a specific fix rather than "add useMemo everywhere". Google's INP guide on web.dev is good background for this question.

#14. When does Context cause performance problems?

Strong answer: Every component that reads a context re-renders when the provider's value changes. A single large context holding fast-changing values (like form input or mouse position) re-renders many consumers. Fixes: split contexts by update frequency, keep the value stable, or use a store with selectors (Zustand, Redux) for frequently changing global state.

#State management questions

#15. How do you decide where state should live?

Strong answer: Classify it. Server state (data from APIs) belongs in a cache like TanStack Query or framework data loading, not in a global store. URL state (filters, pagination, tabs) belongs in the URL so it is shareable. Form state goes to a form library or Actions. Truly global client state (auth session in the UI, theme, a cart) can go in Context or a small store. Everything else stays local. Most "we need Redux" discussions disappear once server state is moved out.

#Architecture, testing and leadership questions

#16. How do you test React components?

Strong answer: Test behavior the user sees, not implementation details. Use React Testing Library to query by role and label, simulate user events, and assert on output. Mock the network at the boundary (for example with a request-mocking library) instead of mocking hooks. Keep a small number of end-to-end tests for critical flows like login and checkout. Snapshot tests of large trees rarely catch real bugs.

#17. How do you review a junior developer's pull request?

Strong answer: Separate blocking issues (bugs, security, accessibility, missing error states) from preferences. Explain the reason, link to docs or an example, and suggest rather than rewrite. Automate style with a formatter and lint so reviews focus on design. For repeated issues, pair or write a short team guideline instead of leaving the same comment ten times.

#18. Tell me about a technical decision you disagreed with.

Strong answer: A real story with structure: the context, what you proposed and why, how you raised it (data, prototype, written trade-offs), what was decided, and how you supported the decision once made. Interviewers are checking that you can disagree without blocking the team.

#Common mistakes candidates make

• Reciting API definitions without explaining when to use them.
• Answering every performance question with useMemo and useCallback.
• Treating 'use client' as "renders only in the browser".
• Not mentioning error, loading and empty states in design questions.
• Talking only about code in leadership questions, never about people or process.

If you want a structured path to cover these areas over a few months, my senior React developer roadmap for 2026 lays out the order I would learn them in.

#FAQ

#What do interviewers expect from a senior React developer?

They expect you to explain why React behaves the way it does, choose trade-offs between rendering and data strategies, debug performance with real tools, and help a team ship maintainable code. Knowing API names is the baseline, not the bar.

#Are React Server Components asked about in interviews?

Increasingly, yes, especially for roles using Next.js App Router. Expect questions on the server and client boundary, what 'use client' does, and what can be passed as props between them.

#Do I need to know the React Compiler for a senior interview?

You should know what it does and its limits: it auto-memoizes components and hooks at build time, skips code that breaks the Rules of React, and leaves useMemo and useCallback as escape hatches.

#How should I answer system design questions for frontend roles?

Start with requirements and constraints, then cover rendering strategy, data fetching and caching, state ownership, error and loading states, performance budgets and accessibility. Name trade-offs out loud rather than presenting one perfect answer.

#Wrapping up

The best senior answers sound like someone who has shipped and debugged real apps: a clear model, a trade-off, and a mistake they have seen. Practice saying your answers out loud with a concrete example for each. If you can explain the server/client boundary, the purpose of an Effect, and how you would measure a slow interaction, you are ahead of most candidates.