The traditional technical interview — whiteboard coding, algorithm puzzles, trivia questions — is the default at most companies, and it's the default because it's easy to administer and feels objective. The problem is that it measures the wrong thing. Whiteboard coding measures the ability to write code without an IDE, without documentation, and without the ability to test — which is a skill nobody uses on the job. Algorithm puzzles measure the ability to solve self-contained problems with known optimal solutions, which is a skill that rarely comes up outside of specialized roles. Trivia questions measure the ability to memorize API details, which is a skill that search engines have made largely irrelevant. These interviews select for people who are good at interviews, not necessarily people who are good at the job.

The evidence for this is that interview performance correlates poorly with on-the-job performance. The strongest engineers I've worked with have ranged from "aced every interview question" to "struggled with the technical screen but was hired anyway based on other signals," and the correlation between interview scores and subsequent performance is weak. That's not because the interviews are bad at measuring what they measure — they're often quite good at measuring interview-taking skill — but because what they measure isn't what the job requires. The job requires the ability to read unfamiliar code, to communicate about technical trade-offs, to navigate ambiguity, and to learn new things quickly. None of those are measured by the traditional interview format.

The first signal I look for is the ability to explain the "why" behind technical decisions. A candidate who can describe what they built is showing me they can code. A candidate who can explain why they chose that approach over alternatives, what trade-offs they considered, and what they'd do differently in hindsight is showing me they think like an engineer. The "why" is where the engineering judgment lives, and engineering judgment is the thing that's hardest to teach and most valuable on the job. I ask candidates to walk me through a recent project and to explain the decisions they made, and the depth of the "why" is a better predictor of seniority than any coding exercise.

The second signal is the ability to work with ambiguity. Real engineering work is messy: requirements are incomplete, stakeholders disagree, the right approach isn't obvious. I present candidates with a deliberately ambiguous problem — "design a system to do X, here's what we know, here's what we don't know" — and watch how they navigate it. Do they ask clarifying questions? Do they state their assumptions explicitly? Do they consider multiple approaches? Do they identify the risks? Candidates who wait for me to remove the ambiguity before they start are showing me they need direction; candidates who navigate the ambiguity themselves are showing me they can operate autonomously. The latter is what I'm hiring for.

The third signal is intellectual honesty. I ask candidates about a time they made a mistake, and the quality of the answer is revealing. Candidates who can't think of a mistake, or who describe a "mistake" that's actually a humblebrag ("I worked too hard"), are telling me they don't reflect on their failures. Candidates who describe a real mistake, what they learned from it, and how they changed their approach afterward are telling me they have the growth mindset that's essential for long-term success. Intellectual honesty — the ability to say "I was wrong" and to mean it — is the foundation of everything else, because a person who can't acknowledge mistakes can't learn from them.

In practice, my interview process is a conversation, not an interrogation. I start by asking the candidate to walk me through a project they're proud of, and I follow up with questions that probe the "why" behind their decisions. I introduce a design problem related to our actual work and watch how they approach it. I ask about a mistake, and I listen for reflection. I leave time for their questions, because the questions a candidate asks are as revealing as the answers they give — a candidate who asks about the engineering culture, the decision-making process, and the team's biggest challenges is engaged in a way that a candidate who only asks about compensation and benefits is not.

The process isn't perfect — no process is — but it correlates better with on-the-job performance than any algorithm-focused interview I've conducted or participated in. The trade-off is that it's harder to administer: it requires the interviewer to have the technical depth to evaluate the candidate's explanations, and it produces less "objective" data than a coding test with a pass/fail score. But the false positive rate — hiring someone who passes the interview but struggles on the job — is lower, and the false negative rate — rejecting someone who would have been great — is also lower, because the process evaluates the skills that actually matter rather than the skills that are easy to test.