Watch a candidate do a small piece of the actual work before you make an offer.
Why is it harder to verify skills now than it used to be?
Because every signal a hiring manager relies on has become cheap to produce.
Candidates write resumes with AI. They generate cover letters in seconds. Application volume has climbed to the point where reading everything is impossible, so companies filter with software that candidates work around using more software. Interview answers get rehearsed against the same tools. A candidate can arrive with polished responses to every common question in a field they’ve never worked in. None of that makes candidates dishonest. Most aren’t. It means the evidence you were using to sort them no longer sorts them, and the volume makes it harder to notice. I don’t blame candidates for using the tools everyone else uses. I blame hiring processes that never changed after the tools arrived and still treat a polished resume as proof of anything.
What does a bad hire cost a small company?
Far more than the salary.
A company with forty people has no bench. The work assigned to a person who can’t do it doesn’t get redistributed smoothly. It stops, or it falls on somebody already at capacity.
The delay in finding out costs as much. Nobody discovers a bad hire in week one. They discover it in month three, after the person has produced work that other work now depends on.
Nobody budgets for a third cost. Somebody has to review what was built, decide what’s salvageable, and rebuild the rest. That’s often longer than doing it from nothing.
That’s the cost that makes me wince, because it falls on people who did nothing wrong. The coworker stuck untangling the mess didn’t make the hire. The manager did, and the manager usually isn’t the one working late to fix it.
How did an interview miss something that obvious?
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. Our bet was that rewriting it in a lower-level language would make it much faster. That bet was correct. The technical judgment was sound.
I needed somebody who knew that language. I posted the role, read the resumes, and interviewed. The person I hired said on their resume that they knew the language 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’d never thought to ask.
So I hired on a resume and a good impression. That’s exactly what I had been given to work with and exactly what I shouldn’t have relied on.
What is the first sign a hire is not working out?
In this case, the program was slower than the one we were replacing. Not slightly slower. Far slower than the version that shipped with the operating system. That was the thing we’d set out to beat.
I investigated. I read the code, and the code was awful. Not stylistically awful, structurally awful, in ways that told me the person writing it didn’t understand the language.
So I sat down with them and asked hard questions. After a while they admitted they’d never programmed in that language in their life. Never written a line of it. Their background was somewhere else entirely.
I let them go, and the project finished without them.
How do you test a candidate without wasting their time?
Keep it short, keep it real, and pay for it.
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.
The whiteboard puzzle interview is a bad test. It tests whether somebody memorized a trick, and it tells you nothing about the work they’ll be doing.
Then have them explain what they did. Ask why they chose that approach, what they’d change with another day, and where they were unsure. Someone who did the work can answer those questions for as long as you keep asking. Someone who didn’t will run out quickly, and you won’t need to be clever to notice. Pay them for the time. It costs a few hundred dollars against a mistake that costs months, and candidates who are worth hiring will decline unpaid work from strangers.
What did the interview in the apartment prove?
It stings that I already knew all of this.
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 didn’t ask what I knew. He watched me do it.
That’s 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’d experienced the right method personally, and I 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.
What happens when the project cannot be saved?
We never made that directory program fast.
The bet on the language was right. The code we had wasn’t salvageable, the schedule had already absorbed the loss, and what we ended up with was tolerable and not good. It shipped in that condition. Not every story ends with a recovery. Some of them end with a system that works well enough and a lesson that cost more than the system was worth. I’ve hired a great many people since, and I’ve never again taken somebody’s word for what they could do.
