Here's a thing that happens constantly in IT hiring. A recruiter posts a network engineer role, collects 200 resumes, filters for the ones that say "Cisco," "firewall," and "CCNA," and sends the top ten to the client. The client interviews them, hires the most confident one, and three months later discovers their new network engineer can't subnet. Not "is rusty at subnetting." Cannot do it. The resume was accurate, the keywords were real, the certifications existed, and the person still can't do the job.
This isn't a story about lying candidates, mostly. It's about a screening process that never once tested whether the person can do the work.
Why keyword matching fails for technical roles
A non-technical recruiter can verify that a resume contains the word "VMware." They cannot verify that the candidate has ever built a cluster, because they don't know what a good answer sounds like. So the screen becomes: does the resume match the job post, does the candidate talk confidently, do the dates line up. Every one of those checks can be passed by someone who sat near the work instead of doing it.
IT makes this worse than most fields, for a few reasons:
- Titles mean nothing. A "network engineer" at one company designs BGP for a national footprint. At another, the same title means they plug in switches someone else configured. The resume says the same thing either way.
- Certifications certify studying. Exam dumps for most major certs are a Google search away. We regularly meet candidates holding certifications for technologies they cannot operate in front of us.
- Proximity reads as experience. "Involved in a Microsoft 365 migration" can mean they led it or that they updated the spreadsheet while a consultant did it. A keyword filter cannot tell those apart. Neither can a recruiter, because the follow-up question that separates them is technical.
- Confidence and competence are uncorrelated. The candidates who bluff best interview best, as long as nobody in the room can call the bluff.
The result is predictable. Companies pay placement fees for people who wash out in a quarter, then conclude "the market is bad." The market has plenty of good techs. The filter just can't see them, and worse, it screens some of them out: the quiet engineer with unfashionable resume keywords who could run your whole environment never makes the top ten.
What a practical screen looks like
When a working tech runs the screen, the whole dynamic changes, because bluffing stops working. You don't need trick questions. You need real ones, with follow-ups.
Scenario walkthroughs. "A branch office loses connectivity to head office. VPN tunnel is down. Walk me through it." Anyone who has done the job starts asking the right questions: is the ISP up, did anything change, what do the tunnel logs say, can each side reach the other's public IP. Someone who hasn't done the job recites definitions. The tell isn't the first answer, it's the third follow-up, and only a tech knows which follow-up to ask.
Hands-on tasks. Twenty minutes with something real. Here's a VM where DNS is broken, fix it. Here's a subnetting problem on a whiteboard: carve this /22 into networks for four offices of different sizes. Here's a switch config, tell me what's wrong with it. These take minutes to check and they're nearly impossible to fake. The candidate who "has ten years of networking" and stalls on a basic subnet question just saved you a bad hire and a placement fee.
Resume archaeology. Pick the most impressive line on the resume and dig. What was your actual role? What went wrong? What would you do differently? Real experience comes with specifics and scars. Borrowed experience comes with summaries.
None of this is hostile. Good candidates like practical screens, because it's the first interview process that actually lets them show what they can do instead of how well they interview. The people who hate hands-on screening are, reliably, the people it exists to catch.
This is how we run staffing
Every technical candidate we place gets screened by our techs, people who do this work themselves, before the client ever sees a resume. Not a personality call and a keyword match: scenarios, hands-on checks, and the follow-up questions that only working techs know to ask. It's slower per candidate and it means we send clients three names instead of ten. That's the point. Ten unscreened resumes isn't a service, it's homework being handed back to you.
How to know your screening works
Look at your last few technical hires and ask one question: at what point in the process did anyone actually watch this person do technical work? If the answer is "never, until they started," your process is keyword matching with extra steps, and your hit rate will show it. The fix is cheap. Put one competent tech in the loop with permission to ask real questions and run one hands-on task, and the can't-subnet candidates stop getting through. If you don't have that person in-house, borrow ours. Techs screening techs isn't a slogan, it's just the only version of this that works.
Stuck on this, or want it done for you? That's the job.
Email us →