React Interview Questions for 5 Years Experience

At five-plus years, a React interview is less about APIs and more about the decisions you own. Expect architecture questions, a front-end system design round, and probes into how you lead technical direction across a team. The questions below reflect that: rendering strategy, the server/client state boundary, concurrent rendering, performance at scale and platform judgement. Answer with trade-offs and real decisions you have made and defended.

What a senior React interview is actually measuring

The interviewer assumes you can write any component; they are assessing how you reason about systems and how you influence others. For each question, frame the problem, lay out the realistic options with their costs, commit to one, and describe how you would validate and roll it back. Evidence of ownership — a migration you led, a standard you set — is what moves you from "senior engineer" to "person we want defining the front end."

Q1. How do you choose a rendering strategy: CSR, SSR, streaming SSR, or server components?

Choose by the page's needs: client rendering for highly interactive app shells behind auth, server rendering for SEO and fast first paint on content pages, streaming SSR to send HTML progressively so users see content before all data resolves, and server components to move non-interactive rendering and data fetching off the client entirely, shipping less JavaScript. The decision hinges on interactivity, SEO, time-to-first-byte, and bundle budget — and most real apps mix strategies per route.

The senior signal is naming the cost of each: SSR adds server compute and hydration complexity; server components constrain you (no state, effects or browser APIs in them); over-clienting bloats the bundle and hurts vitals.

Interview note: Follow-up: "what is hydration and where does it hurt?" Attaching event listeners to server-rendered HTML on the client; large hydration is a common cause of poor interaction latency, which streaming and server components exist to reduce.

Q2. Where is the boundary between server state and client state?

Server state is data owned by the backend — remote, shared, potentially stale — and belongs in a caching data layer (React Query, RSC data fetching, or the framework's loaders), not in a global client store. Client state is UI-only: form drafts, toggles, selections, wizard steps. Conflating the two is the most common architecture mistake at scale.

Making this split is what deletes most "global state" from an app. Once server data lives in a cache with its own invalidation, the remaining client state is small and local, and the debate over Redux versus Context largely dissolves.

Interview note: Trap: "you stored the API response in Redux — what breaks?" You now own caching, invalidation, dedup and staleness by hand, and every screen that touches it re-derives from a snapshot that can go stale. A data layer solves this for you.

Q3. Explain React Server Components and their constraints.

Server Components render on the server, can fetch data directly, and ship zero client JavaScript for their own markup; Client Components ("use client") handle interactivity. They compose: a server component can render client components and pass serialisable props, letting you keep interactive islands small. The constraints are the exam: server components cannot use state, effects, event handlers or browser APIs, and props crossing the boundary must be serialisable.

// Server Component (default in an RSC framework): no hooks, fetches directly
async function ProductPage({ id }) {
  const product = await db.product.find(id); // runs on the server
  return <ProductView product={product} buyButton={<AddToCart id={id} />} />;
}
// AddToCart is a "use client" component for interactivity

Interview note: Follow-up: "how does data get from a server to a client component?" As serialisable props, or the client component fetches from an endpoint; you cannot pass functions or class instances across the boundary.

Q4. What do concurrent features (useTransition, useDeferredValue, Suspense) give you?

They let React keep the UI responsive during heavy updates by marking work as non-urgent. useTransition marks a state update as interruptible so typing stays snappy while an expensive list re-renders; useDeferredValue lets a value lag behind so the input updates immediately; Suspense declaratively shows fallbacks while data or code loads. The mental shift is from "renders are synchronous and blocking" to "React can pause, interrupt and prioritise."

const [isPending, startTransition] = useTransition();
function onChange(e) {
  setQuery(e.target.value);               // urgent: input stays responsive
  startTransition(() => setResults(filter(e.target.value))); // non-urgent
}

Interview note: Trap: "does a transition make the work faster?" No — it makes it interruptible and lower priority, so urgent updates like keystrokes are not blocked. The heavy work still costs the same.

Q5. How do you keep component and state architecture healthy in a large codebase?

Establish clear boundaries: colocate state with the feature that owns it, define where shared/server/UI state each live, standardise data fetching, keep a shared component library with accessibility built in, and enforce it through code review, lint rules and a documented decision record. The leadership answer describes the system you put in place, not just your personal habits — because at scale, consistency across engineers is the real lever.

Interview note: Follow-up: "how do you migrate 200 components off a bad pattern safely?" Incrementally behind a boundary — codemods where possible, a lint rule to stop the bleeding, and a tracked burndown, never a big-bang rewrite.

Q6. How do you approach performance at scale?

Measure before optimising: React Profiler for render cost, browser performance tools and web vitals (LCP, INP) for user-perceived speed. Then attack the biggest lever — usually bundle size (code-splitting, server components), then re-render hot paths (colocation, memoization), then expensive renders (virtualisation for long lists). The senior framing is budget-driven: set targets, measure against them, and optimise the measured problem.

The performance optimization questions go deeper on the tactics; at this level, interviewers want your process and how you prevent regressions with monitoring.

Interview note: Trap: "you memoized everything and it is still slow — why?" The bottleneck was probably bundle size or a genuinely expensive computation, not reference stability. Memoization fixes wasted renders, not slow code or heavy payloads.

Q7. How do you design a reusable component or design-system API?

Design for composition and the consumer: prefer composition (children, slots) over a wall of boolean props, keep components controlled/uncontrolled flexible, build in accessibility (roles, keyboard, focus), keep styling overridable, and version changes carefully because every team depends on you. A good answer treats the component's props as a public API with backward-compatibility obligations.

Interview note: Follow-up: "props explosion — how do you avoid it?" Favour composition and sensible defaults; when a component sprouts a dozen flags, it usually wants to be split or made compound (Menu, Menu.Item).

Q8. How do you make and defend a platform decision, like adopting a new state library or framework?

Frame it as a trade-off with evidence: the problem it solves, the cost of migration, the risk, a spike or prototype, and a reversible rollout. Bring the team along with a written proposal and a decision record, and define success metrics up front. What interviewers want is not the specific tool but a repeatable, transparent decision process that other engineers trust.

Interview note: Trap: "the team disagrees with your choice — then what?" You surface the disagreement, weigh it honestly, and either adjust or commit with a documented rationale and a review date. Ownership includes being willing to be proven wrong on a schedule.

Q9. How do you test and release large React changes safely?

Layer the strategy: unit and component tests for behaviour, integration tests for critical flows, a few end-to-end tests for the money paths, plus feature flags and staged rollout to release risky changes gradually. The senior emphasis is on confidence per unit of effort — a small number of high-value end-to-end tests plus flags beats an unmaintainable pile of brittle tests.

Interview note: Follow-up: "how do flags interact with server components and caching?" Flag evaluation must be consistent between server render and client, and cache keys must include the flag, or users see mismatched or stale UI.

How to prepare

Prepare stories, not just facts. For each area above — rendering strategy, the state boundary, a performance win, a migration you led — have a concrete decision you made, the options you weighed, and how you validated it. Practise a front-end system design out loud: pick a feature, walk data flow, rendering, caching, accessibility and evolution, and narrate trade-offs the whole way. Then pressure-test your reasoning with a senior-level mock interview. Pair this with the state management and performance sets for the deep-dive rounds, and keep the React learning path handy to refresh any concurrent or server-side detail before the loop.