Field note · April 27, 2026

How to hire an engineer who actually ships

Every CTO has hired this person. Great interview — sharp answers, clean whiteboard, references that checked out. Three weeks in, they're stuck on their first PR. Six months in, they've shipped less code than the new junior. You read your interview notes again and wonder what went wrong.

Nothing went wrong. The format set them up. Most interview questions ask what someone would do, could do, might try. Future tense. Hypothetical. And humans don't want to disappoint you — especially not in a 60-minute meeting that decides their next paycheck. So they give you the answer they think you want to hear.

I learned this from Rob Fitzpatrick's The Mom Test — a book about customer interviews. The same trick works for hiring. Stop asking what people would do. Start asking what they did. The past has already happened. There's no room to make it up.

Here are the three questions I ask in every senior-engineering interview, and what each one really tells me.

Question 1: "What's the achievement you're most proud of, and what was the hardest part of getting there?"

This tells me one thing: can they actually ship under real pressure?

Listen for the stuck point. The week things were on fire. The thing they couldn't change. The thing they had to cut to hit the deadline. A strong candidate doesn't tell you what they built — they tell you what they almost didn't build. They name the trade-off. They name the moment they realised the plan was wrong, and what they did in the next two hours.

Weak answers come back clean and lifeless: "we improved checkout performance by 30%", "I led the migration to microservices", "we delivered ahead of schedule." Numbers without scars are copied from someone else's slides. If their proudest achievement has no struggle in it, they either weren't close to the work — or the work wasn't hard.

The difference shows up in two sentences side by side:

Strong: "We had a 4-second p95 on checkout, two days before Black Friday, and I cut the ORM out of the hottest path."

Weak: "I led the performance optimisation effort."

Same résumé bullet. Different relationship to the work.

You can't fake the first one. Specific stories hold up. Abstract ones fall apart. The absence of specifics is the answer.

Question 2: "What are you reading, watching, or attending in your field right now?"

This tells me one thing: does this person grow on their own, or only when a manager pushes them?

Listen for names. A book they actually finished. A conference they went to in the last six months and one thing they took away. A writer whose ideas changed something they did at work. A strong candidate doesn't list sources — they pick one and tell you how it changed a decision.

Weak answers are vague on reflex: "I read a lot of tech blogs." "I try to keep up." "I follow some Substacks." If a candidate says they're "always learning" but can't name one thing they learned this quarter, they aren't. Always and learning are easy words to say. One specific book chapter is worth more than both.

The pattern looks the same as Q1:

Strong: "I've been re-reading Will Larson's Staff Engineer; the chapter on tech-spec rituals is why I started writing RFCs at my last job."

Weak: "I follow a few tech blogs and try to keep up."

Then I ask the follow-up: "What did that change in how you work?" This is where curiosity turns into signal. A candidate who is actually growing can name the old habit, the new habit, and the moment they decided the old one was not good enough. Someone who only consumes content stays at the level of titles and recommendations.

An engineer who doesn't update their toolkit ships yesterday's solutions to today's problems. You don't need someone who reads everything. You need someone who reads one thing deeply enough that it changed how they work. Curiosity isn't a soft skill — it makes them ship faster.

Question 3: "Here's a real problem we're going to solve in the next 12 months. How would you approach it — and have you faced something like it before?"

This tells me one thing: does their past work fit the work we're about to hand them?

Listen for the moment they switch into a war story. A strong candidate hears the problem, holds it for two sentences, and then pulls themselves into the past. They tell you about the project, the limit they couldn't move, the false start, the trade-off, the outcome. You learn more about how someone works from one war story than from an hour of whiteboard diagrams.

Weak answers stay stuck in "what if". Best-practice salad — the right words in the right order, with no project behind them, no real scars, no trade-off they had to fight for at 11pm on a Tuesday. It sounds like someone who has read about the problem, not someone who has solved it.

The pattern is the same as before:

Strong: "Yeah, on the project at [X] we had exactly this. We tried Y, burned three weeks on a dead-end, and ended up shipping Z because the deadline didn't move."

Weak: "I'd start with a discovery phase to map out the dependencies."

The signal is sharp. If a candidate can't name one past project that looks like your real problem, or at least rhymes with it under similar constraints, the problem is new to them. That's not a deal-breaker — plenty of strong engineers learn fast. But it's the wrong hire if you need someone shipping next quarter.

Three questions, three angles

That's the whole framework. Pride and challenge tell you whether they ship under pressure (delivery). Reading and learning tell you whether they grow on their own (curiosity). Past projects against your real problems tell you whether their work fits yours (fit). Three different things, one trick underneath: every question pulls the candidate out of "what they would do" and into what they did. The answer is either specific or it isn't.

Use the pattern as a scorecard:

• Strong hire: they answer with concrete stories, trade-offs, constraints, and decisions they personally made.
• Risky hire: they have one strong signal, but the other answers stay abstract. They may be good, but you need more evidence before trusting them with urgent work.
• Wrong fit for urgent shipping: they stay in hypotheticals, talk in best practices, and can't connect their past work to the problem you need solved next.

The next time you sit across from a candidate, you have one move that beats every other interview trick:

Stop asking what they would do. Ask what they did.