Prepare for React interviews with clear explanations of rendering, hooks, state, effects, architecture, testing, accessibility, and performance.
React interviews are rarely about reciting API definitions. Strong answers connect a React mechanism to rendering behavior, user experience, maintainability, and trade-offs. This guide organizes the questions interviewers use to explore whether you can build a reliable interface beyond a tutorial.
Explain rendering without hand-waving
Be able to describe what happens when state or props change: React schedules an update, renders the component tree, compares the result, and commits necessary DOM changes. Avoid saying that React updates the entire DOM or that every component always rerenders in the same way. Precision builds trust.
Discuss keys as identity, not array indexes by default. A stable key helps React preserve the correct component state when a list changes. If a list is reordered, inserted, or filtered, an index key can associate old state with the wrong item. Use examples where identity affects editing, focus, or animations.
Use hooks for explicit data flow
Know the purpose and constraints of useState, useReducer, useMemo, useCallback, useRef, and useEffect. Hooks must be called at the top level so React can associate calls by order. Explain why a ref can hold a mutable value without triggering a render, while state represents data that should update the UI.
Effects are for synchronizing with systems outside React such as subscriptions, timers, browser APIs, or network clients. They are not a general place to derive values that could be calculated during rendering. Mention cleanup, dependency identity, race conditions, and aborting requests when discussing asynchronous effects.
Design state at the right boundary
A frequent interview topic is whether state should be local, lifted, colocated, or placed in a shared store. Keep state as close as possible to the components that own the behavior. Lift it only when siblings truly need the same source of truth. Avoid copying props into state unless you can explain the synchronization rule.
For server data, distinguish cache state from UI state. A query library can manage fetching, caching, retries, and invalidation, while React state handles a dialog, draft input, or selected tab. This separation reduces duplicated loading flags and stale copies of data.
Build for accessibility and testing
A production React answer includes semantic HTML, keyboard interaction, labels, focus management, loading states, error states, and reduced-motion considerations. Do not use a div with a click handler when a button expresses the behavior. Explain how an accessible component makes testing and maintenance easier because its behavior has a stable user-facing contract.
Test behavior rather than implementation details. A useful test renders the component, performs the same interaction a user would perform, and verifies visible output or accessible state. Add tests for empty, loading, error, and permission states. This is more durable than asserting a private hook or an internal class name.
Discuss performance with evidence
React performance questions should begin with measurement. Use the browser performance tools, React Profiler, network panel, and user-centric metrics to locate the bottleneck. Memoization can avoid work, but it also adds comparison cost and complexity. It is not a universal fix for a slow page.
Common improvements include reducing unnecessary state updates, virtualizing long lists, splitting bundles, optimizing images, avoiding waterfalls, and keeping stable identities where they matter. Explain what changed, how you measured it, and what trade-off you accepted. Performance is a product outcome, not a collection of clever hooks.
A practical action plan
Turn this guide into a weekly workflow. Begin with the smallest action that creates evidence, then schedule a review before adding more complexity. Keep a short record of the decision you made, what happened, and what you learned. This record becomes useful in applications and interviews because it turns preparation into a story of ownership.
When you get stuck, separate a knowledge gap from a practice gap and a communication gap. A knowledge gap needs a focused explanation. A practice gap needs retrieval and repetition. A communication gap needs you to explain the same idea with a simpler structure. Naming the gap prevents random preparation and helps you spend time where it can change the outcome.
Quick reference table
| Area | What it demonstrates | Best preparation move |
|---|
| Rendering and keys | Mental model | Explain identity, reconciliation, and why stable keys preserve state. |
| Hooks and effects | Correct synchronization | Separate derived values from external side effects and cleanup. |
| State architecture | Maintainability | Choose local, lifted, server-cache, or shared state intentionally. |
| Performance | Engineering judgment | Measure first, then optimize the actual bottleneck. |
Before you apply or interview
- Explain a render from state update to commit.
- Practice effect cleanup and race-condition answers.
- Separate server cache from UI state.
- Describe an accessible component.
- Bring a measured performance improvement example.
Finally, review the quality of your evidence from another person’s perspective. Can they understand the problem, your contribution, the result, and the next step without guessing? Clear evidence compounds: it improves your resume, your conversations, your interview answers, and your confidence at the same time.