React developer interview questions

What React interviews should actually measure

The best react developer interview questions reveal whether someone can build, debug, and maintain reliable interfaces—not merely recall Hook names. For hiring managers, engineering leads, and interviewers in the MyDiscussions community, the goal is to connect React knowledge with observable evidence: correct state modeling, predictable rendering, accessible interactions, and sound architectural judgment.

Start by defining the job. A developer maintaining a client-rendered dashboard needs different experience from someone designing a Next.js application with server rendering and streaming. Neither role should be assessed primarily through framework trivia.

A useful interview distinguishes three capabilities:

• Conceptual understanding: Can the candidate explain React’s behavior accurately?
• Implementation ability: Can they translate requirements into working, maintainable components?
• Engineering judgment: Can they identify risks, compare alternatives, and validate decisions?

Use the same core questions and scoring anchors across candidates, with follow-ups calibrated to seniority.

Define the React hiring bar before choosing questions

Write down the responsibilities the person will own during their first few months. Translate those responsibilities into evidence you can collect during an interview.

Do not make every competency equally important. A design-system role should emphasize component APIs and accessibility. A product role may require stronger data-fetching and workflow modeling. Record these priorities before meeting candidates rather than adjusting them afterward.

React fundamentals: questions that expose mental models

1. What causes a React component to render, and does rendering always change the DOM?

A strong answer separates rendering from committing changes. State updates, parent rendering, and consumed context changes can lead to a component rendering. React then determines what needs to be committed; executing a component does not necessarily produce a DOM mutation.

Useful follow-ups include:

• What can happen when state is updated to an equivalent value?
• Why might a child render when its props appear unchanged?
• What does memo help with, and what does it not prevent?

Look for an accurate model rather than exhaustive implementation details. Claims that “every render rebuilds the DOM” indicate a foundational misunderstanding.

2. Why can array-index keys cause bugs?

Ask the candidate to explain what happens when an editable list is reordered.

Strong answers connect keys to component identity among siblings. Index keys can cause React to associate local state with the wrong item after insertion, deletion, or sorting. Random keys introduce another problem: components can remount on every render, losing state and repeating setup work.

Index keys can be acceptable for truly static lists without identity-sensitive behavior. Reward candidates who explain that constraint instead of repeating an absolute prohibition.

3. How would you update state based on its previous value?

Present several updates triggered by one event. Ask why repeatedly calling setCount(count + 1) differs from functional updates such as setCount(previous => previous + 1).

A good answer discusses render snapshots, queued updates, and batching. For object or array state, candidates should preserve immutability and avoid mutating shared references.

For TypeScript roles, extend the discussion to modeling loading, success, and failure as a discriminated union rather than unrelated booleans that permit impossible combinations.

Hooks and asynchronous behavior: test reasoning, not rules recitation

4. When should you use an Effect, and when should you avoid one?

Ask whether filtering a list from props requires an Effect.

Strong candidates usually derive filtered data during rendering. They reserve Effects for synchronizing with external systems, such as subscriptions, timers, or browser APIs.

They should recognize that copying derived values into state creates extra synchronization work and opportunities for stale data. React’s official guidance on when you might not need an Effect provides a useful calibration reference.

For expensive derivations, ask how they would establish whether memoization is worthwhile. “Wrap everything in useMemo” is not a performance strategy.

5. A search box sometimes shows results for an older query. How would you fix it?

This question tests asynchronous reasoning. A complete answer should identify out-of-order responses, then discuss options such as:

• Canceling supported requests with AbortController.
• Ignoring responses that no longer belong to the active request.
• Using a data-fetching library with appropriate query keys.
• Debouncing input when reducing request frequency is desirable.

Debouncing alone does not prevent response races.

Ask how the candidate handles loading, empty results, failures, and unmounting. TanStack Query or SWR may simplify caching and request lifecycle management, but familiarity with either library should not substitute for explaining the underlying problem.

6. Why might an Effect run an extra setup-and-cleanup cycle during development?

A solid answer identifies React Strict Mode’s development checks and explains why cleanup must mirror setup.

The candidate should investigate leaked subscriptions or unsafe side effects rather than disabling Strict Mode to hide the symptom. Stronger answers explain that render logic should remain pure and that network mutations should not accidentally depend on a component mounting once.

Avoid wording this as “Why does React always run Effects twice?” That statement erases important development and configuration context.

State management and component architecture questions

7. Where should state live in a multi-step form?

Describe a form with validation, conditional fields, saved drafts, and a review screen.

Good candidates distinguish among:

• Local UI state: Expanded sections or temporary input visibility.
• Shared workflow state: Values and transitions used across steps.
• Server state: Saved drafts and submission status.
• URL state: A shareable step or filter, where appropriate.

Ask when they would choose local state, a reducer, Context, React Hook Form, Zustand, or Redux Toolkit. Evaluate ownership and update patterns—not loyalty to a particular library.

Trade-offs should be explicit: centralization can simplify coordination but widen coupling; local state improves isolation but may complicate cross-step behavior.

8. How would you design a reusable modal or dialog?

Look beyond prop naming. Candidates should discuss accessible naming, focus management, Escape handling, restoring focus, and preventing unintended interaction with background content.

Ask whether they would build from scratch or adopt an established primitive such as React Aria or Radix UI. Reusing a mature primitive can reduce implementation risk, but teams still need integration testing and suitable styling boundaries.

A strong component API exposes product-relevant behavior without accumulating dozens of interacting flags.

Performance and modern React architecture questions

9. A dashboard feels slow. What would you measure first?

The right answer starts by clarifying the symptom: initial loading, typing latency, navigation delay, or scrolling jank.

Candidates should separate potential causes:

• Network latency and sequential data requests.
• Large JavaScript bundles and expensive startup work.
• Unnecessary or expensive React rendering.
• Browser layout, paint, and long main-thread tasks.
• Excessive DOM size.

Useful tools include React Developer Tools Profiler and Chrome DevTools Performance and Network panels.

Ask candidates to choose a measurement, propose a change, and describe verification. Virtualization may help long lists; memoization may help repeated expensive work; neither fixes a slow backend. Also ask whether the project uses React Compiler, since that affects how candidates should evaluate manual memoization.

10. How do Server Components differ from server-side rendering?

This is appropriate when the role uses frameworks such as Next.js. Strong answers explain that Server Components and server-side rendering solve related but distinct problems.

Server Components execute in a server environment and can keep certain dependencies and data-access logic out of client bundles. Server-side rendering produces initial HTML; Client Components may also participate in that initial server-rendered output.

Candidates should explain where interactivity belongs, how boundaries affect data transfer, and why secrets must remain server-only. They should also recognize that client-side boundaries do not remove the need for server-side authorization.

Use the Next.js Server and Client Components documentation to align expectations with the framework actually used.

A practical React coding exercise

Give candidates a small, functioning repository rather than asking them to spend interview time configuring Vite, TypeScript, or a test runner.

Exercise: build an accessible user search panel

Provide a mock API with configurable delays and occasional errors. Ask the candidate to:

1. Add a labeled search input.
2. Fetch and display matching users.
3. Handle loading, empty, and error states.
4. Prevent stale responses from replacing newer results.
5. Allow selection of a user and display a details panel.
6. Add tests for the most important behaviors.

For a live session, scope the required work to approximately 45–60 minutes and treat extensions as discussion topics. Tell candidates which documentation and AI tools they may use.

Evaluate prioritization as well as completion. A candidate who implements the core flow correctly and identifies remaining risks may provide stronger evidence than someone who finishes more features with fragile state handling.

Useful follow-ups include keyboard behavior, retry semantics, caching, and what changes when the result set becomes large.

Testing questions that distinguish confidence from coverage

11. What would you test in this search component, and at which level?

Strong answers emphasize behavior visible to users:

• Searching displays the relevant results.
• An older response cannot overwrite a newer search.
• Failures produce understandable feedback and a recovery path.
• Controls have accessible names and work with a keyboard.
• Selecting a result updates the details view.

React Testing Library with Vitest or Jest can support component tests. MSW can model network behavior without replacing every internal function. Playwright can verify critical browser-level flows.

The Testing Library guiding principles explain why tests should resemble how software is used.

Ask what should not be tested. Excessive assertions about internal state, Hook call counts, or component structure can make refactoring expensive without protecting meaningful behavior.

A step-by-step interview and evaluation process

Step 1: select role-relevant competencies

Choose a manageable set of essential capabilities. Mark which are required on entry and which can be learned after hiring.

Step 2: prepare consistent prompts

Use shared scenarios, repository setup, and follow-up questions. Test the exercise internally to catch ambiguous requirements and unrealistic scope.

Step 3: begin with explanation

Ask candidates to explain one familiar React system they built, including a difficult bug and a decision they would revisit. Probe their personal contribution without requiring confidential details.

Step 4: observe implementation and debugging

Use the practical exercise to observe how candidates inspect errors, verify assumptions, and respond to feedback. Distinguish independent progress from interviewer-assisted progress without treating clarification as weakness.

Step 5: score evidence independently

Use an anchored scale:

• 1 — Below requirement: Cannot establish a correct approach, even with substantial guidance.
• 2 — Developing: Solves straightforward cases but misses important failure modes.
• 3 — Meets requirement: Produces a sound approach and explains relevant trade-offs.
• 4 — Exceeds requirement: Anticipates risks, validates decisions, and improves the design without unnecessary complexity.

Record examples before the panel discussion to reduce anchoring.

Step 6: decide against the predefined bar

Compare evidence with role requirements, not charisma or another candidate’s presentation style. Discuss uncertainty explicitly and use a targeted follow-up when essential evidence is missing.

Common mistakes in React interviews

• Overweighting trivia: Remembering an obscure API does not establish debugging ability.
• Treating library preferences as correctness: Redux Toolkit, Zustand, and Context address different constraints.
• Rewarding premature abstraction: A generalized component system may be worse than a clear local solution.
• Ignoring accessibility: A clickable div is not equivalent to a semantic button.
• Expecting one universal data-fetching approach: Framework loaders, server execution, and client query libraries fit different applications.
• Confusing speed with seniority: Senior judgment often appears in questions, risk identification, and deliberate simplification.
• Leaving AI assistance undefined: Specify allowed tools and require candidates to explain and verify generated code.

For adjacent role guides and evaluation frameworks, browse more Interview questions topics.

Frequently asked questions

What React developer interview questions should junior candidates answer?

Focus on props, state, events, conditional rendering, lists and keys, basic Effects, and semantic HTML. Use a small component exercise to check whether candidates can implement changes, interpret errors, and explain their choices. Avoid making advanced server architecture a default requirement.

How should senior React developer interviews differ?

Increase ambiguity and architectural depth rather than relying on harder trivia. Ask seniors to diagnose performance, define component boundaries, manage asynchronous workflows, plan migrations, and select testing strategies. Expect them to connect technical decisions to maintainability and delivery risk.

Should candidates memorize React Hook dependency rules?

Candidates should understand reactive dependencies and stale closures, but memorizing lint messages is less valuable than correcting real code. Ask them to explain a dependency warning, restructure an Effect when necessary, and avoid suppressing warnings without a defensible reason.

Is a take-home assignment better than live coding?

Neither format is universally better. Live coding reveals reasoning but can amplify interview pressure. Take-homes allow more realistic tooling but consume personal time and complicate authorship assessment. Keep assignments bounded, disclose evaluation criteria, and offer an equivalent alternative when feasible.