How to assess · For hiring teams

How to Assess React Skills When Hiring

The test formats that actually work for React, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.

The short answer

Assess React with a task, not a conversation: live coding / component build, take-home component or mini-app, ai-generated coding assessment, code review of a flawed component or mcq knowledge check. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.

Has a clear mental model of rendering: what triggers a re-render and how to avoid unnecessary ones
Uses hooks correctly, respects the rules of hooks, and writes clean custom hooks to share logic
Manages state deliberately: knows what belongs in local state, lifted state, context, or a store
Uses useEffect for genuine side effects, with correct dependencies and cleanup, not as a catch-all

Build a React assessment →Read the full article ↓

Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.

When you are hiring a React developer, you are testing two things at once: solid JavaScript and a real mental model of how React renders and manages state. React is the most claimed front-end framework on the market, and many candidates can scaffold a component yet stumble on re-render behaviour, hooks rules, and state architecture. As a recruiter or hiring manager, you need an assessment that goes past "can build a to-do list." This guide covers what to test, which methods reveal genuine ability, and how to score React skill before you extend an offer.

Why React is worth testing

React looks simple in tutorials and gets hard in real apps, where unnecessary re-renders, tangled state, and misused effects cause bugs and slow performance. Because React sits on top of JavaScript, a candidate can know component syntax yet lack the underlying language depth. Testing directly reveals whether someone understands the render model, hooks, and state architecture, which is exactly what determines maintainability and how much rework you will inherit.

What strong React looks like

Has a clear mental model of rendering: what triggers a re-render and how to avoid unnecessary ones
Uses hooks correctly, respects the rules of hooks, and writes clean custom hooks to share logic
Manages state deliberately: knows what belongs in local state, lifted state, context, or a store
Uses useEffect for genuine side effects, with correct dependencies and cleanup, not as a catch-all
Composes small, reusable components and keeps them readable and well-typed
Reasons about performance: memoisation, keys in lists, and avoiding expensive work on every render
Has solid underlying JavaScript: async data fetching, immutability, and clean data handling

Ways to assess React

Live coding / component build

A 30 to 45 minute screen-share building or extending a component, such as a searchable list with data fetching and loading states.

Pros

Shows real React thinking: state design, effect usage, and how they handle async and edge cases.

Cons

Setup and environment quirks can eat time, and pressure may suppress otherwise strong candidates.

Best for Mid and senior front-end roles where component architecture and state design matter.

Take-home component or mini-app

A scoped feature built on the candidate's own time, such as a small dashboard that fetches and displays data.

Pros

Reveals structure, component composition, typing, and testing habits closer to real work.

Cons

Authorship is hard to verify, starter templates and AI inflate results, and large tasks deter good candidates.

Best for Roles where production-quality component code and project structure are the priority.

AI-generated coding assessment

An automated test like Cohesyve's that gives each candidate a unique React problem in a live IDE with real test execution.

Pros

Cheat-proof and scalable: unique problems cannot be shared or pasted from a tutorial, and scoring is objective and async.

Cons

For senior architecture hires, add a short discussion to probe design trade-offs.

Best for High-volume front-end screening before committing interviewer time.

Code review of a flawed component

Hand the candidate a component with bugs (missing dependencies, key misuse, unnecessary re-renders) and ask them to critique and fix it.

Pros

Surfaces depth fast: spotting subtle render and effect bugs is a strong signal of real experience.

Cons

Requires a well-crafted example and an interviewer who can judge the critique.

Best for Senior and lead hires who will review others' React code.

MCQ knowledge check

A short quiz on hooks rules, the render lifecycle, and reconciliation basics.

Pros

Fast, consistent early filter on conceptual understanding.

Cons

Cannot show whether a candidate writes clean, working components.

Best for An early gate before a hands-on stage, never as the sole signal.

Cohesyve

Run a React assessment on your next opening

Cohesyve generates a unique React task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.

Try it free →Book a 30-min demo

What to test

Rendering model and reconciliation

Whether the candidate understands what causes re-renders and how React decides what to update.

Explain what triggers a component to re-renderExplain why keys matter in a list and what breaks without stable keysIdentify why a component re-renders too often and fix it

Hooks and state management

Correct use of useState, useEffect, useMemo, useCallback, and custom hooks, plus where state should live.

Refactor duplicated logic across components into a custom hookDecide whether a piece of state belongs in local state, lifted state, or contextFix a stale-closure bug in a useEffect callbackExplain when useMemo and useCallback actually help versus add noise

Side effects and data fetching

Effects are widely misused. Test correct dependencies, cleanup, and async handling.

Fetch data in a component with loading and error statesAdd cleanup to cancel a request or subscription on unmountExplain why a missing dependency causes a stale value

Component design and composition

Building reusable, readable components and lifting state sensibly.

Break a large component into smaller composable piecesDesign a reusable, controlled input componentDecide between props drilling, context, and a store for shared state

Performance and underlying JavaScript

React performance and the JavaScript skills underneath it.

Memoise an expensive computation and justify the choiceImmutably update nested state without mutating itDebounce a search input that drives a data fetch

Sample React questions

What is the difference between props and state in React?

Entry

Look for Strong: props are passed in and read-only to the child, state is local and mutable via the setter, and changes to either trigger a re-render. Weak: vague or treats them as interchangeable.

Build a component that fetches a list of users from an API and displays loading, error, and success states.

Entry

Look for Strong: useEffect with correct deps, cleanup or guards against state updates after unmount, clear handling of all three states. Weak: no loading/error handling, missing deps, or fetch on every render.

Why is using an array index as a key in a dynamic list a problem, and when is it acceptable?

Mid

Look for Strong: explains reconciliation issues when items reorder or are removed, recommends stable ids, and notes index is fine only for static lists. Weak: thinks any key works.

This component re-renders on every keystroke and feels slow. How would you find and fix the cause?

Mid

Look for Strong: identifies unnecessary re-renders, uses the Profiler, applies memo/useMemo/useCallback judiciously, lifts or co-locates state. Weak: sprinkles useMemo everywhere with no diagnosis.

When would you reach for context, and when is it the wrong tool?

Mid

Look for Strong: context for low-frequency global values (theme, auth), warns that frequent updates cause broad re-renders, suggests a store for high-churn state. Weak: uses context for everything.

Explain a stale-closure bug in useEffect and how you would fix it.

Senior

Look for Strong: describes a callback capturing an old value because of missing dependencies, fixes with the dependency array or a functional updater. Weak: has never hit this or just adds an eslint-disable.

How would you architect state for a medium-sized app with server data, form state, and UI state?

Senior

Look for Strong: separates concerns, a data-fetching library for server cache, local state for UI, minimal global state, and explains the reasoning. Weak: dumps everything into one global store.

Critique this component that mutates state directly and lists items without keys. What are the bugs?

Senior

Look for Strong: spots the direct mutation (no re-render or subtle bugs), the missing keys, and immutability violations, then fixes them. Weak: misses the mutation or only catches one issue.

Red flags

Cannot explain what causes a re-render or treats React as magic
Mutates state directly instead of using the setter and immutable updates
Uses useEffect as a catch-all and cannot reason about its dependency array
Reaches for context or a global store for everything, causing broad re-renders
Uses array indexes as list keys without understanding the consequences
Strong on component syntax but weak on the underlying JavaScript (async, immutability)
Sprinkles useMemo and useCallback everywhere with no idea whether they help

Scoring rubric

Criterion	Weight	What strong looks like
Rendering model and reconciliation	25%	Understands what triggers re-renders, uses stable keys, and avoids unnecessary work on render.
Hooks and state architecture	25%	Uses hooks correctly, writes clean custom hooks, and places state where it belongs.
Side effects and data fetching	20%	Uses effects only for real side effects, with correct dependencies, cleanup, and loading/error states.
Component design and underlying JavaScript	20%	Composes small reusable components and shows solid async, immutability, and data-handling skills.
Performance reasoning and communication	10%	Diagnoses performance issues before optimising and explains trade-offs clearly.

Mistakes hiring teams make

Testing only a basic to-do app, which any tutorial graduate can build
Assuming React skill without checking the underlying JavaScript it depends on
Over-weighting framework trivia and the latest API names over real component design
Trusting a long list of front-end tools on the resume as proof of depth
Giving take-homes where a starter template or AI does most of the work
Ignoring how the candidate reasons about re-renders and state, which predicts maintainability

Roles that need React

React DeveloperFront-End DeveloperFull-Stack DeveloperUI EngineerFront-End EngineerJavaScript EngineerWeb Application DeveloperSoftware Engineer

Common questions

Should I test React skills separately from JavaScript?

Test both, but remember React sits on top of JavaScript. A candidate who is strong on component syntax but weak on async, immutability, and data handling will struggle in real apps. Confirm the JavaScript foundation first, then assess the React-specific mental model of rendering, hooks, and state.

How do I avoid hiring someone who can only build a to-do list?

Push past CRUD. Ask them to handle real data fetching with loading and error states, diagnose an unnecessary re-render, or decide where state should live. These reveal whether someone understands React's render model or has only followed tutorials. A flawed-component code review is especially good at exposing depth quickly.

How can I screen many React applicants without overloading my engineers?

Use an automated, hands-on screen. An AI-generated assessment like Cohesyve's gives each candidate a unique React problem in a live IDE with real test execution, scored objectively and async, so unique problems cannot be shared or pulled from a tutorial. Your engineers then interview only candidates who already cleared a real coding bar.

Is it fair to test React without letting candidates use their usual libraries?

Match the test to the job. If your team relies on a data-fetching or state library, let candidates use it, since that is how they will work. What matters is that the problem reveals their understanding of rendering, state, and effects rather than memorisation of a specific API surface.

Cohesyve · Skill assessments for hiring

Test React before the first interview

Generate a role-specific React assessment from your job description and see who can do the work before you spend interview time on them.

1,500+

assessments completed

50%

faster time-to-hire

90%

completion rate

5 min

from JD to assessment

No credit card · 10 free candidates · Plans sized to your hiring volume

From the blog

Related skill guides