• evidence-led hiring
• hiring engineers
• cvs

what is evidence-led hiring?

by Dev Ashish · 7 october 2026 · 4 min read

evidence-led hiring is a way of hiring engineers where every claim about a candidate is backed by something you can check, a quote from a conversation, a stage of a problem they worked through, or a line of code they wrote, and each requirement of the role is judged on two questions, does this person understand it, and have they done it.

a cv is a claim. it is written by the person it describes, about themselves, to get a job. that was always true, but it used to cost effort to write a good one, and the effort itself said something. it doesn’t anymore. any engineer can now produce a cv that matches your job post line by line in under a minute.

the result is the situation most founders hiring engineers will recognise: two hundred applications, and every one of them says it’s a fit.

evidence-led hiring is the response to that. it stops treating the cv as evidence, and asks a different question about each candidate: what can this person show?

the two questions behind every requirement

every requirement of a role gets judged on two separate questions:

1. do they understand it? can they reason about it when the situation changes, not just define it.
2. have they done it? in real work, with real consequences, not in a tutorial or a hypothetical.

these get confused all the time, and the confusion is expensive. someone who has read everything about distributed locks can explain them beautifully and still never have debugged one at three in the morning. someone else has shipped the fix and can’t name the pattern. a single score blends the two and hides exactly what you needed to know.

so evidence-led hiring keeps them apart, per requirement. a candidate might understand tail latency well, have done real-time streaming in production, and have only read about tenant isolation. that is a far more useful picture than “8 out of 10”.

every mark has a source

the second rule is that no judgement stands without its source. if a candidate is marked as having done something, you can see why:

• a quote from a conversation about their own work
• the stage of a problem they reached, when the problem unfolded one step at a time
• a line of code they wrote, if they chose to share it

this matters for two reasons. it lets you check the judgement instead of trusting it. and it makes the gaps honest: “not assessed” (we never got to it) is a different result from “not there” (we asked, and it wasn’t), and both are different from “thin”.

how the evidence is gathered

there are three sources, and none of them is the cv.

a conversation about real work

the strongest evidence comes from asking engineers about things they have actually built, through situations that unfold as they answer. a situation reveals one stage at a time, and each stage depends on the previous answer, so there is no single question to look up.

a merchant was paid twice. the webhook arrived twice. make the second one harmless.

someone who has handled this in production answers differently from someone who has read about it. they ask where the duplicate came from before they reach for a fix. they mention the case nobody warned them about.

code they actually wrote

when an engineer chooses to share a repository, the code they authored is the best guide to what to ask. not to grade them, but to ask about the decision behind a function, or the bug a commit fixed. the absence of public code is never held against anyone: most engineers’ best work sits in their employer’s private repositories.

what they do with an ai agent

engineers now work alongside ai agents, so it is fair to look at how they direct one: whether they check its work, and whether they catch it when it is wrong. this is optional and separate from the conversation about their own work.

what a founder receives

for each candidate, an evidence card: every requirement of the role, marked on both questions, with the source behind every mark. it comes with an interview guide built from the gaps, so your interview time goes to what the evidence didn’t settle, and with the cv exactly as the candidate wrote it, untouched.

you still decide. evidence-led hiring brings evidence and questions, never a verdict: the hiring decision stays with you.

what it asks of engineers

it asks for twenty to thirty minutes, once, talking about work they have actually done. in return they are judged on what they understand and have done, not on how well their cv was written or where they went to college. they see their own skill map before any company does, and they are told before their profile goes anywhere.

when evidence-led hiring is worth it

it is most useful when the cost of a wrong hire is high and the cv signal is weakest: early engineering hires at startups, roles where one person owns a system alone, and hiring from outside the usual college and company names, where good engineers are most often overlooked.

it is less useful for roles where a short work sample already tells you everything, or where volume matters more than depth.

for the full mechanics, how a role is read, how answers are marked and how cheating is handled, see the method. for a worked example of one concept, read how to tell if an engineer really understands idempotency. the terms used here are defined in the glossary.