Ten years of React are all on the market at once.
React has changed enough that an engineer who stopped learning in 2019 writes code your current team will quietly rewrite. The CV says React either way, and so does the interview unless somebody asks the right questions.
class OrderList extends React.Component {
componentDidMount() {
fetch('/api/orders')
.then(r => r.json())
.then(orders => this.setState({ orders }));
}
render() { /* ... */ }
}function OrderList({ customerId }) {
const { data, isPending, error } = useQuery({
queryKey: ['orders', customerId],
queryFn: () => getOrders(customerId),
});
// loading, error and stale states handled
// by the library, not by hand, every time
}The library is the same. Almost everything around it is not.
Class components to hooks was the visible change and is the one every candidate can talk about. The changes that affect your codebase are quieter: how server data is fetched and cached, what state management is still for once it is, and how much of the application should render on the server.
An engineer who moved to hooks but is still storing server responses in a global store and hand-writing loading and error states will produce a codebase that works and is roughly twice the size it needs to be. Reviewers who learned React the same way will not flag it.
This is the single most common quality gap we see in React hiring, and it is invisible to a generic screen because everything the candidate says is true, just several years out of date.
The other half is what React has never covered. Accessibility, bundle size, rendering performance on the devices your users actually have, and form handling at real complexity are all outside the library and all things a strong front-end engineer has opinions about. Those opinions are what we screen for, because they are what separates somebody who can build a screen from somebody who can own a front end.
What we ask a React engineer.
None of these are trick questions. All of them separate current practice from practice that stopped developing several years ago.
Where does server data live?
The single most discriminating question. A query library with caching, or a global store full of server responses and hand-written loading flags.
What is state management still for?
Once server state is handled properly, most applications need very little client state. Candidates who reach for Redux by default have not made that shift.
Why did this re-render?
We want the profiler, not a guess, and an understanding of when memoisation helps and when it is cargo cult.
How do you test a component?
Testing what the user sees, not internal state. Candidates testing implementation detail write tests that break on every refactor.
How does this behave for a keyboard user?
Accessibility is not a specialism, it is part of the job. This question is answered well surprisingly rarely.
What is in your bundle?
An engineer who has never looked at a bundle analysis has never been accountable for how the application performs on a mid-range phone.
React is rarely the whole job.
Being explicit about these up front changes who we put forward, and stops the third-month conversation about what was in scope.
| Also needed | How often | Who covers it |
|---|---|---|
| TypeScript | Almost always | Any React engineer we would put forward |
| Next.js or a meta-framework | Frequently | Specify it; it changes the profile |
| Design system work | Frequently | React engineer, with a designer for the system itself |
| Accessibility to a standard | Increasingly, and often contractually | React engineer, we screen for it |
| Back-end work | Sometimes | Full-stack or a separate hire |
| Visual design | Sometimes | A designer. React engineers are not designers |
| React Native | Sometimes assumed, wrongly | A different hire |
Three kinds of front-end brief.
The middle one is the most valuable work we do in React and the least advertised, because it does not look like a project until you see the bill for the alternative.
New product front ends
Design system, component library, data layer and an accessibility standard agreed at the start rather than retrofitted after somebody asks. See product engineering.
Design system TypeScript AccessibilityReplacing a legacy front end, leaving the back end alone
Screens rebuilt against a JSON contract while the engine, the database and twenty years of business rules stay exactly where they are. See ColdFusion to React.
Reversible Ships per screen No platform riskInterfaces for AI features
Streaming responses, citation display, correction and approval flows. A different interaction problem from CRUD, and one most front-end engineers have not met. See copilots.
Streaming Citations Human approvalRates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring React engineers.
The three that most affect who we put forward.
How do we tell a current React engineer from an out-of-date one?
Ask where server data lives and listen for what they do not say. An engineer working currently will describe a query library that handles caching, revalidation, loading and error states, and will treat that as unremarkable. An engineer whose practice stopped developing around 2019 will describe fetching in an effect, storing the result in a global store, and managing loading flags by hand, and will describe it confidently, because it was correct when they learned it. Neither is dishonest and the CV is identical. It is a five-minute conversation and it is the highest-value question in a React interview; we run it on every candidate before you see them.
Do we need Next.js?
Only if you need what it does, and many teams adopt it for reasons that do not apply to them. It earns its place when you need server rendering for public pages that must be indexed or must load fast on poor connections, or when you want file-based routing and an integrated build without assembling one. For an authenticated internal application behind a login (which is a large share of what gets built), it adds deployment complexity and a rendering model your team has to reason about, in exchange for benefits nobody will notice. We would ask whether anything needs to be indexed, and answer from there.
Can a React developer also work on our React Native app?
Partly, and the gap is larger than the shared name suggests. The component model, hooks and state management transfer directly, so a React engineer will be productive on screens quickly. What does not transfer is everything below that: navigation, native modules, platform-specific behaviour, build and signing, store submission, and debugging something that only happens on one Android manufacturer's firmware. A React engineer will manage feature work on an existing, well-set-up React Native app. They should not be the person who sets it up, owns the release process, or diagnoses a native crash— see React Native developers.