What you'll learn

By the end of this you'll know which React topics show up in real frontend loops, how to answer them out loud without sounding like a documentation page, and how to recover when a follow-up goes somewhere you did not rehearse. You'll also have a prep routine — not a flashcard deck — that maps to what interviewers actually score.

This is not a list of 200 questions. It is the smaller set that keeps appearing, with the reasoning behind each answer so you can adapt when the wording changes.

Who this is for

  • Frontend or full-stack candidates where React is the main UI layer
  • Developers who ship features but freeze when asked to explain hooks or rendering
  • Anyone who walked out of a loop thinking "I knew that, I just could not say it"

You can skip this if you're interviewing for staff-level architecture roles where React API trivia is barely touched. At that level, expect tradeoff conversations about data loading, bundle strategy, and team conventions — not "explain useEffect."

What a React interview actually is

Plain English: a React interview is a conversation about whether you understand what your components are doing, not just whether you can make them work.

Interviewers are not checking if you memorized every hook signature. They want to see that you can explain re-renders, predict side effects, and make reasonable choices when two patterns both "work." Think of it like a driving test — they care that you know why you checked the mirror, not that you recited the manual.

Most React rounds blend live coding (small component or bug fix), verbal deep dives (hooks, state, lists), and sometimes a take-home review. The verbal part is where this guide helps most.

Prerequisites

You should have built at least one non-trivial React app — routing, forms, API calls, component extraction. You do not need to have read the React source code.

Comfortable baseline:

  • JavaScript: closures, async/await, destructuring, array methods
  • HTML/CSS: forms, accessibility basics, responsive layout
  • Git: enough to talk through how you work on a branch

If hooks still feel like magic symbols, spend two evenings building a small app with useState, useEffect, and lifted state before drilling interview answers. The answers stick better once you've been burned by a stale closure yourself.

Setup from zero

You do not need a special repo. You need a repeatable week of prep.

Step 1 — Audit your last project

Pick one React codebase you know well. For each major screen, write one sentence: what state lives where, what triggers re-renders, and where data is fetched. Interviewers love "walk me through something you built." Having that map ready beats generic answers.

Step 2 — Rehearse out loud

Read each question below and answer in 60–90 seconds without looking at notes. Record yourself once. You will hear rambling, filler, and places where you say "optimize" without saying what got faster. Fix those.

Step 3 — Do one timed component exercise

Give yourself 25 minutes: build a searchable list with controlled input, loading state, and empty state. No UI library. The goal is fluency, not beauty. Most live React exercises are this shape — state, effects, lists, keys.

Little tip: interviewers forgive imperfect styling. They notice when you forget key, mishandle async in useEffect, or cannot explain why something re-rendered. Prioritize correctness and explanation over pixel polish.

The mental model

React is a description engine, not a DOM manipulation engine.

You describe UI as a function of state. React reconciles that description with the previous one and applies the smallest DOM update it can. Hooks, memoization, and Server Components are all ways to control when that description runs and where work happens.

When you are stuck on a question, return to: "What state changed? What re-rendered? What side effect runs because of which dependencies?" That frame answers most hook and performance questions cleanly.

Key terms

Re-render — React calling your component function again. Not the same as the browser repainting.

Reconciliation — comparing the previous and next element trees to decide minimal DOM changes.

Controlled component — input value driven by React state; the DOM displays state, not the other way around.

Side effect — work outside render: fetch, subscription, document.title, timers.

Stale closure — a callback that reads an old state value because it closed over a previous render.

Lifted state — shared state moved to the closest common ancestor of components that need it.

Step-by-step

Work through these in order during prep. Each includes the question, a strong short answer, and the follow-up interviewers often ask.

Q: What happens when you call setState?

Answer: React schedules an update. The current function keeps the old value; the next render sees the new one. Multiple setState calls in the same event handler may batch into one re-render (in React 18+ this is broader than inside events).

Follow-up: "Why did my log show the old value?" Because you logged inside the same render, before React re-ran the component.

---

Q: useEffect vs useLayoutEffect?

Answer: Both run after render. useLayoutEffect runs before the browser paints; use it when you measure layout or must avoid a visible flash. useEffect runs after paint — default for fetches, subscriptions, analytics.

Follow-up: "Can Server Components use them?" No. Effects run in the client runtime. Any file using them needs "use client" in the App Router model.

---

Q: Why does my effect run too often?

Answer: Missing deps → runs every render. Empty [] → runs once but can stale-closure if you read state without refs. Object/function deps → new reference every render unless stabilized.

Better line: "I treat exhaustive-deps warnings as review items, stabilize callbacks with useCallback when a memoized child needs it, and use refs for 'run once but read latest value' cases."

---

Q: When does a component re-render?

Answer: Its own state changes, its parent re-renders (unless memoized and props shallow-equal), or consumed context changes.

Follow-up: "Does React.memo always help?" No. Inline object props break memo every time. Fix data flow first; memo is a measured tool, not a default.

---

Q: Rules of hooks — why?

Answer: Hooks are stored in call order. Conditional hooks change order between renders and React loses track of which state belongs where. Only call hooks at the top level of components or custom hooks.

---

Q: Controlled vs uncontrolled inputs?

Answer: Controlled: React state is source of truth — best for validation and dynamic UI. Uncontrolled: DOM holds value; read with ref on submit — fine for simple forms and file inputs.

---

Q: Why do keys matter in lists?

Answer: Keys tell React which item is which across renders. Index keys break when items reorder — state attaches to the wrong row (classic form-in-list bug). Use stable IDs.

Working examples

Bug: effect with missing dependency

function UserPanel({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/api/users/${userId}`).then(r => r.json()).then(setUser);
  }, []); // bug: userId changes, effect does not re-run

  return user ? <p>{user.name}</p> : <p>Loading…</p>;
}

Fix: [userId] in the dependency array, or abort in-flight requests on change. In interviews, mention cancellation — it signals production awareness.

Memoization when it actually helps

const sorted = useMemo(() => heavySort(items, query), [items, query]);
const onSelect = useCallback((id) => setSelected(id), []);

Use when profiling shows cost or when passing callbacks to memoized children — not everywhere by default.

Patterns and when to use them

| Pattern | When to use |
|---------|-------------|
| Lifted state | Two siblings need the same data |
| Context | Many consumers, low-frequency updates (theme, auth) |
| External store (Zustand, etc.) | Many updates, avoid context re-render storms |
| Server Components fetch | Initial page data, SEO, no client waterfall |
| Client fetch (SWR/React Query) | User-driven refetch, polling, optimistic UI |

Little tip: saying "I'd fetch in a Server Component first, then add client cache if we need invalidation or optimistic updates" sounds like someone who has shipped App Router apps, not just read the docs.

Common mistakes

"I optimize with memo everywhere." Without a measured problem, you add complexity and often still re-render because props are recreated inline.

Treating useEffect as componentDidMount. The mental model is synchronization: "when these values change, align with this external system." That framing fixes dependency bugs.

Cannot explain your own take-home. If AI or a tutorial helped you scaffold, you still must own data flow and error paths. "The tool wrote it" fails every time.

Ignoring error and loading states in live coding. A list that only handles the happy path reads junior. Show skeleton, empty, and error — even minimally.

Troubleshooting

Blank mind on hooks question: Draw a timeline — render 1, render 2 — and mark when state updates and when effects run. Interviewers respect visible reasoning.

Keep losing track in live coding: Start with state shape on paper ({ query, results, status }). Implement render branches before fetch logic.

Take-home feedback was "over-engineered": Next time, fewer abstractions, clearer file names, one README paragraph on how to run and what you'd add with more time.

Checklist

  • [ ] Can explain re-render triggers in one minute
  • [ ] Can compare useEffect and useLayoutEffect with a concrete example
  • [ ] Can describe one real project's state and data flow
  • [ ] Know why index keys in dynamic lists are dangerous
  • [ ] Did one timed component exercise this week
  • [ ] Practiced answers out loud, not just read them

Practice task

Take a component from your portfolio that fetches data. Rewrite it on paper without looking: state variables, effect dependencies, loading/error UI, and what would break if props changed. Then explain it in 90 seconds as if to an interviewer. Gap between paper and speech is what prep fixes.

FAQ

Do I need to know React internals like Fiber?
Helpful at senior level, rarely required mid-level. Know reconciliation at a high level; skip deep scheduler trivia unless the role asks.

Class components?
Uncommon in new code. Know that they existed and that hooks replaced lifecycle patterns — enough for legacy codebases.

Which React version?
Assume 18+ with concurrent features and 19 where relevant. Mention batching and transitions if performance comes up.

Should I mention Next.js?
If the job lists it, yes — especially Server vs Client Components and where fetch belongs.

What to learn next

  • JavaScript deep cuts — closures and the event loop show up inside React answers
  • System design starter — full-stack React roles often add a design round
  • AI tools angles — many teams now ask how you work with Cursor or Copilot
  • [Node.js interview prep](/interview/nodejs-interview-prep)
  • [JavaScript interview deep cuts](/interview/javascript-interview-deep-cuts)
  • [System design interview starter](/interview/system-design-interview-starter)

Takeaways

React interviews reward clarity over buzzwords. Know what triggers re-renders, how effects synchronize with the outside world, and how to walk through something you actually built.

Prepare by mapping a real project, rehearsing short spoken answers, and doing one small timed component. The candidates who sound strongest are not the ones who memorized the most API — they are the ones who can reason in public.

If you remember only one thing: React re-renders when state, props, or context change — explain every answer by pointing at what changed and what ran because of it.