React developer screening questions for recruiters

Screening a React developer means checking that they have built real screens with React, know how data and state move through an app, and can explain how they keep a page fast and usable. Fifteen to twenty minutes is enough for that, and the answers are easier to judge than you might expect, because good front-end developers describe things you can picture.

What does a React developer do?

A React developer builds the part of a web application people see and click, using React, a JavaScript library for building user interfaces. The Bureau of Labor Statistics describes front-end web developers as creating "the technical features for a website's look," including the layout and pieces such as a retail checkout tool. Day to day, that means turning designs into components, connecting them to APIs, testing them and fixing what breaks in the browser.

The tools have moved. React's version page lists 19.3 as the latest version (React 19 first shipped in December 2024), and in February 2025 the React team deprecated Create React App for new apps, recommending a framework such as Next.js or React Router, or a build tool such as Vite.

Which skills should you check at each level?

What screening questions should you ask a React developer?

We wrote these for this page. If the team uses Angular or Vue, most of them still work with the framework name swapped.

Walk me through a screen you built in React, from the design you were handed to the finished page.

This shows how they break a design into parts and who they worked with.

Strong answer: names the components, where the data came from, where state lived, what showed while data was loading or if it failed, and how the layout worked on a phone.

Weak answer: "I built the UI using React and CSS."

When do you keep state inside one component, and when do you move it somewhere shared?

Where state lives decides how hard a React app is to change later.

Strong answer: local state for things only one component cares about (an open menu), shared state when several parts of the page need it, and a data-fetching library for server data. They mention a time too much global state caused bugs.

Weak answer: "I always use Redux" or "I use useState for everything," with no reason.

A search box feels slow when someone types. How do you find out why?

Performance questions show whether they measure or guess.

Strong answer: opens the React DevTools Profiler to see what re-renders and checks whether every keystroke fires an API call. Then they fix the cause: waiting until the user pauses before searching, memoizing where it helps, or a virtualized list for long results.

Weak answer: "I'd wrap everything in useMemo."

How did you set up your last React project, and why that tool?

The answer tells you how current their experience is.

Strong answer: Vite, Next.js or React Router, with a reason (server rendering, routing, build speed). If the project used Create React App, they know it's deprecated for new apps and what they'd use instead.

Weak answer: can't name the setup, or plans to start a new project in 2026 with Create React App.

How do you test a React component?

This shows whether they test what users do or only check that the code runs.

Strong answer: React Testing Library with Jest or Vitest, testing what a user sees and does (clicks, typed text, messages on screen), mocking API calls, plus a few end-to-end tests in Playwright or Cypress.

Weak answer: "QA tests it," or only snapshot tests.

How do you make a form usable for someone on a screen reader or using only a keyboard?

Clients with public-facing sites often require accessibility work, and it's easy to leave out of a screen.

Strong answer: real labels tied to inputs, buttons that are actual buttons, a sensible tab order, visible focus, error messages a screen reader announces, and testing with a keyboard and a screen reader. They may mention WCAG, the common accessibility standard.

Weak answer: "Add alt text to images," and nothing about forms.

What did TypeScript catch for you on a recent project?

Asking for a catch, rather than a definition, shows whether they used it seriously.

Strong answer: a specific bug, such as an API field that could be missing, caught before it shipped, plus how they typed component props and API responses.

Weak answer: "We used TypeScript, but mostly with any."

What red flags should you note?

• For a mid-level role, a portfolio of tutorial projects only (a to-do list, a weather app) and nothing from a job or real users.
• Every answer is about class components and lifecycle methods when the team's code uses hooks.
• They say they did "the full stack" but can't name the API their front end called.
• A GitHub project they can't walk you through.
• Answers about accessibility or testing that start and end with "the QA team handles it."

A red flag is a prompt for a follow-up. If you suspect someone else is speaking for the candidate, read how to spot a proxy interview.

How do you run this screen with Simplehire?

Create the role with its required skills, for example React, TypeScript, Next.js, React Testing Library and accessibility, and send the candidate the interview link. They talk with our AI interviewer in the browser; you get a screening report when they finish.

Junior and high-volume front-end roles can start on Basic ($2 per screen, about 15 minutes). Before client submission, Adaptive ($3, about 20 minutes) adds follow-up questions on the candidate's answers and a per-answer AI assessment. Senior or client-critical roles fit Advanced ($5, about 30 minutes), and its optional coding round, scored separately from the conversation, lets the client see code.

Front-end candidates often bring a portfolio, and the report gives you the conversation to set beside it: a verdict, Skills demonstrated X/Y and Areas to probe. The decision is yours. Every screen runs with proctoring on: enforced full-screen, copy and paste restricted or flagged, and tab switches recorded for a person to review. Try it on 25 free Basic screens a month (pricing).

For roles that include the back end, use the full-stack developer questions. Front-end teams that hire testers can use the QA automation engineer questions.