A resume and an interview tell you what somebody says they can do. Neither one tells you what they can do.
Every signal a hiring manager relies on has become cheap to produce. Resumes are written with AI. Cover letters are generated in seconds. Application volume has climbed past the point where reading everything is possible, so companies filter with software that candidates work around using more software. Interview answers get rehearsed against the same tools.
None of that makes candidates dishonest. Most are not. It means the evidence you were using to sort them no longer sorts them.
The hire I got wrong
Early in my time at a consulting firm we were building a set of disk utilities as a product. One piece was a directory program. The version shipping with the operating system was painfully slow, and our bet was that rewriting it in C would make it much faster. That bet was correct.
I needed somebody who knew that language. The person I hired said on their resume that they knew it inside and out. They interviewed well. Confident, articulate, easy to talk to.
I was a baby manager at the time. I had the title of vice president of consulting and no training in interviewing whatsoever. Nobody had ever taught me how to run one and I had never thought to ask.
So I hired on a resume and a good impression.
The tell was in the output
The program ran slower than the one we were replacing. Not slightly. Far slower than the version shipping with the operating system, which was the thing we had set out to beat.
I read the code and it was awful. Not stylistically awful, structurally awful, in ways that told me the person writing it did not understand the language.
I sat down with them and asked hard questions. After a while they admitted they had never programmed in that language in their life. Their background was somewhere else entirely.
I let them go and the project finished without them.
I already knew better
My own first real job came from an interview in Rick Shirley’s apartment, where he sat me down and had me write programs on the spot. He did not ask what I knew. He watched me do it.
That is how I got hired with almost no experience and a background nobody would have shortlisted. The demonstration was the whole application.
Then I became a manager and hired somebody off a resume and a good conversation. I had experienced the right method personally and still defaulted to the easy one, because the easy one is what everybody does and nobody had told me otherwise.
Trust but verify. I learned that phrase the expensive way.
A short paid work sample, then an explanation
A small piece of actual work, an hour or two, from your real problem domain. Not a puzzle, not a whiteboard exercise, not an algorithm nobody uses. Something resembling what the job involves on a normal Tuesday.
Then have them explain what they did. Why this approach, what they would change with another day, where they were unsure. Somebody who did the work can answer those questions for as long as you keep asking. Somebody who did not will run out quickly.
Pay them for the time. A few hundred dollars against a mistake that costs months, and candidates worth hiring will decline unpaid work from strangers.
The honest ending
We never made that directory program fast. The bet on the language was right, the code was not salvageable, and what we shipped was tolerable rather than good.
Not every story ends with a recovery. Some end with a system that works well enough and a lesson that cost more than the system was worth.
I have hired a great many people since, and I have never again taken somebody’s word for what they could do.
The full article is on my site: https://thewritingking.com/trust-but-verify-hiring/. It runs longer, carries the diagrams, and answers the questions readers ask most.
These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.