Why pre-screen React developers before the technical exercise
React is easy to write badly in a way that works for months. State scattered across components, effects that fire more often than anyone intended, and a re-render cascade that only becomes visible when a list gets long. Developers who have maintained an application past its first year have hit all of it and can explain the decisions they now make differently. A short screen asks about state and about a performance problem they measured.
What actually matters when screening React Developer candidates
- 01
Technical proficiency
Probe hooks depth: useMemo versus useCallback, dependency arrays, custom hooks, Suspense, and how they type props and generics in TypeScript with React 18 concurrent rendering.
- 02
Systems and trade-offs
Ask how they chose state tools: Redux Toolkit, Zustand, TanStack Query, or Context, plus bundle size, code splitting, and Next.js versus Vite decisions.
- 03
Evidence and rigour
Check testing and performance evidence: React Testing Library, Playwright, React Profiler traces, Core Web Vitals like LCP and INP, accessibility audits with axe.
- 04
Collaboration and communication
Assess how they work with designers and backend: Figma handoff, component library or Storybook ownership, API contract disputes, and code review habits on pull requests.
Pre-screening questions to ask React Developer candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Apps they maintained
3 questions01Tell me about your hands-on experience as a React developer.
Listen forApplications they built and then maintained, with what changed in their approach after living with the code.
Projects built and handed over immediately, or no application they have maintained past its first release.
02Can you explain a complex problem you faced in a React project and how you solved it?
Listen forA genuine architectural difficulty with the options considered, and what they would do differently now.
Difficulty that turns out to be learning a library, or a problem solved by adding a dependency.
03What specific features of React have you worked with?
Listen forFeatures tied to problems they solved, with a view on which ones they avoid and why.
Feature lists with no application, or newer features adopted without understanding what they replace.
State decisions explained
3 questions04Can you explain how you manage state in React?
Listen forState located deliberately with server and client state distinguished, and the choice justified for that application.
Everything held in global state, or the same library reached for regardless of the application's needs.
05How do you structure your React projects, and why?
Listen forA structure they can justify, with a view on how it holds up as a codebase grows past a few dozen components.
Structure copied from a starter template with no reasoning, or organisation by file type at any scale.
06Do you have experience with React hooks?
Listen forDependency arrays and effect behaviour understood properly, with a bug caused by a missing or wrong dependency.
Effects used for everything, or dependency warnings suppressed rather than understood.
Profiling not guessing
4 questions07How do you ensure the performance of a React application?
Listen forA problem found with the profiler, with the cause identified and the measurement before and after the fix.
Memoisation applied everywhere as a default, or performance work with no measurement behind it.
08Do you have experience with testing React applications?
Listen forTests written around behaviour rather than implementation, with a regression a test of theirs caught.
Tests that break on every refactor, or testing described as the quality team's responsibility.
09What techniques do you use for debugging React applications?
Listen forComponent and profiler tools used properly, with a specific bug diagnosed through them rather than by trial.
Debugging described as adding log statements, or no use of the framework's own tooling.
10What is your approach to handling errors in a React application?
Listen forError boundaries and asynchronous failures both handled, with what the user sees when something fails.
Errors handled only in development, or failures that leave the interface in an unrecoverable state.
Components tested
2 questions11Can you provide examples of how you have used React in a collaborative team environment?
Listen forShared conventions agreed with a team, including how they handled a disagreement about approach.
Works alone by preference, or conventions imposed with no discussion.
12What best practices do you follow when writing React code?
Listen forPractices they can justify from experience rather than recite, including one they have changed their mind about.
Rules quoted from documentation with no reasoning, or practices applied regardless of context.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Explains re-render causes precisely, names memoisation pitfalls, writes typed custom hooks, and distinguishes server from client components confidently.
Systems and trade-offs
25%5Justifies state and routing choices against real constraints, cites bundle or Lighthouse numbers, and admits where the trade-off later hurt.
Evidence and rigour
25%5Cites measured before and after figures on render time or LCP, and describes tests that caught actual regressions in production.
Collaboration and communication
15%5Describes concrete handoff friction resolved, maintained a shared component library, and gives review feedback others acted on.
React is easy to write badly in a way that works for months, then does not. A one-way video screen asks about a re-render problem they actually diagnosed.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for a React developer take?
Ten to fifteen minutes across eight to ten questions, answered async. Enough to establish what they built and maintained, test their state reasoning, and hear one performance problem they profiled.
Should this replace a coding exercise?
No, it goes before one. The screen removes candidates who cannot explain their own architectural decisions, which is a large share of the pool, so exercises are only reviewed for people likely to pass.
Evaluating answers
What is the strongest signal when screening a React developer?
A rendering problem they diagnosed. Developers who have maintained an application describe the profiler output and the cause. Anyone who solves performance by adding memoisation everywhere has been guessing.
How do I judge state management answers?
Ask why they chose their approach. Good answers weigh what the application actually needed against the complexity added. Anyone who reaches for the same library every time has not made a decision.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
