How to tell if a candidate really has the skills on their CV
Most of the time, a candidate who overstates a skill isn't lying. They've touched it, so they tick the box. An engineer uses embedded software every day, so they list "embedded," not realising the role means writing the firmware that sits inside the board. A marketer who's read reports in an analytics tool lists it next to someone who actually builds the tracking. A finance hire who's edited a model claims modelling, then can't build one from scratch.
That gap between familiarity and capability is where interview time goes to die. You book an hour, spend fifteen minutes finding out the skill is thinner than the CV suggested, and you're back to square one. Do that across a shortlist and you've lost a day.
So here's how to spot it on the CV, how to test it in an interview, and how we've built Archer to catch most of it before the CV ever lands in your pile.
How can you tell if a candidate actually used a skill or just listed it?
Look at whether the skill shows up in the work history, not just the skills list. A skill that's real leaves a trail: a project, a problem, a result. A skill that's only familiar sits in a tidy list of tools at the bottom and never appears anywhere they describe what they actually did.
The verbs give it away. "Familiar with," "exposure to," "worked with," "used" are soft. "Built," "shipped," "owned," "debugged," "migrated" are people telling you they did the thing. If every skill on the CV is a soft verb, or there are no verbs at all, you're looking at a tool list, not experience.
The red flags, in order of how often they catch people out:
The skill is in the skills list but never appears in the work history.
Soft verbs everywhere, no "built" or "owned."
The skill is adjacent to what they clearly did, not central to it.
No specifics tied to it: no scale, no problem solved, no outcome.
A wall of every tool going, with no depth in any of them.
The green flags are the mirror image. The skill lives inside a specific story: what they built, the problem it solved, what happened after. There's concrete detail, the actual system, the number of users, why it mattered. And there's depth in a few areas rather than a thin layer across forty. Someone who's genuinely good at three things tells you more than someone who claims twenty.
How do you test whether a candidate really has a skill in an interview?
Don't ask "are you familiar with X." It's a yes/no question and everyone passes it. Instead, ask them to walk you through one time they used it, start to finish.
Then follow up on how and why. Why did they pick that approach? What broke? What would they do differently now? Familiarity runs out fast under follow-ups. Real experience has texture, and it comes out when you keep asking.
The fastest tell is the unglamorous stuff. Ask about debugging, edge cases, the thing that went wrong at 2am. People who've actually done the work remember those parts, because they lived them. People who've only touched the skill go vague, because there's nothing to remember.
How does Archer surface people who've actually done the work?
Everything above is detective work you're doing after the CV is already in your pile. Archer moves the check earlier. It reads the context and experience behind a skill, how and where someone actually used it, not just whether the word appears, and qualifies candidates against what you defined as good for the role.
So the engineer who uses embedded software but has never written firmware doesn't get sorted next to the one who has. Archer reads the difference between "used" and "built" the same way a good recruiter would, then puts the people who've done the work in front of you. You start with the right shortlist instead of filtering down to it.
Recruiters tell us this constantly: the hardest part isn't finding people, it's finding people who genuinely have the skills they list. After more than ten years in hiring, we know how much interview time that costs. Archer reduces it. It won't catch every overstatement, and it isn't meant to. You still decide who's good. Archer just does the first pass of the detective work so you're not spending interviews on it. Book a free demo today.
Frequently asked questions
Is a candidate lying if they overstate a skill on their CV?
Usually not. Most overstatement is innocent: someone has used the skill before, so they tick the box without clocking the gap between using something and being able to build it from scratch. It's a screening problem to solve, not a character flaw to catch.
What's the difference between being familiar with a skill and actually having it?
Familiarity means you've been around the skill: you've used a tool, read its outputs, worked next to it. Having the skill means you can do the work yourself, from scratch, including the hard parts. A CV often can't tell the two apart, which is why the same word can mean very different things on two profiles.
Why do candidates list skills they can't really do?
Because a skills list rewards breadth and the box is easy to tick. If someone uses embedded software daily, "embedded" feels true, even when the role means writing the firmware. It's rarely deception, more that adjacency reads as capability when everything sits in one list.
Should you test every skill a candidate lists?
No. Focus on the few must-haves for the role rather than the whole list. Pick the skills the job depends on and go deep on those in the interview, asking for specific, end-to-end examples instead of running down a checklist.
Can AI screening tell whether a candidate really has a skill?
It depends how the tool works. Keyword matching can't, it treats "used" and "built" as the same word. Archer reads the context and experience behind a skill, how and where someone actually used it, and qualifies candidates against what you defined as good for the role, so people who've only touched a skill are far less likely to reach your shortlist. It won't catch every overstatement, but it does the first pass so you're not spending interviews on it.