Nobody good applies

I regularly post jobs that get thousands of applicants. One recent EE verification role got 2,700. The boolean search we built from that job's own requirements returned two people, and neither of them was the person we hired. That's the pattern I keep running into: a team spends months sourcing, and the right candidate was sitting in their applicant pool from the first week, filtered out for missing a word.

Technical recruiting has leaned on boolean search for a long time, on the assumption that the right combination of skills and keywords will separate the qualified from the rest. As any technical hiring manager will tell you, it rarely works for specialized roles. You may be looking for a wifi chip designer, and the keywords point you at a flood of hobbyists who've used wifi to connect their Arduinos. You may be looking for a strong ML architect, and find your recruiters rejecting people who specialize in TensorFlow because the JD happened to say PyTorch.

The failure that's hardest to see is what I'd call a near-miss pair: two candidate pools that share almost every keyword and have almost nothing else in common. A field-testing RF engineer and a lab-testing RF engineer. A 5G MAC RTL designer and a WiFi MAC verification engineer. If those sound like the same person to you, that's exactly the point - most non-specialists can't tell them apart, and neither can a keyword. Two genuine experts, identical on paper, and their skills don't transfer.

So a lot of teams conclude that nobody good ever applies, and that outbound is the only way to hire. Keyword search does enrich a result - the people who match are better on average than the people who don't. But for engineering roles it was always unreliable, because anybody can claim a skill and the spectrum of mastery behind that claim is enormous. Someone who watched one Python lecture on Coursera and the inventor of Python himself look about the same in a keyword search. Worse, the search actively pushes you away from the strongest candidates, who tend to be the ones most wary of claiming skills they haven't mastered. When a signal is cheap to produce, the people who invest most in producing it have the least of what it's meant to signal.

All of this is getting worse in the age of AI, now that candidates have worked out how to stuff a resume with every keyword and break most automated ATS ranking. To put it in engineering terms: your recruiting team is a receiver using a keyword filter, and the volume of inbound applications is a high power jammer drowning out your signal. Our data says those filters miss more than 60% of the strong candidates in a pool, and that nearly two-thirds of the people who reached an interview would never have been surfaced by them at all.

None of this should be news. Five years ago, Harvard Business School and Accenture surveyed^[1] employers and found 88% agreeing that qualified high-skill candidates were being vetted out of their own hiring process because they didn't match the exact criteria in the job description - and more than 90% of those employers were using automated systems to do the filtering. Everyone involved already knows the filter is cutting good people. We just haven't had a better way to find them.

There's no perfect string of booleans that fixes this. Loosen the search and you recover 98% of the strong candidates - by returning 77% of the entire pool, at which point you no longer have a filter, you have the pile you started with. Tighten it and you lose three of every five strong candidates. Like any jammed receiver, a keyword filter either rejects most of the signal or passes most of the noise. What it does reliably select for is resume length: in every single job we looked at, the resumes that matched were longer than the ones that didn't. Optimizing for a keyword filter doesn't require being a better engineer. It requires listing more.

How badly it fails depends heavily on the domain. Software recall^[2] runs around 57%. Hardware is 14%. Hardware test and validation is 7%. The explanation is that software culture emphasizes specific stacks and tools, and engineers reliably list them in a skills section - there is only one word for Python. That convention is why keyword search feels like it works to anyone who has only ever sourced software, and why the technique keeps getting exported to domains where the same job might be called characterization, bring-up, verification, DVT/PVT, or bench test depending on who wrote the resume.

The newest vocabulary performs worst of all. On AI roles - LLM stack, RAG, agents - only 3% of the people a keyword search returned were strong candidates, and half were clearly unqualified. That's roughly thirty misses for every hit, the worst ratio of any search we ran. This should be familiar to anyone hiring AI specialists right now: most applicants have AI skills on their resume, and a small fraction can explain how a transformer actually works.

Across the roles we looked at, these searches typically surfaced fewer than fifteen people out of pools of several thousand that held hundreds of genuinely strong candidates^[3]. So when a recruiter tells you there are no good applicants, what they usually mean is that the filter came back empty. Those are not the same thing.

The good news is that the durable signals are still there, and they're the ones a keyword can't fake. Skills are self-reported and free to claim. Where someone worked and what they actually built are third-party facts - and they survive the fact that two people will describe the same job in completely different words. Only a handful of companies on earth have ever built a WiFi MAC, which means the qualified population for that role is an employer list, not a keyword list.

Next week I'll get into what actually works, and how to look for it.