The Engineering Interview Question Most CTOs Get Wrong

Most engineering interviews are designed to test what a candidate knows. Algorithms, system design, technical trivia. The interview identifies someone who can answer the questions the interviewer thought to ask.

The problem: the best engineers I have worked with — at the BBC, at Booking.com — were not the ones who knew the most. They were the ones who made the best decisions under uncertainty. When requirements were unclear. When the codebase was unfamiliar. When the right answer was not obvious.

That quality does not show up in a standard technical interview.

Why the Common Approach Fails

Technical interviews optimise for retrievable knowledge — things a candidate can recall and demonstrate on demand. LeetCode problems. System design patterns. Architecture diagrams drawn on a whiteboard.

But engineering in production is not a recall exercise. It is a judgement exercise. The problems that matter are not the ones with known solutions — they are the ones with incomplete information, real constraints, and no clean answer.

An engineer who aces every technical question but defaults to the most sophisticated solution rather than the simplest effective one is a liability in a growing startup.

TechTek's Position

The question that reveals engineering judgement is not "how would you design this system?" It is "what would you not build?"

Ask a candidate to describe a situation where they pushed back on a technical decision. Where they argued for doing less, not more. For choosing a simpler approach over a more sophisticated one. For deferring a technical investment because the business did not need it yet.

The best engineers have strong opinions about what not to build. They have seen over-engineering cause more damage than under-engineering. They understand that the most expensive line of code is the one you write for a problem you do not yet have.

The Nuance

This is not an argument for always doing the minimum. Senior engineers know when to invest in infrastructure early — when a shortcut now will cost significantly more at scale. The skill is knowing the difference between the two situations.

The question that surfaces it: "Tell me about a time you argued for a simpler solution. And tell me about a time you argued for the harder investment. What was different about those two situations?"

What This Looks Like in Practice

The candidate who tells you about pushing to replace a working system with microservices because "it did not scale" — when the system was handling 1,000 users — is showing you something important about their judgement.

The candidate who tells you about arguing to keep a monolith for 18 more months while everyone else wanted to decompose it, shipping 3× faster as a result, and being proven right — that is a different kind of engineer.

Build a team of the second type. They are harder to find and significantly more expensive to miss.