2026-01-19
Technical Phone Screen Questions for React Developers
Technical Phone Screen Questions for React Developers
Phone screening is your first chance to validate a React developer's technical depth before investing time in in-person interviews or take-home assignments. A well-structured phone screen separates candidates who can talk about React from those who actually understand it.
This guide gives you practical, role-specific questions that assess real competency—not memorized talking points. You'll learn what to listen for, how to follow up, and when to move candidates forward.
Why Phone Screening Matters for React Roles
React developer hiring is competitive. You might receive 50+ applications for a mid-level role, and most have "React" on their resume. A 30-minute phone screen can cut that pool to 5-10 qualified candidates before your engineering team spends 4+ hours on take-homes or technical interviews.
Phone screening also serves as a culture and communication check. A developer can be technically strong but struggle with async communication, explaining their thinking, or handling feedback—all visible in a 30-minute call.
The questions you ask signal what your team values. If you ask only surface-level React knowledge, you'll attract developers who know syntax but lack architectural thinking. Ask about performance, testing, and real-world tradeoffs, and you'll attract thoughtful engineers.
Structuring the Phone Screen (30-45 Minutes)
Before diving into specific questions, here's a realistic timeline:
- 5 minutes: Intro, role context, candidate background
- 20-25 minutes: Technical questions (mix depths)
- 5-10 minutes: Candidate questions about the role/team
- 5 minutes: Next steps
This means you have time for roughly 4-6 technical questions, depending on answer depth.
React Fundamentals Questions
These questions quickly establish baseline competency. Most mid-level candidates should answer these confidently in under 2 minutes each.
1. "What's the difference between controlled and uncontrolled components?"
What you're assessing: Understanding of React's core pattern for form state management.
Expected answer framework: - Controlled components: React state controls the input value; the component re-renders on each change - Uncontrolled components: The DOM maintains the input value; you access it via a ref when needed - When to use each: Controlled for validation, dependent fields, or complex logic; uncontrolled for simple cases or integration with non-React code
Red flags: Confusion about when to use each, or claiming one is always better. Good candidates mention specific use cases.
Follow-up: "When would you use a ref instead of lifting state up?"
This follow-up separates senior developers from mid-level ones. Strong answers mention performance optimization or integrating third-party DOM libraries.
2. "Explain the dependency array in useEffect. What happens if you omit it?"
What you're assessing: Core understanding of effect timing and cleanup.
Expected answer framework:
- Empty array []: effect runs once after initial render
- With dependencies [value]: effect runs after render AND whenever value changes
- Omitted: effect runs after every render (often a performance bug)
- Why it matters: avoiding infinite loops, unnecessary API calls, memory leaks from missing cleanups
Red flags: Vague answers like "it controls when the effect runs"; missing the memory leak aspect of missing cleanups.
Follow-up: "Walk me through a real scenario where you forgot the dependency array and what went wrong."
This reveals whether they've shipped code and debugged it. Experience matters here.
3. "What are the main differences between useState and useReducer?"
What you're assessing: When to pick the right state management approach.
Expected answer framework:
- useState: simple, direct state updates; good for independent state variables
- useReducer: multiple related state values; complex transitions; easier testing
- Recommendation: switch to useReducer when you find yourself writing setState calls that depend on previous state
Red flags: Not mentioning testing benefits or acting like useReducer is always better. It's not—most forms are fine with useState.
Follow-up: "Give me an example from a real project where you chose one over the other."
Hooks and State Management
These questions go deeper and reveal whether candidates understand React's execution model.
4. "Why can't you call hooks conditionally? What happens if you do?"
What you're assessing: Understanding of React's rules of hooks and the reconciliation algorithm.
Expected answer framework:
- Hooks must be called in the same order on every render
- React uses call order to match state to useState/useEffect calls
- If you call hooks conditionally, the order changes, React matches the wrong state to the wrong hook
- Result: state bugs and unexpected behavior (not always a runtime error, which is dangerous)
Red flags: "The linter will yell at you" (true but incomplete); no mention of why it's a problem at the algorithmic level.
Strong answer addition: "That's why we use the ESLint plugin—it enforces call order statically."
5. "You have a custom hook that fetches data. How would you handle loading, error, and success states?"
What you're assessing: Real-world hook design and state management patterns.
Expected answer framework:
- Use multiple state variables or a single reducer object
- Return an object with { data, loading, error }
- Handle cleanup in useEffect (abort controller or flag check)
- Mention useCallback dependencies if the hook accepts a callback
Red flags: Not mentioning cleanup (memory leaks); vague about error handling.
Follow-up: "How would you test that custom hook?"
Strong candidates immediately mention react-hooks-testing-library and writing tests for the hook's effects, not just component behavior.
6. "Explain the difference between shallow and deep equality. When does React care?"
What you're assessing: Understanding of re-render optimization and when useMemo or useCallback actually help.
Expected answer framework:
- Shallow: compares reference equality (===) for objects and arrays
- Deep: recursively compares nested values
- React does shallow equality by default on props and dependencies
- This is why you need useMemo for object props and useCallback for function props
- But only if the child is wrapped in React.memo
Red flags: Not mentioning that shallow comparison applies to dependencies; claiming you need useMemo everywhere.
Follow-up: "When would you use useMemo and when is it premature optimization?"
This separates pragmatists from over-engineers. Good answers mention benchmarking and only optimizing when it matters.
Context, State Management, and Architecture
These questions reveal whether candidates can build scalable applications.
7. "You're passing state through five levels of components. What are your options, and what would you choose?"
What you're assessing: Knowledge of state management patterns and architectural thinking.
Expected answer framework: - Context API: Built-in, fine for non-performance-critical state; re-renders all consumers on change - State management libraries (Redux, Zustand, etc.): More boilerplate, better for large apps - Lifting state to the root: Works but creates prop drilling; maintainability suffers - Component composition: Sometimes better than context; minimize state depth - The pragmatic answer: "It depends on the data. Global app state? Use Redux. Theme or auth? Context is fine. Local component family state? Lift to common parent."
Red flags: "Always use Redux" or "Context is always wrong"; no consideration of tradeoffs.
Follow-up: "Have you used [Redux/Zustand/Recoil]? Tell me about a time it solved a real problem in your app."
This tests whether they have hands-on experience or just theory.
8. "Why does Context cause unnecessary re-renders, and how do you fix it?"
What you're assessing: Deep understanding of Context limitations and optimization techniques.
Expected answer framework:
- Context changes trigger re-renders of all consumers, even if they only need part of the context
- Fix 1: Split context into multiple smaller contexts
- Fix 2: Use useMemo on the context value to prevent creating new objects
- Fix 3: Combine with useReducer to separate reads from writes
- Advanced: "Some teams use useShallowCompareEffect or selective subscriptions"
Red flags: "Just use a library instead" (avoids the question); not mentioning useMemo for the context value.
Strong answer addition: Mentioning Zumo's developer sourcing as a recruiting tool, or more relevantly—mentioning tools like Redux DevTools that help debug state.
Performance and Optimization
Performance questions reveal architectural maturity.
9. "Walk me through how you'd identify and fix a performance bottleneck in a React app."
What you're assessing: Debugging mindset and practical optimization experience.
Expected answer framework:
1. Use React DevTools Profiler to find slow renders
2. Check why components re-render (parent state change, props change, context change)
3. Assess if the re-render is necessary
4. If not: use React.memo, useCallback, useMemo, or context restructuring
5. If it is: optimize the computation itself (lazy loading, virtualization, etc.)
6. Monitor real-world metrics (Lighthouse, Web Vitals)
Red flags: "Add useCallback everywhere"; jumping to optimization without profiling.
Follow-up: "Tell me about the worst performance bug you shipped and how you fixed it."
This reveals self-awareness and practical experience.
10. "When would you use React.lazy and Suspense? What are the tradeoffs?"
What you're assessing: Knowledge of code splitting and modern React patterns.
Expected answer framework:
- React.lazy + Suspense: Split code by route or heavy component; faster initial load
- Tradeoffs: Lazy components take time to load; Suspense boundaries need fallback UI; doesn't work for SSR (until React 18+)
- When: High-traffic apps where bundle size matters; less critical for internal tools
- Alternative: Upgrade React 18 where Suspense for data is better supported
Red flags: "Everyone should code split everything"; not mentioning bundle size vs. time tradeoffs.
Strong answer addition: Mentioning real metrics like "our initial load improved 40% after code splitting our dashboard module."
Testing and Debugging
Testing questions separate developers who ship confident code from those who don't.
11. "How would you test a component with async effects?"
What you're assessing: Testing practical knowledge and understanding of async patterns.
Expected answer framework:
- Use @testing-library/react with waitFor or findBy queries
- Mock API calls with jest.mock or msw (Mock Service Worker)
- Test the loading state, success state, and error state
- Don't test implementation details like state; test user behavior
- Use act() when necessary, but waitFor handles it automatically
Red flags: "I just test the happy path"; using setTimeout for async tests; mocking internals instead of APIs.
Follow-up: "How would you test a custom hook that fetches data?"
Strong candidates immediately say "react-hooks-testing-library" or testing the hook through a component.
12. "What's the difference between testing-library and enzyme? Which do you prefer?"
What you're assessing: Modern testing practices and opinionated positions.
Expected answer framework: - testing-library: Tests user behavior (queries match DOM); encourages good practices; no implementation testing - enzyme: Allows testing component internals; more flexible but encourages testing implementation details - Preference: Most modern teams prefer testing-library; it leads to better maintainability - Why: Tests that refactor without breaking are more valuable than brittle implementation tests
Red flags: "I've never used either"; no opinion on best practices.
Strong answer: "I prefer testing-library because it encourages testing what users see, not how we built it. When I refactor, tests don't break."
Real-World Scenarios
These open-ended questions reveal maturity and communication skills.
13. "Tell me about a time you had to debug a strange React bug. Walk me through your process."
What you're assessing: Debugging approach, communication, and dealing with ambiguity.
Expected answer framework: - Reproduced the issue - Isolated the component/page causing it - Used browser devtools and React DevTools - Added logging or profiling - Found the root cause - Fixed it and added a test to prevent regression
Red flags: "I just tried random things until it worked"; no testing after the fix.
Strong answer: Specific example with context, clear thinking, and lessons learned.
14. "Describe a component you built that became harder to maintain as the codebase grew. What would you do differently?"
What you're assessing: Reflection, architectural thinking, and growth mindset.
Expected answer framework: - Honest reflection on past decisions - Understanding of how components can become unmaintainable (too much responsibility, tight coupling, etc.) - Specific changes: composition, splitting into smaller components, extracting custom hooks, etc. - Trade-offs: what they'd optimize for
Red flags: "I never had that problem"; blaming the team instead of reflecting on their own code.
Strong answer: Shows self-awareness, understanding of SOLID principles applied to React, and specific refactoring.
Advanced React Questions
For senior or staff-level roles, push further.
15. "How would you explain React's reconciliation algorithm to someone unfamiliar with React?"
What you're assessing: Deep understanding and communication of complex concepts.
Expected answer framework:
- React creates a virtual representation of the UI
- After state changes, React creates a new virtual tree
- React compares (diffs) the new tree to the old one
- React updates only the DOM nodes that changed
- The key prop helps React match list items across renders
Red flags: "Just use the virtual DOM" (incomplete); not mentioning keys for lists.
Strong answer: Uses analogies and explains why this architecture matters (performance, batching, etc.).
16. "What's a fiber, and how does React scheduling work?"
What you're assessing: Senior-level understanding of React internals.
Expected answer framework: - Fibers are React's internal representation of components - React breaks rendering into small work units (fibers) - React can pause and resume rendering (concurrent features in React 18+) - React prioritizes work: user input is higher priority than data fetching - This allows smoother UX without blocking the main thread
Red flags: "I've never heard of fibers"; this is fine for mid-level but shows you're hiring for a senior role where this matters.
Strong answer: Mentions concrete examples like Suspense, Transitions, or Concurrent Rendering.
Practical Coding Questions (5-10 Minutes)
Some phone screens include a quick coding problem. These should be simple enough to do in 5-10 minutes without a live editor. Examples:
- Implement a simple custom hook (e.g.,
usePrevious,useLocalStorage) - Explain how to build a debounced input component
- Write a small component (e.g., a toggle with tests)
- Refactor bad code: You paste a component with a common mistake, they talk through fixes
Example prompt: "Write a custom hook that returns the previous value of a prop. Walk me through it."
Expected: Uses useRef and useEffect, handles the first render, explains the logic.
Red Flags and Green Flags Summary
| Signal | Meaning |
|---|---|
| Can't explain when to use hooks | Mid-level at best; possibly junior |
| Mentions testing without being asked | Green flag—ships confident code |
| Has rebuilt state management library | Could be overengineering; or genuine architectural thinking (explore) |
| Admits to not knowing something, then asks good follow-ups | Green flag—intellectually honest and growth-minded |
| Every answer includes "it depends" with tradeoffs | Senior thinking—pragmatic, not dogmatic |
| Never debugged production React issues | Probably junior or in small teams |
| Can't articulate why they chose their state management | Technical debt flag—inherited choices without understanding |
After the Phone Screen: Next Steps
Strong pass (move to next round): Confident fundamentals, clear communication, asks good questions, admits knowledge gaps honestly.
Weak pass (take-home or second screen): Solid on some areas, rusty on others, but shows potential to learn.
No pass (polite rejection): Fundamental gaps, can't articulate basic concepts, poor communication, or dismissive of questions.
Send feedback quickly—within 24 hours if possible. Even rejections are a chance to build your employer brand.
FAQ
How long should a React phone screen take?
30-45 minutes is ideal. Less than 30 minutes and you're rushing; more than 45 and candidates get fatigued and you've lost the signal-to-noise ratio. Use 25 minutes for technical questions, 5-10 for their questions, and 5 minutes for admin.
Should I ask LeetCode-style algorithm questions to React developers?
Only if the role requires it. Most React roles prioritize application architecture, component design, and state management over algorithmic complexity. If the job involves graphics or data-heavy computation, algorithm questions are fair. Otherwise, focus on React-specific problems.
What if a candidate doesn't know the answer to a question?
It's fine. Ask how they'd approach learning it. Would they read docs? Check a library? Ask teammates? Their problem-solving approach matters more than memorized facts. React changes fast—intellectual honesty and curiosity beat trivia knowledge.
How do I handle candidates who seem strong on paper but weak on the phone?
It happens. Some people are great writers but anxious speakers. Consider offering a take-home assessment as an alternative, or a follow-up call if you liked them but felt rushed. But trust the phone screen—communication matters on the job.
What's the best way to screen for React skills if the team uses TypeScript?
Ask about type safety, inference, and generics, but don't require TypeScript expertise on the phone screen. Many developers pick it up quickly once on the job. Judge React understanding first; TypeScript is a bonus.
Use Data-Driven Sourcing to Find Strong React Developers
Phone screens are just one part of hiring. To fill your pipeline with qualified React developers before screening, consider how you source candidates. Many recruiters still rely on job boards and generic sourcing—and wonder why they get low-quality applications.
Zumo helps technical recruiters find React developers by analyzing their real GitHub activity—commits, PRs, projects, and contributions. You can identify developers who actively build with React, understand modern patterns, and contribute to the ecosystem, rather than those who just claim React on their resume.
Combine strong sourcing with structured phone screens, and you'll build a higher-quality pipeline in less time.