How to Verify a Candidate Actually Did the Work They Claim

Every line on a resume is a claim. "Led the migration." "Owned the redesign." "Drove 40% growth." Read in isolation, each one sounds like proof. It isn't. It's an assertion, written by the person who benefits from you believing it — and in an era where anyone can generate a flawless, confident resume in under a minute, the gap between what a candidate claims and what they actually did has never been wider or harder to see.

This guide is about closing that gap: how to move from trusting what's written to confirming what's true, without turning your hiring process into an interrogation that scares off good people.

Why traditional verification doesn't verify much

Most teams already have "verification" steps. The problem is that the common ones mostly check the wrong thing.

Reference checks are gamed by design. The candidate hands you a list of people who like them, pre-warmed and ready to say nice things. You're not getting an independent assessment; you're getting a curated one. And references confirm that someone worked somewhere far more reliably than what they were actually capable of.

Background and employment checks verify that a title and a date range are real. Genuinely useful — but a confirmed job title tells you nothing about whether the person did the work well, owned what they claim to have owned, or could do it again for you. "Was employed as a Senior Engineer at X" and "is a senior engineer" are different facts.

The resume itself is unverifiable by construction. It's a one-way document. There's no mechanism inside it to distinguish the person who led the migration from the person who watched it happen from a nearby desk. Both write the same bullet.

So the standard stack confirms identity and employment, and then quietly assumes ability. Assumption is exactly the thing AI-generated applications exploit. (If you haven't, it's worth reading why detecting AI resumes is a losing game — verification is the move that makes detection unnecessary.)

Verify projects, not job titles

The reason job titles resist verification is that they hide signal instead of revealing it. Consider two product managers, both with "5 years of experience" and nearly identical resumes. One spent those years making small reporting tweaks. The other launched a personalization engine that drove eight figures of revenue. On paper they're interchangeable. The thing that separates them — the actual work — is invisible at the title level and only becomes visible at the project level.

That's the shift worth internalizing: treat a career as a portfolio of projects, not a sequence of titles. A title is a claim about a role. A project is a unit of work you can actually examine — with a problem, a contribution, an outcome, and evidence attached. Verification gets dramatically easier once you're checking projects rather than trying to confirm something as fuzzy as "was a senior engineer." You're no longer asking "is this title real?" — you're asking "did this specific thing happen, and did this person do the part they say they did?"

Verification is a layer, not a gate

Here's the mistake that makes verification painful: teams try to apply it at the front door, to everyone. Require proof up front and you crush your application rate — the good candidates with options simply don't bother. So most teams give up and verify almost nothing.

The fix is to stop thinking of verification as a wall and start thinking of it as a layer you apply where it matters. Candidates don't need to be fully verified to apply. They need to be verifiable when you decide to look closely — which is only ever for the handful who reach your shortlist.

This changes the economics completely. You're not verifying four hundred applicants. You ranked the pile on signal, surfaced the few who stand out (see finding the real candidates in a high-volume pile), and now you apply real scrutiny to maybe eight people. At that scale, deep verification is not only affordable — it's the highest-leverage hour in your whole process.

What proof actually looks like

When you do look closely, "verify" doesn't mean "ask for another reference." It means asking the candidate to make the work concrete. For a given claim, you can request:

Artifacts — the actual thing they made or contributed to, or a representation of it.
Screenshots and outcomes — evidence of the result, not just a description of it.
Project context — what the problem was, what constraints they worked under, what their specific role was versus the team's.
Coworker validation — confirmation from people who actually worked alongside them, not a hand-picked reference.

The power here isn't any single item. It's that a real contributor can produce this texture easily and a fabricated claim falls apart the moment you ask. Someone who genuinely led the migration can tell you what nearly broke, what they'd do differently, and who else was in the room. Someone who didn't, can't — no matter how clean the resume reads. You're not detecting a lie; you're creating a situation where only the truth has substance behind it.

A useful way to structure this for any project that matters is to walk it through six questions: What was the problem? What was the solution? What was this candidate's specific contribution versus the team's? What was the outcome? What metrics back that up? And what proof exists — artifacts, context, validation? A genuine contributor moves through all six naturally. A thin claim stalls somewhere around contribution or proof, and that stall is your answer. The framework also keeps you honest: it forces you to separate "the project was impressive" from "this person did the impressive part," which is exactly the distinction the resume blurs.

The interview is your best verification tool

You already have a verification instrument and you're probably underusing it: the interview. The trouble is that most interviews try to discover a person from scratch in 45 minutes — generic questions, generic answers, exactly the format an AI-coached candidate is most prepared to game.

Flip it. Walk in already knowing what the candidate claims to have worked on, which of it aligns with your role, and what specifically needs validating. Then spend the time pressure-testing that. Instead of "tell me about a challenge you faced," you ask them to walk you through the actual project on their resume — the decisions, the trade-offs, the parts that went wrong. Real work survives that scrutiny and gets richer under it. Fabricated work gets thinner with every follow-up. The interview stops being a performance and becomes a verification.

A practical verification workflow

For your next shortlist:

Rank first, verify second. Don't verify the pile. Use signal to get to a short list, then concentrate verification there.
Verify the specific claims that matter for the role. You don't need to confirm everything — confirm the two or three claims your hiring decision actually hinges on.
Request texture, not just references. Ask for artifacts, outcomes, and context. Let the candidate show the work, not just name people who'll vouch for them.
Interview from evidence. Go in knowing what to pressure-test, and test the real work rather than running generic questions.
Weigh validation by role. What counts as convincing proof differs across jobs — demonstrated output for an execution role, network and reputation signals for a relationship-driven one. Decide what real evidence looks like before you ask for it.

The bottom line

A resume tells you what someone says they did. Verification — done as a focused layer on the people who matter, not a gate on everyone — tells you what they actually did, what holds up, and what doesn't. In a world where anyone can claim anything convincingly, that shift is the whole advantage.

The companies that win hiring from here won't be the ones who trust the best-written resumes. They'll be the ones who can tell, quickly and consistently, which claims have real work behind them — and which are just well-phrased noise.

MSTS (Multi-Signal Talent Stack) treats verification as a dynamic layer, not a barrier: candidates apply freely, and when a claim matters you can request artifacts, context, outcomes, and coworker validation — so your decisions rest on proven work instead of assumed ability. See how it works.