How to Prepare for a React Interview: 7/14/30-Day Plan

Rendering & reconciliation (including keys)

Why it’s asked: It checks whether you can reason about what re-renders, why it re-renders, and how React decides what to update.

Typical prompts:

• Explain reconciliation/diffing at a high level
• Why keys matter, and why using index-as-key can be risky
• What causes a component to re-render? (and how to prevent unnecessary renders)

What good looks like: You can describe render → reconcile → commit and explain how keys preserve identity so React can apply updates predictably.

State updates & batching (React 18+)

Why it’s asked: Modern React behavior depends on update semantics and batching, which affects both correctness and performance.

Typical prompts:

• Why doesn’t state update immediately?
• Multiple updates in one event: why setState(x + 1) twice does not always do what you think
• What batching is and when it applies

What good looks like: You explain state updates as queued and applied during render, and you understand when React batches updates and what that implies for observable state.

Hooks fundamentals + Rules of Hooks

Why it’s asked: Hooks are the default React model; breaking the rules creates subtle, hard-to-debug problems.

Typical prompts:

• The Rules of Hooks (where/when you can call hooks)
• Why hooks must be called in consistent order
• When to extract a custom hook

What good looks like: You can justify the rules (stable call order is what makes hooks work), and you describe custom hooks as reusable stateful logic—not magic.

useEffect mental model (deps, cleanup, timing)

Why it’s asked: This is where most real-world bugs live: stale closures, missing dependencies, repeated effects, and incorrect cleanup.

Typical prompts:

• What the dependency array actually means
• Cleanup functions (subscriptions, timers, event listeners)
• useEffect vs useLayoutEffect (timing differences)

What good looks like: You treat effects as synchronization with external systems, explain dependency-driven reruns, and treat cleanup as part of correctness—not optional polish.

Strict Mode behavior (double-invocation / re-running effects in dev)

Why it’s asked: People get surprised by “why did my effect run twice?” and then ship hacks instead of fixing the underlying side-effect issue.

Typical prompts:

• Why React may double-render / re-run effects in development
• How Strict Mode helps find side effects
• What kinds of bugs this pattern surfaces

What good looks like: You understand it’s a dev-time safety check meant to reveal unsafe side effects, and you don’t “fix” it with random flags unless there’s a clear, scoped reason.

Stale closures & state in callbacks

Why it’s asked: Classic React pitfall: handlers and effects reading old state/props.

Typical prompts:

• Why is my callback seeing stale state?
• When to use functional updates (setState(prev => ...))
• When refs help (and when they’re a code smell)

What good looks like: You can explain closure capture vs updated state, and you can apply functional updates or ref patterns intentionally (with a reason), not as superstition.

Performance & memoization (React.memo, useMemo, useCallback)

Why it’s asked: It tests judgment: do you optimize when it matters, and do you understand the cost/benefit trade-off?

Typical prompts:

• When memoization helps vs hurts
• Referential equality + why useCallback exists
• Avoiding re-renders in component trees

What good looks like: You explain memoization as work avoided and acknowledge overhead; you optimize based on measurements/symptoms, not reflexively wrapping everything in memo.

Context & state management trade-offs

Why it’s asked: It checks whether you can share state without accidentally creating broad re-render storms or mixing responsibilities.

Typical prompts:

• When to use Context vs lifting state vs external store
• Context pitfalls: overuse, performance, layering
• Structuring shared state boundaries

What good looks like: You talk about scope, update frequency, and separation of concerns—and you can articulate why “Context replaces Redux” is an oversimplification.

Forms & controlled vs uncontrolled components

Why it’s asked: Forms are real work; controlled inputs reveal your grasp of state, events, and performance under interaction.

Typical prompts:

• Controlled vs uncontrolled inputs
• Validation strategy and UX trade-offs
• Handling large forms without lag

What good looks like: You can build a predictable controlled form, and you can explain when uncontrolled + refs is a pragmatic choice (not a workaround).

A) useEffect mental model (deps, cleanup, timing)

Why they ask it: Effects are where real-world bugs hide: stale values, runaway rerenders, missing cleanup, and race-prone data fetching.

Common trivia questions:

• What does the dependency array mean?
• When does cleanup run, and with which values?
• Why does an effect run again even if I did not change anything?
• useEffect vs useLayoutEffect: what is the difference and why does it matter?

60-second answer skeleton:

• Effects run after commit to synchronize with systems outside React (network, timers, subscriptions, DOM APIs).
• When dependencies change, React runs cleanup with old values and then setup with new values.
• The dependency array declares which reactive values the effect reads; missing deps often cause stale values or incorrect syncing.

Common traps:

• Treating effects as lifecycle replacements instead of synchronization.
• Forgetting cleanup (leaks, duplicated listeners/subscriptions, double timers).
• Removing dependencies to silence reruns instead of fixing the dependency model.

How to practice: Take one effect bug (stale closure, missing cleanup, or infinite loop) and explain the fix using sync → deps → cleanup.

B) Strict Mode behavior (double-invocation in development)

Why they ask it: This checks whether you understand dev-time safety checks and purity expectations.

Common trivia questions:

• Why does my component or effect run twice in development?
• Will it happen in production?
• What kinds of bugs is Strict Mode trying to reveal?

60-second answer skeleton:

• Strict Mode intentionally re-invokes certain logic in development to surface bugs from impure rendering or unsafe side effects.
• This is development-only behavior; avoid masking it and fix side effects so they are idempotent with correct cleanup.

Common traps:

• Adding run-once flags instead of fixing the side effect or cleanup flow.
• Confusing development checks with production behavior and debugging the wrong problem.

How to practice: Write a tiny subscribe/unsubscribe effect and verify it remains correct even when setup/cleanup happens more than once.

C) State updates, batching, and “why is state not updated immediately?”

Why they ask it: This reveals whether you understand React update semantics when multiple updates happen in one event.

Common trivia questions:

• Why does setState not update immediately?
• Why do multiple setState(count + 1) calls not always increment twice?
• When should you use functional updates (setCount(c => c + 1))?

60-second answer skeleton:

• State updates are queued; each render sees a snapshot of state and props.
• When next state depends on previous state, use functional updates to avoid stale snapshots.
• Batching combines updates for efficiency; your logic should be correct regardless of batching details.

Common traps:

• Treating state as a mutable variable that updates instantly.
• Logging right after setState and assuming it reflects the next render.

How to practice: Do three mini prompts where functional updates are required (counters, toggles, and queued action patterns).

D) Rendering & reconciliation (re-renders and keys)

Why they ask it: Identity and reconciliation are frequent causes of state jumping between list items and unstable UI behavior.

Common trivia questions:

• What causes a component to re-render?
• Why are keys important in lists?
• Why is index as key risky?

60-second answer skeleton:

• A component re-renders when its props, state, or context change; React builds a new tree and reconciles against the previous one.
• Keys preserve element identity across renders; incorrect keys can cause wrong reuse and state leakage between items.

Common traps:

• Assuming index as key is always safe (it breaks with reorder/insert/delete).
• Blaming React when the root cause is identity/key choice.

How to practice: Build a reorderable list and show what breaks with index keys versus stable IDs.

E) Stale closures in callbacks and effects

Why they ask it: This is one of the most common production bugs and quickly separates memorized answers from real understanding.

Common trivia questions:

• What is a stale closure?
• Why does a callback sometimes read old state?
• When do refs help, and when do they become a smell?

60-second answer skeleton:

• Functions capture values from the render where they were created; stale behavior appears when updated values are expected without resyncing.
• Fix based on context: correct dependencies for effects, functional updates for transitions, or ref bridges for external callbacks.

Common traps:

• Randomly adding or removing dependencies without understanding synchronization behavior.
• Using refs everywhere to bypass state modeling.

How to practice: Fix three stale-closure cases: inside setInterval, Promise callbacks, and event handlers.

F) Memoization & referential equality (React.memo, useMemo, useCallback)

Why they ask it: Interviewers test optimization judgment: when memoization helps, when it adds noise, and why.

Common trivia questions:

• When does useMemo help versus hurt?
• Why does useCallback exist?
• What does React.memo actually do?

60-second answer skeleton:

• Memoization avoids repeated work but adds overhead and depends on stable references.
• React.memo skips re-render when props are referentially equal; useMemo/useCallback help stabilize expensive values and callbacks when needed.
• Use memoization for meaningful saved work, not as a default wrapper.

Common traps:

• Wrapping everything in useMemo/useCallback by reflex.
• Assuming memoization universally prevents all re-renders.

How to practice: Take one component tree and mark where memoization helps, where it is noise, and which symptom would justify it.

G) Context usage and pitfalls

Why they ask it: Context is easy to overuse and can trigger broad re-renders or tangled architecture if boundaries are unclear.

Common trivia questions:

• When should you use Context versus lifting state?
• Why can Context cause unnecessary re-renders?
• How would you reduce Context re-render churn?

60-second answer skeleton:

• Context works best for shared dependencies like theme, auth, or locale, but scope and update frequency are key.
• Keep providers focused, split high-churn state away from broad providers, and layer contexts by responsibility.

Common traps:

• Treating Context as a full replacement for all state management.
• Using one mega-context for everything.

How to practice: Refactor a mega provider into 2–3 focused providers and explain each boundary decision.

1) Typeahead / Autocomplete (debounced input + async fetch)

Prompt template: Build an autocomplete input that fetches suggestions. Add debouncing and handle loading, error, and empty states.

What they’re testing: State transitions, async correctness, race-condition handling, and UX clarity.

What good looks like: Clear separation between input value and fetched results; debounced fetch; latest-request-wins behavior; explicit loading/empty/error UI.

Common pitfalls:

• No stale-request protection, so results jump or revert.
• Request per keystroke with no debounce/throttle.
• One tangled state object mixing input, network, and UI flags.

2) Data table (sorting + filtering + pagination)

Prompt template: Build a table with sortable columns, filtering, and pagination.

What they’re testing: Derived state, interaction correctness, performance instincts, and coordinated UI behavior.

What good looks like: Source data remains immutable; sorted/filtered data is derived; pagination resets logically after filter changes; empty states and reset behavior are predictable.

Common pitfalls:

• Mutating the source array while sorting/filtering.
• Recomputing everything on every keystroke without a plan.
• Pagination breaks after filtering because page state is not coordinated.

3) Forms (controlled inputs + validation + submit states)

Prompt template: Build a signup form with validation and clear error messaging.

What they’re testing: Controlled input discipline, validation strategy, and submit-state UX.

What good looks like: Validation rules are explicit; errors appear at the right time; pending submit state disables duplicate actions; success and failure paths are deterministic.

Common pitfalls:

• Validation logic tangled directly into render flow.
• Error state that never resets or resets at the wrong time.
• Submit spamming because pending state is not handled.

4) Modal / Dialog (open/close + ESC + focus basics)

Prompt template: Build a reusable modal with open/close, ESC-to-close, and outside click behavior.

What they’re testing: Component API design, event handling correctness, and accessibility fundamentals.

What good looks like: Simple isOpen/onClose API; ESC behavior is reliable; overlay click behavior is intentional; cleanup is complete; focus returns to trigger as a bonus.

Common pitfalls:

• Event bubbling closes the modal unexpectedly.
• Background scroll remains enabled or gets stuck disabled.
• Document-level listeners without cleanup.

5) Tabs / Accordion (composition + keyboard behavior)

Prompt template: Build tabs or an accordion, then add keyboard navigation if requested.

What they’re testing: State modeling, component boundaries, and clean interaction rule implementation.

What good looks like: Controlled or uncontrolled mode is intentional; active state is unambiguous; panel rendering is predictable; keyboard support is added without structural rewrites.

Common pitfalls:

• Overcomplicated state for a simple widget.
• Identity and key issues when panels are dynamic.
• Active state split across multiple sources.

6) Progress / Timer UI (start/stop/reset + cleanup)

Prompt template: Build a progress bar that simulates async progress and supports start, stop, and reset.

What they’re testing: Timer correctness, state transitions, cleanup discipline, and rapid-interaction edge cases.

What good looks like: Clear state machine (idle → running → complete); timer cleanup is reliable; repeated start/stop is stable; reset behavior is deterministic.

Common pitfalls:

• Timer leaks where intervals continue running.
• Race-prone behavior when users spam controls.
• Progress updates continue after unmount.

7) Infinite scroll / Feed / Job-board list (paged loading)

Prompt template: Build a feed or job list that loads more items via pagination or infinite scroll.

What they’re testing: Async pagination control, in-flight guards, list stability, and performance judgment.

What good looks like: Single in-flight request; deduped page handling; explicit end-of-results state; stable list updates; avoids unnecessary full-list rerenders.

Common pitfalls:

• Multiple simultaneous fetches creating duplicate pages.
• No guard for already-loading states.
• No strategy for long-list rendering cost.

8) Transfer list (dual list move items + select-all)

Prompt template: Build a dual list where selected items move between sides, including select-all behavior.

What they’re testing: State normalization with IDs/sets, selection correctness, and repeatable operations.

What good looks like: Normalized state shape; selection remains correct after moves; repeated operations remain idempotent and predictable.

Common pitfalls:

• Selection tied to indices, which breaks after reorder or move.
• State shape becomes hard to reason about after a few interactions.
• Bugs appear after repeated move/select cycles.

9) Small app prompts (Todo / Tic-tac-toe / Carousel)

Prompt template: Build a small app and evolve it with one or two follow-up constraints.

What they’re testing: Core state and event handling, componentization, and ability to evolve an initial solution safely.

What good looks like: Minimal working baseline ships quickly; state remains coherent; new constraints are integrated without architectural collapse.

Common pitfalls:

• Premature abstraction before baseline behavior works.
• Tangled state that makes every follow-up expensive.
• Ignoring boundaries and identity edge cases.

Signal 1: Clarify requirements early (reduce ambiguity)

What they’re evaluating: Can you prevent scope drift and avoid building the wrong thing?

What good looks like:

• Ask 2–4 targeted questions before coding (keyboard/a11y expectations, controlled vs uncontrolled, loading/error/empty states, stale-response handling).
• Restate requirements in one sentence and confirm alignment quickly.

Red flags:

• Jumping into code and discovering requirements mid-implementation.
• Asking too many questions without converging to a concrete plan.

Signal 2: Model UI state cleanly (state-machine thinking)

What they’re evaluating: Can you build UIs that stay stable under real conditions?

What good looks like:

• Separate server state (loading/error/data) from UI interaction state (open/closed, selected item, query).
• Name transitions explicitly (idle → loading → success/error).
• Keep derived state derived instead of mutating source data.

Red flags:

• State soup: one large mutable object with unpredictable interactions.
• Sorting/filtering that mutates source lists and creates follow-up bugs.

Signal 3: Treat effects as synchronization (with cleanup)

What they’re evaluating: Do you avoid high-frequency React bugs like stale closures and leaking side effects?

What good looks like:

• Explain useEffect as synchronization with external systems, not lifecycle replacement.
• Cleanup is intentional for timers, listeners, and subscriptions.
• For fetch flows, mention stale responses and ignore/cancel strategy to prevent flicker.

Red flags:

• Disabling dependency lint rules instead of fixing effect design.
• Effects with obvious side effects but no cleanup plan.
• Patching Strict Mode surprises with arbitrary run-once flags.

Signal 4: Optimize with judgment (not superstition)

What they’re evaluating: Can you improve performance without reducing maintainability?

What good looks like:

• Frame memoization as work avoided and call out overhead/trade-offs.
• Use React.memo, useMemo, and useCallback only when there is a clear hotspot or boundary reason.
• Reason about cost with concrete context (large rerendering list, unstable callback props, expensive derivation).

Red flags:

• Wrapping everything in useCallback/useMemo by default.
• Assuming referential-equality tricks always improve runtime performance.

Signal 5: Validate and test your thinking (reliability mindset)

What they’re evaluating: Do you prove correctness under likely failure and edge paths?

What good looks like:

• Run short sanity checks aloud (empty query defaults, fetch failure state, stale response ignored).
• Mention targeted tests: cleanup behavior, async races, keyboard paths, controlled input validation.

Red flags:

• No validation step (“it should work”).
• Ignoring edge cases and relying on interviewer to reveal failures.

Signal 6: Keep code readable under pressure (production hygiene)

What they’re evaluating: Can teammates maintain and extend what you produce in interview constraints?

What good looks like:

• Use clear naming, small functions, and straightforward control flow.
• Prefer simple boundaries over clever hacks.
• Keep state close to where it is owned and consumed.

Red flags:

• Spaghetti rendering logic with deep nested conditionals.
• Overengineering a mini-framework for a short prompt.

Signal 7: Communicate like a teammate (not a code printer)

What they’re evaluating: Can you collaborate, align quickly, and lead the conversation while shipping?

What good looks like:

• Narrate intent briefly (“I’m modeling state this way to avoid derived-state bugs”).
• Call out async guards and cleanup purpose while implementing.
• State uncertainty clearly and verify with a small example when needed.

Red flags:

• Long silent coding stretches with no alignment checks.
• Over-talking without concrete implementation progress.

Effects + cleanup correctness

What to review: Review dependency intent, cleanup timing, and safe synchronization with external systems.

Micro-drills:

• 60-second explanation: what triggers rerun, and when cleanup runs.
• Patch one effect bug by fixing dependencies instead of suppressing lint.
• State one stale-response guard before writing async code.

Practice items:

• useEffect() in React: syncing with the outside world (timing, dependencies, cleanup)react-useeffect-purpose
• What’s the difference between useEffect and useLayoutEffect? When does it matter?react-useeffect-vs-uselayouteffect
• React Debounced Search with Fake APIreact-debounced-search

Stale closures + async races

What to review: Review closure capture, latest-wins behavior, and predictable async UI state updates.

Micro-drills:

• Explain stale closure cause in one real callback scenario.
• Implement one latest-wins guard on a search-like flow.
• List one cancellation/ignore strategy before coding.

Practice items:

• Why does React sometimes show stale state in closures? How do you fix it?react-stale-state-closures
• Autocomplete Search Bar (Hooks)react-autocomplete-search-starter
• Chat UI with Streaming Responsereact-chat-streaming-ui

Rerenders, keys, and identity

What to review: Review component rerender triggers, key identity, and list-state stability under reorder/update.

Micro-drills:

• Give a 60-second keys explanation with one bad-key bug example.
• Predict which components rerender when one list item changes.
• Run one list manipulation variant and verify stable behavior.

Practice items:

• What is the significance of keys in lists in React?react-keys-in-lists
• When does React re-render a component, and when does it actually update the DOM?react-component-rerendering
• React Transfer List (Select + Move Between Two Lists)react-transfer-list

Forms and submit-state reliability

What to review: Review controlled input patterns, validation timing, and pending-submit behavior.

Micro-drills:

• Explain controlled vs uncontrolled with one trade-off.
• Implement pending-state guard to prevent duplicate submits.
• Validate one error-reset edge case after correction.

Practice items:

• What is the difference between controlled and uncontrolled components?react-controlled-vs-uncontrolled
• Contact Form (Component + HTTP)react-contact-form-starter
• Multi-step Signup Formreact-multi-step-signup

Memoization + context performance judgment

What to review: Review when memoization helps, when it adds noise, and how context boundaries affect rerender cost.

Micro-drills:

• State one valid reason to add memoization and one reason not to.
• Explain useMemo vs useCallback in 60 seconds.
• Refactor one broad context idea into smaller responsibility boundaries.

Practice items:

• What is the difference between useMemo() and useCallback()?react-usememo-vs-usecallback
• Why does Context cause performance issues? How do you fix them?react-context-performance-issues
• React Filterable / Searchable User Listreact-filterable-user-list

State transitions and deterministic UI behavior

What to review: Review explicit UI states and deterministic transitions under rapid user interaction.

Micro-drills:

• Define state transitions before coding (idle/running/success/error if relevant).
• Add one guard for invalid repeated action.
• Run one reset-flow scenario and verify deterministic output.

Practice items:

• React Progress Bar (0–100 with Threshold Colors)react-progress-bar-thresholds
• React Tabs / Multi-View Switcherreact-tabs-switcher
• React Dynamic Table (Rows × Columns)react-dynamic-table