React Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps

React interview cheatsheet in 2026 searches usually come from candidates who know JSX but want the interview-ready version: how to explain state ownership, hooks, component boundaries, effects, performance, accessibility, and modern rendering tradeoffs without sounding like a memorized tutorial. This guide gives you the patterns, examples, practice plan, and common traps that show up in frontend, full-stack, and senior engineering interviews.

React interview cheatsheet in 2026: the mental model

React is a UI runtime for describing what the interface should look like for a given state. Interviews are testing whether you can keep that state predictable as requirements change. Syntax matters, but the stronger signal is whether you can explain why a value is state, why a component owns it, when an effect is necessary, and how users experience loading, errors, focus, and slow devices.

Expect React to appear in these formats:

• Component coding: build a combobox, modal, table, form, tabs, file uploader, or feed.
• Frontend system design: design a dashboard, checkout flow, design system primitive, or collaborative UI.
• Debugging: fix re-render storms, stale closures, effect loops, hydration mismatches, or broken keys.
• Senior discussion: tradeoffs around client/server rendering, state libraries, component APIs, testing, and accessibility.

In 2026, many React teams use a framework with server rendering or server components. The core interview skill is still the same: know what state changes on the client, what data can be fetched on the server, and how to keep the transition between the two reliable.

State ownership: the highest-value pattern

Before coding, classify state. This alone can separate strong candidates from average ones.

| State type | Examples | Where it often belongs | |---|---|---| | Local UI state | open/closed, active tab, input draft, hover/focus | Component or nearby parent | | Server state | user record, search results, notifications | Data-fetching layer or server cache | | URL state | filters, sort, page, selected item | Router/search params when shareable | | Global app state | auth user, theme, feature flags | Context or app shell; avoid overusing | | Derived state | full name, filtered count, selected label | Compute during render or memoize if expensive |

A practical interview line: “I want one source of truth. If a value can be derived from props or other state, I will not store it separately unless there is a clear performance reason.”

Example trap:

const [items, setItems] = useState<Product[]>([]);
const [filtered, setFiltered] = useState<Product[]>([]); // often a trap

A cleaner version:

const filtered = useMemo(
  () => items.filter(item => item.name.includes(query)),
  [items, query]
);

Even useMemo may be unnecessary for small lists. Say that you would start simple and memoize when the calculation is expensive or creates referential stability issues for child components.

Component boundaries and APIs

Good React design is not “make everything tiny.” It is “give each component a clear responsibility.” A useful split for interactive components is:

• Container or feature component: owns data fetching and feature state.
• Headless logic hook: owns reusable behavior without markup when reuse is real.
• Presentational component: renders UI from props.
• Primitive component: design-system building block with accessibility baked in.

For a data table, for example:

• UsersPage handles URL params and server query.
• UsersTable renders columns, rows, loading, empty, and error states.
• ColumnVisibilityMenu owns local open/close state.
• PaginationControls updates page params.

Keep component APIs boring. Prefer explicit props over magical context until prop drilling is truly painful. Use composition for flexible layout:

<Card>
  <Card.Header title="Invoices" />
  <Card.Body>{children}</Card.Body>
</Card>

For senior roles, explain controlled versus uncontrolled components. A controlled component gets value and callbacks from its parent. It is easier to coordinate but requires more wiring. An uncontrolled component owns internal state and is simpler for isolated use. Many design-system components support both with careful defaults.

Hooks: what interviewers actually test

You should be able to explain the common hooks without reciting docs.

• useState: local state that changes over time and affects rendering.
• useReducer: related state transitions, especially multi-step or event-driven flows.
• useEffect: synchronize with external systems after render: subscriptions, network calls, timers, browser APIs.
• useRef: stable mutable value that does not trigger render; DOM refs; storing latest value for imperative integration.
• useMemo: cache expensive calculations or stable derived values.
• useCallback: stable function identity when passing to memoized children or hook dependencies.
• useContext: read cross-tree values such as theme or auth; not a replacement for all state management.

The most important hook answer: not everything belongs in an effect. If a calculation can happen during render, do it during render. If an action happens because the user clicked, put it in the event handler. Use effects for synchronization, not for deriving state from state.

Stale closure example:

useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1); // stale if count is captured from first render
  }, 1000);
  return () => clearInterval(id);
}, []);

Fix with functional update:

setCount(c => c + 1);

In interviews, narrate why the fix works: the updater receives the latest state, so it does not depend on the closed-over count value.

Rendering performance: practical, not superstitious

React performance problems usually come from one of five sources: too much state too high in the tree, unstable props, expensive derived work, huge DOM lists, or slow network/data dependencies. Do not start by sprinkling useMemo everywhere.

A good performance debugging sequence:

1. Reproduce the slow interaction.
2. Identify what re-renders and why.
3. Move state closer to where it is used if broad re-renders are unnecessary.
4. Stabilize props only when child memoization depends on it.
5. Virtualize long lists if DOM size is the problem.
6. Split expensive components or lazy-load rarely used flows.
7. Measure again.

Keys matter. Use stable IDs for dynamic lists. Index keys are acceptable only when the list is static and never reordered, inserted into, or filtered. Bad keys can preserve the wrong component state after reordering.

Memoization tradeoff: React.memo helps when a child is expensive and often receives the same props. useCallback helps when function identity causes a memoized child to re-render. useMemo helps for expensive calculations or stable object identities. Each adds complexity, so tie it to a real problem.

Accessibility and forms

Accessibility is a high-signal React interview area because custom UI can easily break native behavior. Start with semantic HTML. A real button beats a clickable div. A real label connected to an input beats placeholder-only instructions. Use ARIA to fill gaps, not to repaint broken markup.

For modals, mention focus trap, initial focus, returning focus to the trigger, Escape behavior, scroll locking, and screen-reader labeling. For comboboxes, mention keyboard navigation, active descendant, result announcements, and touch targets. For forms, mention field labels, inline validation, error summaries, disabled versus pending states, and preserving user input after server errors.

A strong form answer separates draft state from submitted state. The user can type freely, validation can run on blur or submit, and the server can reject with field-level or form-level errors. Avoid locking the entire page unless the action truly requires it.

Data fetching and async states

React code should model the full async lifecycle: idle, loading, success, empty, error, retrying, and stale. A single isLoading boolean is often insufficient for serious features.

A good pattern is a discriminated union or server-state library that makes impossible states harder. If using a framework, explain what data can be loaded server-side and what must remain client-side because it depends on user interaction. If using optimistic updates, explain rollback and conflict handling.

For search, debounce user input and cancel stale requests. For mutations, prevent duplicate submissions, show progress, handle validation errors, and reconcile server response. For dashboards, distinguish “no data” from “data failed to load.”

Common React traps

The first trap is deriving state in effects. If you write an effect whose only job is to update one piece of state from another, ask whether it can be computed during render.

The second trap is stale closures. Timers, subscriptions, and async callbacks can capture old values. Use functional updates, refs, or correct dependencies depending on the case.

The third trap is prop drilling panic. Passing props through two levels is not automatically bad. Context is useful, but it can make dependencies invisible and trigger broad re-renders if misused.

The fourth trap is ignoring hydration boundaries. If server-rendered markup depends on browser-only values such as window size or local time, you can create mismatches. Render stable initial markup and update client-only values after hydration.

The fifth trap is treating client-side permissions as security. Hiding a button is UX. Authorization must be enforced on the server or trusted backend boundary.

The sixth trap is snapshot-only testing. User behavior tests catch more meaningful regressions: typing, clicking, keyboard navigation, validation, loading, error, and retry flows.

How to talk about React in interviews

Use a product-first sequence: “The user needs X. The states are A, B, and C. This component owns local interaction state; server data comes from Y; URL params hold shareable filters. I’ll handle loading, empty, error, and accessibility before optimizing. If performance becomes an issue, I’ll measure and address the bottleneck.”

For senior roles, add maintainability. Explain how you would make a component easy to reuse without over-abstracting. Name migration risks. Talk about team conventions: data fetching patterns, design-system primitives, accessibility checks, error boundaries, and test strategy. If you choose a library, explain the operational reason, not just popularity.

When asked about server components or frameworks, keep the boundary clear. Server-rendered components are good for data-heavy, non-interactive UI and reducing client JavaScript. Client components are necessary for stateful interactions, browser APIs, and event handlers. The architecture should minimize client bundle size without making the app hard to reason about.

Seven-day React practice plan

Day 1: Classify state for ten features. Decide local, server, URL, global, or derived state and explain why.

Day 2: Build a modal and a combobox. Focus on keyboard behavior, focus management, and labels.

Day 3: Build a data table. Include URL filters, sorting, pagination, loading, empty, and error states.

Day 4: Drill hooks. Explain effect cleanup, dependency arrays, stale closures, reducers, refs, and when an effect is unnecessary.

Day 5: Debug performance. Create a slow list, bad keys, unstable props, and expensive calculations. Fix each with the smallest tool.

Day 6: Practice async flows. Build search with cancellation and a mutation with optimistic update plus rollback.

Day 7: Run a mock interview. Narrate requirements, state ownership, component boundaries, accessibility, tests, and performance tradeoffs before writing code.

Final interview checklist

• Did I clarify the user flow and all important states?
• Is there one source of truth for each value?
• Did I avoid storing derived state unnecessarily?
• Are component responsibilities clear and APIs boring?
• Are effects used for synchronization, not routine calculation?
• Are keys stable for dynamic lists?
• Did I handle loading, empty, error, retry, and stale states?
• Did I include keyboard, focus, labels, and semantic HTML?
• Did I test user behavior rather than only snapshots?
• Did I discuss performance after correctness and accessibility?

React interviews reward engineers who make UI predictable under change. If you can explain state ownership, effects, accessibility, async behavior, and measured performance tradeoffs, you will stand out from candidates who only know how to render a list.

Related guides

• API Design Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A practical API design interview cheatsheet for 2026: how to scope the problem, choose REST/GraphQL/gRPC patterns, model resources, handle auth, versioning, rate limits, and avoid the traps that cost senior candidates offers.
• AWS Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A high-signal AWS interview cheatsheet for 2026 covering architecture patterns, IAM, networking, reliability, cost, debugging, and the answers that show real cloud judgment.
• Backend System Design Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A backend System Design interview cheatsheet for 2026 with the core flow, architecture patterns, capacity heuristics, reliability tradeoffs, and traps that separate senior answers from vague box drawing.
• Data Modeling Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A practical Data Modeling interview cheatsheet for 2026 covering entities, relationships, relational and NoSQL patterns, analytics models, index choices, examples, and the traps that make otherwise strong candidates look shallow.
• Distributed Systems Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A practical distributed systems interview cheatsheet for 2026: the patterns interviewers expect, how to reason through tradeoffs, and the traps that cost strong candidates offers.