The best hires don't always match the job description

You post a role. You find someone who fits the req. You send them over, and the manager denies them. Then, only then, do you get all the little nuances they never wrote down.

One sourcing operations leader at a defence contractor put it plainly: "A lot of times we'll post a position, find somebody, and then they'll deny them... they need this. And then they'll give us all these little nuances." We hear this constantly from sourcing teams. The rejection isn't a dead end. It's a signal that the calibration was never finished.

And it exposes something bigger. Matching on paper and being the right hire are two different things, and the gap cuts both ways.

Why do hiring managers reject candidates who look perfect on paper?

Because the job description only captures a fraction of what "good" means for the role. The rest lives in the manager's head, and it usually stays there until someone gets rejected.

A candidate can tick every keyword in the JD and still be wrong. Wrong for how they work. Wrong for the team. Wrong against an unwritten standard the manager assumed was obvious. None of that is on the req, so you had no way of screening for it.

Another sourcing leader at a large defence contractor framed the rejection as a check on the req itself: "It almost forces recruiters to make sure that the reqs are written correctly... if they're a match and you're like 'oh they don't fit,' then what are you missing in your req?" That's the right instinct. A denial after a clean keyword match tells you the definition of good was incomplete before you started.

Can a great hire not match the job description at all?

Yes, and it happens more than most reqs allow for. The best hires often don't match the JD on paper. What matters is the capability underneath, built in an adjacent or even a different role.

A developer who spent three years in React can pick up Vue quickly because the underlying skills carry across. A literal filter searching for "Vue" throws them out. Someone from a different industry whose real strength is ownership and problem-solving can map directly onto a role, even though their CV doesn't share the sector keywords. A support rep who's spent two years defusing angry customers and learning the product has most of what a customer success role needs, just under a different job title.

Related skills, transferable skills, experience that built the capability the role actually requires: a keyword filter can't see any of it. So the tool designed to save you time quietly bins your strongest candidates.

What is transferable skill matching?

Transferable skill matching is evaluating a candidate on the capability behind their experience, not on whether the exact words from the job description appear on their CV. It looks at what someone can actually do, where they built it, and how close that is to what the role needs.

Rigid JD-reading and keyword-matching tools both miss, in opposite directions. Keyword matching surfaces people who read as perfect and get rejected for reasons no filter could catch. And it discards people who'd be excellent because their skills sit under a different label. One over-trusts the words. The other never questions them.

How do you fix the gap between paper and reality?

Two things, done early.

First, get the manager's real criteria out before you source, not after the first rejection. Live calibration, an actual conversation about what "good" looks like, is where the little nuances come out while they're still useful. If a clean match gets denied, treat it as feedback on the req and rewrite it.

Second, evaluate on genuine capability rather than literal word overlap. That means being willing to consider someone whose title, stack or industry doesn't match, but whose skills do.

Both of these are hard to do by hand across a large pipeline. That's the practical problem, and it's where the tooling matters.

Where does Archer fit in?

Archer is hackajob's AI sourcing agent for passive, in-demand talent. It reads beyond the CV and beyond keywords.

Archer understands related and transferable skills and the experience behind them, so it doesn't just check whether the exact words from the JD appear. It surfaces qualified candidates a keyword match would miss, the developer whose stack shifted, the person from an adjacent role, and it qualifies them against what the recruiter actually said "good" looks like. If your calibration says ownership matters more than a specific tool, Archer sources against that.

The division of labour stays honest. Recruiters own the definition of quality. Archer does the reach and the qualification against it. Interviews and hiring decisions stay with your team.

Get the real definition of good out early, then judge candidates on what they can do. The rejections that used to arrive with a list of nuances start arriving less often.