Good Resumes Are Getting Thrown Out by Accident

A recruiter gave me one note on my resume this week. Move the AI tooling out of the skills section and write the actual use cases into my most recent role, because it's the number one thing recruiters are reading for and because his filters are set to only surface candidates whose resumes demonstrate AI usage in their last role. If it isn't there, he never sees you.

Start from the hiring manager's seat, because that's where this actually originates.

You have four hundred applicants and you can interview maybe eight. The thing you genuinely need to know about each one is whether they've changed how they work in the last eighteen months, because your team has, and a person who hasn't will cost you six months of drag you can't afford. That is a real question with real consequences and there is no clean way to measure it at the top of a funnel.

So you reach for the nearest thing you can automate. Do the words appear in their most recent role. It's cheap, it's instant, and it correlates with the thing you care about well enough to feel defensible on a Tuesday afternoon with four hundred resumes in the queue.

I'd have done the same thing. I've built automation on exactly that logic in other parts of a business, where the honest version of the design conversation is "we can't measure the real thing, so we'll measure the thing sitting next to it and watch whether it holds."

Here's what happens next, and it's the part worth planning for.

Shortcuts like this stop working the moment enough people know about them, and this one is getting around fast. It's in recruiter posts, career coach threads, every resume service, and now it's in this newsletter. Give it a quarter, maybe two. Everybody writes the bullets. Every resume demonstrates AI usage in the most recent role. The filter passes everyone, the signal goes to zero, and you're back at four hundred applicants with one fewer tool and a quarter of hiring done on noise.

None of that is new. It's the same arc as every keyword-stuffing cycle in hiring, every certification that used to mean something, and every number that got turned into a target. The tell is always the same. The thing you're able to measure is easy to fake, and the thing you actually care about isn't.

Which leaves both sides of the desk with a more interesting question than whether the words are on the page. What actually separates someone who has genuinely changed how they work from someone who has learned to describe it.

The signal you want is not fluency with tools. It's whether the person rebuilt a process after the tools changed, and whether they can tell you what broke when they tried.

Three questions that get you there faster than any filter.

Ask what they stopped doing in the last year, and why. Anyone who has actually integrated this into their work has killed something, a report, a vendor, a step, a whole role's worth of manual effort. People who have only read about it have added things and subtracted nothing.

Ask about a time it didn't work. Real usage produces real failures, the automation that broke silently, the output nobody could trust, the thing that was faster to do by hand after all. A candidate who has never hit that has never gone deep enough to matter.

Ask what they'd do first in your environment and listen for whether they ask about your data. The people who are dangerous with this stuff know that the constraint is almost never the model, it's whether your systems can actually feed it anything true.

None of that is automatable at four hundred applicants, which is the real problem. My suggestion is to stop trying to measure the trait in the filter and move it to the first screen, where a human can hear the difference in ninety seconds. Use the filter for the things filters are good at.

The advice the recruiter gave me is correct and you should follow it this afternoon, but understand you're clearing a gate, not building an advantage. The advantage is being able to answer the three questions above.

Find three things you actually did in the last year. Not three things you could do. What used to take you a full day and now doesn't. What you stopped sending out to a vendor. What you built or tested yourself that you'd have had to ask someone else for two years ago.

Write each one as a result rather than a tool. What the task was, what you used, what changed. Time, volume, cost, error rate, headcount you didn't have to add.

Before: Responsible for monthly reporting and dashboard maintenance.
After: Rebuilt monthly reporting with AI-assisted analysis, cutting the cycle from three days to roughly four hours and moving the team to weekly reporting.

Before: Oversaw customer support operations.
After: Built an AI triage layer for inbound tickets that routed and drafted first responses, dropping average first reply from six hours to under one.

Before: Led a team of eight.
After: Trained a team of eight on AI-assisted workflows, standardized what worked into documented process, and absorbed a 30% volume increase without new hires.

Put them in the role, not in the skills row, because the skills row is where claims go to be ignored. And don't stretch any of it, because the person across the table only needs two follow-up questions to find out.

I had the diagnosis and still failed the test, and the reason is specific enough to be worth naming.

I document for a living. SOPs, process docs, enablement material, training hundreds of people on a system so it runs without me standing next to it. That part I'm good at. What I never write down is my own contribution, because once I understand something I assume it's common knowledge and that explaining it would be condescending. The system gets documented. The operator behind it doesn't.

Some of that is the sports brain, next play, next at bat, short memory on purpose. But mostly it's the assumption that if it's obvious to me it's obvious to everyone, which is wrong roughly every time.

It's a common failure in exactly the people you'd least expect it from. The better you are at making a system legible to other people, the more invisible your own work tends to be inside it, because a thing that runs cleanly doesn't look like it took anyone to build.

So if you sat down to find your three and came up empty, you probably have them and never logged them. Read your calendar and your sent folder from the last six months instead of trying to remember. That's where mine were.

Paint Protection Pros is about a month old and I assumed certified partnerships would be an easier sell than they've been. They haven't been, and the mistake was mine rather than the market's. I built well past the point where I should have been collecting feedback, on the theory that a better product shortens the sales conversation. It doesn't. Distribution is the product decision most builders make last and should make first.

That's the same error as the filter, incidentally. I optimized the thing I could control and measure instead of the thing that determines the outcome.

The rest of the build log: this newsletter is on issue two, a YouTube return is an intention rather than a plan, and a webinar is planned but not built. No Scoreboard this week. That section earns its spot when there's something real in it.

If you're hiring: the shortcut you're screening on has a shelf life, so decide now what replaces it. If you're applying: clear the gate today, then get good at the three questions.

See you next Wednesday.

Nick

If you're building a team and trying to work out what AI fluency should actually look like in your org, or you're running a business and your problem is pipeline rather than hiring, those are both conversations I'm happy to have. Book time at nicksakkis.com.