How to Interview Engineers Without Wasting Everyone's Time

I've sat in on hundreds of engineering interviews across client engagements, and the pattern is always the same: the company asks algorithm puzzles, the candidate performs or doesn't, and six months later nobody can explain why the "great hire" is struggling or the "borderline" candidate is thriving.

The interview didn't test anything that matters on the job.

What Actually Predicts Performance

The engineers who succeed in scaling companies aren't the ones who can reverse a linked list on a whiteboard. They're the ones who can take a fuzzy requirement, ask the right clarifying questions, make reasonable tradeoffs, and ship something that doesn't fall over at 10x load.

So that's what I interview for.

Senior Engineer Screens (30 Minutes)

For senior candidates, I run a collaborative design conversation, not a test. The structure:

"Tell me about the last system you were responsible for end-to-end." This immediately reveals scope, ownership mentality, and communication ability. Weak candidates describe features they built. Strong candidates describe systems they owned — including the parts that sucked.

"Where did that system hurt the most in production?" This is the real question. Anyone can describe what they built when things went well. The engineers you want are the ones who can articulate production pain honestly, explain the tradeoffs that led there, and describe what they'd do differently. If a candidate can't name a single production problem, they either weren't paying attention or they're not being honest.

"Here's a fuzzy requirement. Walk me through how you'd approach it." I give them something intentionally ambiguous — not to trick them, but to see how they handle uncertainty. Do they ask clarifying questions? Do they identify the biggest risks first? Do they propose a simple starting point, or do they immediately jump to a complex architecture?

Junior Engineer Screens (30 Minutes)

Junior interviews are completely different. You're not hiring for experience — you're hiring for learning velocity and reliability.

I use simple feature design and bug troubleshooting scenarios. Can they reason through a problem they haven't seen before? Do they ask questions when stuck, or silently spin? Do they communicate their thinking as they work?

The single best signal for junior engineers: give them a bug report and watch how they approach diagnosis. Engineers who will grow quickly start by understanding the expected behavior, then work backward from symptoms. Engineers who struggle jump straight to code without understanding the problem.

AI Tool Fluency Is Now Table Stakes

In 2026, I assess every candidate's relationship with AI coding tools. Not "do you use Copilot" — but do they understand when AI suggestions are wrong? Can they articulate the limitations? Have they developed a workflow that amplifies their judgment rather than replacing it?

A senior engineer who can't effectively use AI tools in 2026 is like a developer who refused to use an IDE in 2015. They'll be slower than they need to be, and they'll slow down the team by not participating in the tooling culture.

What I've Stopped Asking

Take-home projects that take more than 2 hours. You're selecting for candidates with free time, not candidates with talent. If you need to see code, do a live pairing session where you work through a real problem together.

Language-specific trivia. "What's the difference between == and === in JavaScript?" tells you nothing about engineering ability. Test judgment, not memorization.

"Where do you see yourself in 5 years?" Nobody knows, and the answers are always performative.

The Cathedral vs. Brick-Laying Test

One thing I always probe: does this person understand how their work fits into the bigger picture? I call it the cathedral vs. brick-laying distinction. Some engineers see themselves as laying bricks — they complete tickets. The ones you want see themselves as building a cathedral — they understand the business context, they think about how their component connects to the whole, and they push back when a ticket doesn't make sense.

You can test this directly: "Why did the system you built matter to the business?" If they can't answer that, they were laying bricks.

Structuring the Full Loop

For a typical engineering hire at a scaling company, I recommend four touchpoints: a recruiter screen (culture fit, logistics, salary expectations), a technical screen (the collaborative design conversation), a pairing session (live coding on a realistic problem), and a team fit conversation (with the actual team they'd join, not random senior engineers).

Four touchpoints, each under an hour. Candidates who are actively interviewing won't wait for your six-round process. You're competing for talent against companies that move faster.

The Hiring Mistakes I See Most

Hiring for the resume instead of the work. A Google engineer who spent five years on internal tooling may not be the right person to build your scrappy product from zero. Match the experience to the actual job.

Not testing for communication. In a remote-first world, an engineer who can't write clearly or explain their decisions in a Slack thread is a net negative, regardless of their coding ability.

Skipping the reference check. I know it feels old-fashioned. Do it anyway. One conversation with a former manager reveals more than three hours of interviews.