How to hire a full-stack React and Node developer
Start by accepting that React and Node is not a specialism. It is the most common web stack in professional use, so requiring it removes almost nobody from your candidate pool and gives you no signal about quality. The differences that decide whether a hire works are underneath the stack: how they hold state, what they do when a request is slow, and whether they have ever operated the thing they built.
Does asking for React and Node narrow anything?
Barely. Almost every web developer who has worked on a product in the last several years has used both, so the requirement functions as a spelling check rather than a filter. It is worth stating in the advert because candidates search for it, but it should not appear in your evaluation criteria.
What does narrow things is the surrounding shape: whether the React is a single-page application talking to a separate API, or a server-rendered framework where the boundary between client and server moves around, and whether the Node service owns a database or mostly orchestrates other services. Those are meaningfully different jobs with the same two words on top.
So the useful version of the requirement names the architecture, not the libraries. A candidate who has built a server-rendered app with streaming and a candidate who has built a single-page app against a REST API have both used React and Node, and only one of them has met your problems.
What actually varies between two React and Node developers?
Five things, and none of them appear on a CV. Each has a question that surfaces it quickly, and the answers are unrehearsed because these are not the questions candidates prepare for.
| Dimension | Weak answer sounds like | Strong answer sounds like | Question that surfaces it |
|---|---|---|---|
| State in React | Everything in a global store, or everything in useEffect | Server state, URL state and local state kept separate on purpose | Where does data from the API live in your components? |
| Data fetching | Fetch on mount, then fetch again when it looks stale | Names request waterfalls and how they collapsed them | How do you avoid a page making six sequential requests? |
| Node under load | Add more instances | Knows the event loop is single-threaded and what blocks it | What happens if one request does heavy CPU work? |
| Database access | The ORM handles it | Has read generated SQL, recognises an N+1, knows about pooling | How did you find the last slow query you fixed? |
| Operating it | Someone else deploys | Describes a real incident and how they saw it | How did you find out the last time production broke? |
Where do React and Node projects usually go wrong?
In four recognisable places. Request waterfalls on the client, where a component fetches, renders a child, and the child fetches again, producing a page that is correct and slow for reasons no single line of code explains. Anyone who has debugged this once talks about it unprompted.
Blocking the Node event loop is the second. Node handles many concurrent requests precisely because nothing it does should hold the thread, so one synchronous image resize or one large JSON parse stalls every other request on that instance. Developers who have only worked on low-traffic services often have never seen this, which is not disqualifying but should be known before hiring.
The other two are the ORM emitting a query per row without anybody noticing until the table grows, and connection exhaustion when a service designed for long-lived processes is deployed somewhere that starts a new one per request. All four are ordinary, all four are cheap to ask about, and none of them are visible in a portfolio.
How much does framework churn matter?
Less than the release notes suggest, and it is a poor hiring filter. The React ecosystem changes its recommended patterns regularly, and a developer who last shipped on an older pattern is not out of date in any way that costs you more than a fortnight.
What does not change is the underlying judgement: what belongs on the server, what has to be interactive, how to avoid fetching the same thing three times, and how to keep a cache honest. Those transfer across every version and every framework, and they are what you are actually buying.
The practical filter is whether a candidate can explain why a pattern changed rather than just which one is current. Someone who can articulate what problem server components were meant to solve understands the trade; someone who only knows that it is the new way will be equally lost when the next change arrives.
Where do you find them?
Three routes, with different economics. Direct hiring through your own network and job boards is the cheapest per hire and the slowest, and it works well when your product is interesting enough to describe in two sentences. It works badly when you need someone within weeks.
Agencies and development partners are faster and carry a margin, and the honest reason to use one is not access to talent but the transfer of the assessment burden and the replacement risk. That is worth paying for when you have nobody internal qualified to judge a developer, and worth less when you do.
Contract marketplaces sit between the two and vary enormously in quality, because the filtering is left to you. If you go this route, the assessment process matters more than anywhere else, since the platform's own ratings mostly measure responsiveness and delivery of small tasks rather than the judgement you are hiring for.
What can you test in an afternoon?
Give them a small running application with a specific, real defect and watch them find it. A page that makes sequential requests when it could make one, or an endpoint that returns the right data slowly because of a query inside a loop. Ninety minutes, their own editor, screen shared, and a clear statement that you care about the reasoning rather than the fix.
The signal is in the order of operations. Strong candidates look at what is actually happening before they change anything: network panel, logs, the generated query. Weaker candidates start editing code and reason forwards from a guess. This distinction predicts a great deal and takes one session to observe.
Then ask them to say what they would do if the fix were not obvious within an hour. Willingness to say they would ask, and specifically who they would ask and what they would bring to that conversation, is a more useful signal than confidence.
Common questions
- Is React and Node a specialism worth filtering for?
- Not really. It is the most widely used professional web stack, so requiring it removes almost nobody from the pool. Name it in the advert because candidates search for it, but keep it out of the evaluation criteria. What genuinely narrows the field is the architecture around it: server-rendered with a moving client boundary is a different job from a single-page application talking to a separate API.
- What should you ask a Node developer in an interview?
- Ask what happens when one request does heavy CPU work. Node processes many concurrent requests because nothing should hold its single thread, so one synchronous resize or large parse stalls every other request on that instance. A developer who has seen this explains it immediately. Also ask how they found the last slow database query they fixed, which reveals whether they have ever looked at generated SQL.
- What goes wrong most often in React and Node projects?
- Four things recur: client request waterfalls where a component fetches, renders a child, and the child fetches again; blocking the Node event loop with synchronous work; an ORM issuing one query per row unnoticed until the table grows; and connection exhaustion when a service written for long-lived processes runs somewhere that starts one per request. All four are ordinary and none appear in a portfolio.
- Does it matter if a candidate has not used the newest React patterns?
- Rarely. Recommended patterns in this ecosystem change regularly and catching up costs a capable developer a couple of weeks. The judgement that transfers across versions is what belongs on the server, what must be interactive, and how to keep a cache honest. A useful filter is whether the candidate can explain what problem a new pattern was meant to solve, rather than only knowing which pattern is current.
- Where is the best place to hire a full-stack React and Node developer?
- Direct hiring through your own network and job boards costs least per hire and takes longest. Agencies and development partners cost more and the real thing being bought is transfer of assessment and replacement risk, which is worth paying for when nobody internal can judge a developer. Marketplaces sit in between and leave the filtering to you, so the assessment process matters most there.
- How do you test a full-stack developer in one session?
- Hand them a running application with a real defect, such as a page making sequential requests or an endpoint slowed by a query inside a loop, and give them ninety minutes in their own editor with the screen shared. The signal is the order of operations: strong candidates observe what is happening in the network panel, logs and queries before changing anything, while weaker ones start editing from a guess.
