Most vetting processes are a diagram with six boxes and no content. This is the content: what each stage is for, what it actually catches, and where it fails. We run it ourselves, which means the article doubles as a description of what we would put you through, and as an invitation to hold us to it, since publishing a process is only useful if someone can check that it happened.
The short version
Six stages, and every engineer completes all six before being put in front of a client.
The written questions matter more than the live interview. They test the thing the job consists of: reasoning about someone else's code.
Test on real code from a real codebase, not a puzzle. Puzzles select for people who practise puzzles.
The stage that catches the most is the pull request review, and almost nobody runs it.
Vet for the ability to say "I do not know". It is the most predictive signal in the whole process.
The six stages, and what each one is for
Each stage exists to catch something the previous one cannot. Running them out of order, or skipping the cheap ones, is how a process ends up expensive and unreliable at the same time.
-
01
Written application, read properly
Not a CV scan. A short set of questions about work they have actually done. Catches: people applying to everything, and people who cannot write.
-
02
A thirty minute conversation
No technical questions. What they worked on, what they would change, what they disagreed with. Catches: mismatched seniority, and people describing a team's work as their own.
-
03
Four written questions on real code
Sent, not supervised. Two to three hours of work on a small extract of a real codebase, with the questions below. Catches: most of what matters.
-
04
A pull request review, in their words
We send a PR containing three deliberate problems and ask for a review. Catches: whether they can improve code they did not write, which is the job.
-
05
A live pairing session
Ninety minutes on a bug in a codebase they have not seen, with our engineer alongside. Catches: how someone behaves when stuck, and whether they narrate their thinking.
-
06
References from an engineer, not a manager
Managers report reliability. Engineers report whether they would take the code back. Catches: the gap between the two.
Stage four is the one almost nobody runs, and in our experience it is the most predictive of the six. Writing new code from a blank file is a small part of the job. Reading, judging and improving code somebody else wrote under time pressure is most of it, and it is a distinct skill that a greenfield exercise does not test at all.
The same six stages sit behind every engineer we place, which is why they are also written out on the hire React developers page alongside the replacement terms.
The four written questions
These go out as a short repository with a README. Candidates are told to spend no more than three hours and to leave notes where they ran out of time. We mean that, because a process that quietly rewards people who spent nine hours is selecting for who had a free weekend.
The fourth question is the one that sorts senior from mid, and it is the only one where the interesting part is not the code. A strong candidate leaves things alone deliberately and can say which things and why. A weaker one rewrites everything, which reads as thoroughness and behaves, on a real codebase, as risk.
Where our interests differ from yours
Publishing our take-home means candidates can prepare for it, which makes it weaker for us over time. We publish it anyway because a vendor claiming a rigorous process without showing it is asking you to take vetting on trust, and that is the one thing you cannot verify after the fact. If you use these questions yourself, change the codebase they sit on.
If you would rather see the questions themselves with model answers, they are broken down in React interview questions that actually work.
What the answers tell you
Reading a take-home well is a skill in itself. These are the things we score, roughly in order of how much they predict performance six months later.
"The most predictive sentence in any take-home is "I was not sure whether X, so I assumed Y and here is what I would ask." Almost nobody writes it, and almost everybody who does turns out to be good."
The live session, and how not to waste it
By stage five you already know whether the person can write React. The live session is not there to confirm it. It is there to watch someone meet a problem they cannot immediately solve, in front of another person, which is a situation they will be in constantly.
Use a real bug
One from your own history, with the fix removed. Reproducible, unfamiliar, and solvable in ninety minutes by someone competent.
Let them use everything
Documentation, search, an assistant if they want one. Banning tools tests memory, and memory is not the constraint at work.
Watch the first ten minutes
Do they reproduce it before theorising? Read the error properly? Narrate? That is the whole signal, and it appears early.
The failure mode of this stage is the interviewer enjoying themselves. If your engineer is steering, hinting and filling silences, you are assessing the interviewer. Agree beforehand that they stay quiet for the first ten minutes and answer only direct questions.
A live session is also the closest thing to the first week of a real engagement, which is what a two week paid pilot tests at a larger scale.
The placement we got wrong
A candidate cleared all six stages with the strongest take-home we had seen that year. Nine weeks into the engagement the client asked us to replace them, and they were right to.
Nothing about the code was the problem. The problem was that they went quiet when blocked. A question that should have taken a message on Tuesday became four days of independent investigation and a solution to a problem nobody had. Every stage of our process had been solitary or supervised, and neither of those observes what somebody does with an ambiguity when nobody is watching.
What changed: stage two now includes a direct question about the last time they were blocked and what they did, stage five deliberately includes an ambiguity we will not resolve unless asked, and every engagement now has a written standing rule that thirty minutes of being stuck means posting the question and switching tickets. We also stopped billing for the weeks in question, which is the part that made the lesson stick.
What running this actually costs
A process is only real if someone is paying for it. Ours costs roughly nine hours of senior engineering time per candidate who reaches stage three, and most candidates do not.
Stages 1–2
~40 mins
Reading the application properly and a half-hour conversation. Cheap, and removes most of the field.
Stage 3
~90 mins
Reading a take-home carefully enough to score it fairly. The single largest cost, and not compressible.
Stages 4–5
~3 hrs
PR review plus a live pairing session with a senior engineer present throughout.
Stage 6
~40 mins
Two reference calls, with engineers rather than managers, which take longer to arrange than to hold.
That cost is the reason thin vetting is cheap and why cheap vendors have thin vetting. It is also why the process only makes sense if the engineer stays: at high turnover you are paying it repeatedly and amortising it over months rather than years.
Vetting cost is one input to a rate. The rest of what you actually pay for is in what an offshore team really costs.
Where the candidates actually come from
A process is only as good as the people entering it. Ours has changed shape more than once because the sourcing changed, and the two are harder to separate than hiring advice usually admits.
The second row is worth the effort it costs. Reading somebody's open source contributions, or a post they wrote about a problem they solved, tells you more in twenty minutes than a CV does in any amount of time, because it is the real artefact rather than a description of one. It does not scale, which is precisely why it works: everyone else is skipping it.
One thing we would advise against: judging candidates on the popularity of their public work. Stars measure marketing. Read the code, the commit messages and how they responded to an issue from a stranger, and ignore the counter entirely.
Public work is the strongest signal available before you speak to anyone, which is the same reason our own case studies carry real numbers rather than logos.
Calibrating the bar, and the rejection to worry about
Every hiring process has two error modes and they are not symmetrical in how visible they are. A bad hire is loud, expensive and remembered. A good candidate wrongly rejected is silent, costs nothing today, and never appears in a retrospective. Processes therefore drift towards being too harsh, because only one of the two errors ever gets discussed.
The last one is the most common failure we see in client hiring processes, and it is fixable in an afternoon. If a panel cannot describe, in a sentence, what the candidate would have had to do differently to get an offer, then the process is not measuring anything. It is producing a feeling with a scorecard attached.
The first two weeks after they start
Vetting is a third of the outcome. What happens in the fortnight after someone joins decides most of the rest, and it is almost entirely within your control rather than theirs.
The trivial merge on day one matters more than it looks. It proves access, environment, CI and review in a single pass, at a moment when discovering a broken deployment costs an hour rather than a sprint. Teams that skip it routinely find out in week two that the new engineer has never successfully deployed anything.
The Friday retrospective is where the compounding happens. The observations of somebody in their first week are the most valuable documentation feedback you will ever get, and they have a shelf life of about ten days before everything confusing becomes normal.
Week one is also where overlap hours start to matter: a reviewer who answers the same day is worth more than any onboarding document.
Questions people ask
Where to go next
The four questions in full, with what a good answer sounds like, are in React interview questions that actually work. If you are costing a team rather than assessing one, what React development costs covers what moves the number. Our own terms are on the hire React developers page.
Yogesh Jadhav
Founder of reactdevstudio. Ten years as a working full stack developer, across SaaS products and client work.
Related, Group B only
Three more on engineering
Engineering posts only, scored within Group B, so a technical reader is never handed a procurement checklist.