The interview format is broken. I redesigned mine.

The standard technical interview measures the wrong thing. We pretend it is measuring engineering ability. It is actually measuring familiarity with a specific genre of problem, comfort with public performance under time pressure, and the candidate’s willingness to spend evenings memorizing solutions to questions they will never encounter again after the interview.

I am not the first person to make this observation. The interview format has been criticized for at least fifteen years. The criticism has changed nothing. The format persists because it is cheap to administer, easy to grade, and lets the company point at a number when a hiring decision goes wrong. None of those are reasons related to whether the format produces good engineers.

I redesigned the interview I give. I want to explain what I changed and why, in case other people are tired of the same problem.

The first thing I did was throw out the puzzle. The candidate is not asked to invert a binary tree on a whiteboard. They are not asked anything that has a known textbook solution. The reason is that I am not hiring someone who has memorized textbook solutions. I am hiring someone who can shape a problem from ambiguity and ship something that works.

What replaces the puzzle is a scenario. The candidate is given a real situation, drawn from work I have actually done. The situation has the kind of texture real work has. It is not crisp. It is not fully specified. The candidate has information they would not have in real life, and they are missing information they would have in real life. Their first job is not to solve the problem. Their first job is to ask the questions that should be asked.

The interview reveals what I actually want to know. How does the candidate frame an ambiguous problem? What do they ask first? What assumption do they catch themselves making? When do they reach for a tool, and which one? When they propose a solution, do they consider failure modes? When they explain their thinking, can I follow it?

None of that is measured by a puzzle. All of it is measured by a scenario.

The second thing I did was make the scenario interactive. I do not silently grade the candidate. I respond to their questions. I sometimes tell them facts they did not have. I sometimes change a constraint partway through. The interview is closer to a working session than to an exam. The candidate gets to demonstrate how they actually behave in a working session, which is what I am hiring them to do.

The third thing I did was structure my notes around behaviors, not artifacts. I do not write down whether they solved the problem. I write down how they handled the moment where the requirements changed. How they paused before answering a question they were not sure about. Whether they acknowledged their own uncertainty or papered over it. Whether they revised an earlier answer when new information arrived. Those are the signals I trust.

The objection I hear most often to this format is that it is harder to administer. That objection is fair. A puzzle has a known answer. A scenario does not. Grading a scenario interview requires a person who can listen carefully, hold ambiguity, and judge an engineer’s behavior under pressure. That is not a cheap skill, and it does not scale to high-volume top-of-funnel screening.

I agree. I would not run a thousand scenario interviews a week. I run scenario interviews for the candidates I am seriously considering hiring. The wider funnel filters earlier in cheaper ways. The expensive filter is reserved for the moment when the decision matters.

The second objection is that it is harder to be fair. Two candidates getting different scenarios cannot be directly compared. This is also fair, and it is also a feature. Engineering work is not a standardized test. Two engineers doing similar work are operating in different contexts and producing different outputs. The honest comparison is between the candidates and the work, not between the candidates against each other on a fixed rubric.

The format I run is not perfect. I am sure I miss good candidates. I am also sure the standard format misses good candidates, and I am sure the standard format hires bad candidates with high confidence, which is worse.

If you have hired engineers using the standard format and felt that the result was uncorrelated with the engineer’s actual ability to do the work, you are not imagining it. The format you used is not measuring what you needed to measure. There are other formats. They take more effort. The effort is worth it.