How to hire a React developer.

What years of experience will not tell you

React has a low floor and a high ceiling. An engineer can be productive within weeks and can also spend five years never learning why their application re-renders as much as it does.

The gap between a competent React developer and a strong one shows up in three places: how they structure state, how they think about rendering cost, and how they handle data that comes from a server. None of these appear on a CV.

Questions that reveal actual depth

• Where does this state belong, and why not one level higher or lower?
• This component re-renders more than expected. How would you find out why?
• When would you reach for useMemo, and when is it not worth it?
• How do you keep server data and client state from drifting apart?
• What does a key prop actually do when a list reorders?
• When would you use a ref instead of state?

Signals that mislead

A few things look like competence and frequently are not.

Fluency in a specific state management library says more about which company they worked at than about their judgment. Knowing Redux thoroughly is useful; reaching for it reflexively on every project is a signal in the other direction.

Similarly, memoising everything is not a performance strategy. An engineer who wraps every component in memo without a measurement has learned a ritual, not a technique. Ask them how they would know whether it helped.

Finally, be cautious about portfolio sites as evidence. They demonstrate taste, which matters, but they say almost nothing about how someone behaves in a large codebase with other people's code in it.

A screening structure that works

Thirty minutes of conversation about a project they have actually shipped, pushing for specifics: what broke, what they would do differently, which decision they regret. Engineers who have genuinely owned production systems answer these easily and concretely.

Then sixty minutes of pairing on a small, realistic problem in a repository that already exists. Not an algorithm puzzle. Give them a component with a real defect - a stale closure, a missing dependency, an unnecessary re-render - and watch how they investigate.

What you are assessing is process rather than speed. Do they read before editing? Do they form a hypothesis and check it? Do they say when they are unsure? These predict performance on your codebase far better than whether they arrive at the answer in the allotted time.

Check the TypeScript separately

Almost all current React work is TypeScript, and React fluency does not imply TypeScript fluency.

Ask how they type a component that accepts either of two shapes of props. A strong answer reaches for a discriminated union. A weaker one reaches for optional fields on a single interface, or for any. That single question separates a large portion of candidates.