To vet software engineers properly, run a structured five-stage process: screen the CV against the real role, set a work sample that mirrors your codebase, hold a system-design conversation, review their code for reasoning rather than syntax, and verify references for delivery and behaviour. The single biggest predictor of a good hire is not years of experience or a polished CV; it is whether each stage tests the work the person will actually do.
Most hiring mistakes happen because teams over-weight one weak signal, usually a CPU-heavy puzzle or a confident interview, and skip the stages that reveal how someone builds, ships and behaves under pressure. This guide gives you a framework you can apply whether you are hiring directly, through an agency, or through a managed provider that has already done the vetting for you.
Why most engineering vetting fails
The typical hiring loop leans on signals that are easy to administer but weakly correlated with on-the-job performance. A timed algorithm test favours recent graduates and interview-circuit specialists over experienced engineers who solve real problems with documentation open. A free-flowing chat rewards confidence and shared background, which is exactly how unconscious bias creeps in.
According to public market data and industry research, a meaningful share of senior-level CVs contain claims that do not survive a practical task, and a large part of early attrition traces back to a mis-set expectation at hiring time rather than a skills gap. The cost of a wrong hire is rarely just the salary; it is the rework, the delayed roadmap and the time your best engineers spend cleaning up.
A reliable process fixes this by testing the right things in the right order, and by writing down what good looks like before anyone meets a candidate.
The 5-stage vetting framework
Each stage exists to surface a specific signal and to filter before you invest more expensive time. Run them in sequence so a strong work sample earns a system-design conversation, not the other way round.
Stage 1: Screen the CV against the real role
Start by writing the role honestly: the stack, the seniority, the autonomy expected and the problems the person will own in their first quarter. Then read CVs against that, not against a generic ideal.
- Match the stack and the seniority together. A five-year React engineer and a five-year embedded-systems engineer are not interchangeable, even with identical tenure.
- Look for ownership and outcomes, not tool lists. "Reduced checkout errors" tells you more than "used Redis".
- Treat tenure as context, not a score. Short stints can be contract roles or a startup that folded.
This stage should remove obvious mismatches only. Do not try to rank fine differences from a CV; later stages do that far more reliably.
Stage 2: Set a work sample that mirrors your codebase
A work sample is the highest-signal stage in the whole process because it tests the actual job. The best samples are a small, realistic slice of your work, not an abstract puzzle.
- Use a scoped, paid task of two to four hours, ideally a sanitised version of a real ticket.
- Provide a brief that is deliberately slightly incomplete, so you can see how the candidate handles ambiguity and what they ask.
- Score against a written rubric: correctness, readability, tests, edge cases and the questions they raised.
Keep it short and respect the candidate's time. A bloated take-home filters for the unemployed and the desperate, not the best. We cover the trade-off in depth in our guide to technical interview best practices.
Stage 3: Hold a system-design conversation
For mid-level and senior engineers, system design reveals judgement that code alone cannot. The goal is a conversation, not a whiteboard exam.
Pose a realistic, open problem from your domain and explore it together. Strong candidates clarify requirements first, name trade-offs out loud, reason about scale and failure, and know when a boring, proven approach beats a clever one. Watch for the engineer who designs for the problem in front of them rather than reciting a reference architecture they once read.
Stage 4: Review code for reasoning, not syntax
Pair the work sample with a short code-review exercise: hand the candidate a small pull request with a few deliberate issues and discuss it.
You learn how they give and take feedback, whether they spot the subtle bug as well as the obvious one, and how they reason about maintainability. This stage doubles as a culture signal: a candidate who is curious and constructive in review tends to behave the same way on your team.
Stage 5: Verify references for delivery and behaviour
References are the most skipped and one of the most useful stages. Ask former managers and peers specific, behavioural questions: how the person handled a slipped deadline, what they owned end to end, and whether they would hire them again. Verify identity and right-to-work where relevant; for offshore engagements this is a defined step, which we explain in knowledge transfer and bus-factor risk in offshore teams.
Signal versus noise: what each stage actually tells you
Not every stage carries equal weight, and treating them as equal is a common error. The table below maps each stage to the signal it produces and the noise to discount.
| Stage | High-value signal | Low-value noise to discount |
|---|---|---|
| CV screen | Stack-and-seniority fit, ownership of outcomes | Buzzword density, prestige of past employers |
| Work sample | Real-world correctness, tests, handling ambiguity | Speed alone, perfect formatting |
| System design | Trade-off reasoning, failure thinking, pragmatism | Memorised reference architectures |
| Code review | Maintainability instincts, constructive feedback | Knowing one specific framework idiom |
| References | Delivery track record, behaviour under pressure | Generic "great to work with" lines |
Weight the work sample and system design highest for output, and references highest for risk. The CV is a filter, not a verdict.
Build it in-house or buy vetted engineers
You can run this framework yourself, but it is expensive in senior engineer time: a thorough loop consumes several hours of your best people per hire, multiplied by every candidate who reaches the later stages. For one or two roles a year that is manageable. For a growing team it becomes a tax on the people you can least afford to distract.
A managed provider runs the full funnel before you ever see a candidate. OSCABE applies a five-stage vetting process for both technical ability and the communication needed to embed in a UK or EU team, then presents a shortlist that has already passed. You keep the final say and direct the work; we carry the sourcing, assessment, employment and replacement. A dedicated, fully-managed engineer starts from around £2,000 per month under one UK contract, with the vetting cost absorbed rather than billed per hour. See how the model works on /how-it-works and browse profiles on /engineers.
For teams scaling fast, the same vetting discipline applies to whole pods, which we explore in scaling a startup engineering team with offshore pods and in our managed teams overview.
Frequently asked questions
How long should vetting a software engineer take?
A focused loop runs in one to two weeks from first screen to offer. The CV screen takes minutes, the work sample two to four hours of candidate time scored asynchronously, and the system-design and code-review conversations around an hour each. Anything slower usually means too many rounds or slow scheduling, and the strongest candidates drop out of long processes. A managed provider compresses this further because the vetting is already complete; OSCABE typically matches a vetted engineer within around 72 hours of a brief.
Are take-home tests or live coding better for vetting?
Each tests something different, so the best loop uses both in moderation. A short, paid take-home reveals real-world quality, tests and how someone handles ambiguity, while a live exercise reveals reasoning and communication in the moment. Keep the take-home under three to four hours to avoid filtering for free time rather than skill, and keep the live session collaborative rather than adversarial. We compare the two in detail in technical interview best practices.
How do you vet remote engineers in India or the Middle East?
Use the same five-stage framework, then add identity, right-to-work and reference verification appropriate to the country, plus a deliberate check of asynchronous written communication because that is how distributed teams actually work. Test English clarity under realistic conditions rather than judging accent. For a country-specific walkthrough, see our guide to hiring remote developers in India, or let a managed provider handle the compliance steps for you.
Can you skip vetting if you use an agency?
Only if the agency actually vets to a documented standard and is accountable for the outcome; many staff-augmentation firms simply forward CVs and leave the assessment to you. Ask any provider to show their funnel, their rubric and their replacement policy. With a managed model like OSCABE, vetting is the core of the service rather than an add-on, which is the difference between buying a CV and buying a verified, supported engineer.
Ready to skip the funnel?
If you would rather direct the work than run a hiring loop, talk to us about your role. We vet, employ and manage dedicated engineers from India and the Middle East under one UK contract, and present only candidates who have already passed every stage above. Tell us what you need on /contact and browse vetted profiles on /engineers.