Real Broken Code, Not Whiteboard Trivia
Every developer whose profile reaches you has debugged something genuinely broken, reviewed a pull request with real problems buried in it, and defended a system design decision including the trade-off they would refuse to make.
The Gap Between Reading About Production and Living In It
Almost every JavaScript developer can build a to-do application. Far fewer can open an unfamiliar repository, read a stack trace that points at the wrong file, and work out in twenty minutes that the real problem is a cache invalidated in the wrong order. That second skill is what you are actually hiring, and it is not visible on a CV.
So the assessment is built around unfamiliar code that misbehaves, rather than blank-page problems with known answers. We are watching the reasoning, not the result: what the candidate looks at first, what they rule out, whether they test a theory before they change something, and how they behave for the ten minutes after they realise they were wrong.
None of this predicts brilliance, and we do not claim it does. What it reliably catches is the distance between someone who has read about production and someone who has been on call for it. What you see in the profile is what turns up in your standup.
What a Candidate Goes Through Before You See Them
Tailored to the role rather than run identically for everyone. A React Native candidate spends time on device-specific failure; a Node candidate spends it on a service under load.
Live debugging on real broken code
The candidate is given a repository they have never seen and a symptom rather than a diagnosis: a request that times out under concurrency, a React view that renders stale data after a mutation, a job queue that silently drops work when the process restarts. All of these are drawn from the shape of real production failures rather than invented to have a neat answer.
We are watching the method. Do they reproduce it before changing anything? Do they read the actual error or skim past it? Do they add logging in a useful place or scatter it everywhere? When the first theory collapses, do they revise it or keep pushing? Plenty of strong candidates do not finish inside the hour, and that is not a failure — how far they got and how they got there is the signal.
Pull request review with problems buried in it
The candidate reviews a pull request that looks reasonable and is not. Somewhere inside there is an unhandled rejection, a race between two writes, a query that will be fine on a thousand rows and fatal on a million, or a type assertion that quietly disables the check it appears to perform. The obvious style issues are there as decoys.
This is where seniority separates most clearly. Junior reviewers comment on naming and formatting. Senior reviewers ask what happens when this runs twice, or when the third-party call fails halfway. We also read the tone: a reviewer who is technically right and unpleasant about it will cost you more in team friction than the bugs they catch.
System design, including the trade-off they would refuse
A conversation rather than an exam. We take something realistic — adding a reporting feature to a service that is already slow, or splitting a monolith that two teams are fighting over — and talk through how they would approach it, what they would measure first, and what they would deliberately not build yet.
Then the important question: which trade-off would you refuse to make here, and why? Anyone can list options. The people worth hiring have a line they will not cross without saying so out loud, whether that is skipping a migration plan, storing something they should not, or shipping an endpoint with no way to page through the results. A candidate with no line anywhere is agreeable in interviews and expensive afterwards.
Communication, assessed in writing as well as speech
Your developer will spend a lot of the engagement writing: pull request descriptions, standup notes, questions in a channel where the answer may take four hours to arrive. So we assess written explanation deliberately and not as an afterthought. Can they describe a decision so that a colleague reading it tomorrow understands the reasoning? Do they ask a precise question when a requirement is missing, or do they assume and build the wrong thing quietly?
We also listen for the ability to say “I do not know” without either bluffing or collapsing. In a remote engagement that one sentence, used at the right time, is worth more than another year of experience.
Work history and references
We verify what we reasonably can: where somebody worked, for how long, and what they were genuinely responsible for on the projects they cite. If a candidate describes a system they built, we ask questions that are easy to answer if they built it and awkward if they watched somebody else build it.
References are taken where they exist and are worth having. A former manager who supervised the candidate for a year is useful. A friendly peer arranged by the candidate is not, and we weigh it accordingly. Where a claim cannot be corroborated, we note that in the profile rather than quietly rounding it up.
How the Stages Narrow a Pool
The shape of the funnel, not a measured result. The figures below are invented for illustration.
Applications and approaches
Illustrative figure only — everyone who applies or is approached for a role
Screening call and work history
Illustrative figure only — stack claims checked against what they have actually shipped
Live debugging and pull request review
Illustrative figure only — the technical stages described above
Shortlisted and sent to a client
Illustrative figure only — the two or three profiles that reach your inbox
Illustrative diagram showing the shape of the process. The proportions are drawn for clarity and are not a record of any real pass rate. We do not publish an acceptance percentage, because a number without an audited denominator behind it is marketing rather than evidence.
Why There Are No Algorithm Puzzles Here
Not because they are too hard. Because of what they measure, and what they miss.
Mostly, recent rehearsal
- Whether the candidate has spent evenings practising a specific genre of question in the last few months.
- How they perform while being watched on a problem with a single correct answer and a hidden trick.
- Recall of data structures that most application developers correctly delegate to a library or a database index.
- Tolerance for an artificial ritual, which many experienced developers have simply stopped participating in.
Nearly all of the actual job
- Reading unfamiliar code written by someone who has left, under a deadline, without a rewrite.
- Knowing which corners are safe to cut this week and which ones become next quarter’s incident.
- Asking the question that stops two days of work on the wrong interpretation of a ticket.
- Leaving the codebase a little more comprehensible than they found it, repeatedly, for months.
There is one honest argument for puzzle rounds: at enormous hiring volume they are cheap to administer and easy to score consistently. We are not hiring at that volume, so we can afford to run an assessment that costs more per candidate and tells us something closer to the truth.
What Vetting Cannot Catch
A vetting process that claims to eliminate risk is describing something other than hiring. Here is what ours genuinely does not see, which is also why the two-week replacement window exists.
What Is Actually in the Profile You Receive
Short, specific and written for a technical reader. No scores out of ten, no star ratings, no stock photography.
What they have built, in detail
The systems they worked on, their actual part in them, the scale involved and the parts of your stack they have used in production rather than in a course. Written so that you can ask a follow-up question in the interview and get a real answer.
How they performed in the assessment
A short, honest note on the debugging exercise and the review: what they spotted, what they missed, and how they reasoned. Enough for you to decide what to probe yourself rather than repeat what we already covered.
Availability, hours and notice
When they can start, the working window they can commit to, and any fixed commitments. Overlap is agreed before the engagement rather than negotiated in week two — see engagement models.
The stretch in the match
If somebody is strong on React and thinner on the Node side, or has the right skills but less experience than you asked for, the profile says so. You will find it out in the interview anyway; discovering it there instead of in the profile just costs you an hour and some trust.
Questions About Vetting
Why do you not use algorithm puzzles or whiteboard questions?
Because they measure preparation for a particular genre of interview rather than the ability to work inside a codebase. The best signal we have found is watching somebody deal with code they have never seen that is behaving badly. A puzzle round reliably filters out people who have not rehearsed recently, and that group includes a great many of the senior developers you would most want to hire.
What does the live debugging exercise actually involve?
A small but genuinely broken service or component, taken from the kind of failure that happens in production rather than a puzzle with a trick in it. The candidate gets the repository, the symptom and about an hour. We watch how they narrow it down, whether they read the error properly, whether they form a theory before changing code, and what they do when the first theory turns out to be wrong.
Do you assess communication, or only code?
Both, because in a distributed engagement the writing matters nearly as much as the code. We look at how a candidate explains a decision in writing, whether they ask for missing information instead of assuming it, and whether they can say they do not know something without either bluffing or falling apart. A developer who writes a clear pull request description saves your reviewers more time than one who is marginally faster at typing.
What can vetting not tell you?
Whether somebody will still be engaged in month nine, how they behave under a manager who is not good at the job, and whether they know your particular domain. Vetting measures capability on a representative problem over a few hours. It does not measure staying power, and anyone who claims otherwise is selling a certainty that does not exist.
Do you check references and work history?
We check work history and take references where they are available and meaningful. A reference from somebody who managed the candidate for a year is worth reading carefully. A reference arranged by the candidate from a friendly peer is worth very little, and we weigh it accordingly. Where a claim about a past project cannot be corroborated, it is flagged in the profile rather than smoothed over.
Should I still interview if you have already vetted them?
Yes. Our vetting answers whether this person can do the work. Only you can answer whether they fit your team, your review culture and the specific mess in your codebase. The point of a shortlist of three is that your interview becomes the deciding round rather than the filtering one.
See What the Vetting Produces
Send us the role and read the profiles yourself. Two or three come back within three business days, and the shortlist costs nothing whether or not you hire.