Technical Interview

An application tells you what someone says they did. A line reading "built the payments system" doesn't say whether they designed it, added features on top of a structure someone else built, or were one of five people on it.

So for a long time interviews were places where people described their experience. You asked what they had done and listened to the answer. The problem is that this tilts toward measuring the ability to describe. Pagedeck hired that way once. Someone who talked about architecture fluently for an hour couldn't get a single assigned feature to release two months after joining. Meanwhile someone who had been slow to answer in their interview shipped three things in their first month.

There was also a period of tilting the other way — proving rigor by having candidates solve an algorithm problem inside an hour. That does measure something, but often something with no overlap with the job. Hand a shortest-path problem to a candidate for a role building product screens and what you have separated is people who practiced that problem type recently from people who didn't.

That is why the technical interview settled into its current shape: watch the work happen instead of listening to a description of it, and choose what you watch so it overlaps with the actual job. Both halves of that matter — watching the wrong thing closely is no better than listening to the right thing vaguely.

Divide an hour into four stretches.

1. The first five minutes explain the format. What will be looked at, whether searching is allowed, whether asking for help when stuck is fine. Without that framing, candidates spend the next fifteen minutes guessing at the rules.
2. The next fifteen go deep on one past piece of work. Not a tour of the list — one item, ideally one the candidate picked. An engineer sketches the structure of that feature; a designer explains which alternatives they discarded on that screen. What's being examined is the choices made and the things given up, not what got built.
3. The next thirty solve something together, on the spot. Give one problem close to the real work. For an engineering role at Pagedeck that might be how to handle conflicts in simultaneous document editing. What's being read isn't the answer but the order of approach: whether they ask back about the requirements, whether assumptions get said out loud, whether a blocked path leads them to look for another.
4. The last ten minutes are the candidate's questions. That stretch isn't assessment; it's information. Even so, what someone chooses to ask often reveals what they consider important about the work.

Fix the problem used in the thirty-minute stretch in advance. Interviewers improvising a question that day hand each candidate a different problem, which makes results impossible to place side by side. Give the same problem to ten people and by the tenth you know the range of possible answers, which makes judgment faster and makes a strong answer recognizable as strong.

Two interviewers is the right number: one colleague who actually does the job, and the manager who needs the role filled. With one, the judgment hardens into that person's taste. With three or more, the candidate spends more time being asked than answering, and the panel starts performing for each other.

One person leads the questions and the other takes notes. Notes record scenes, not verdicts. Instead of "weak on structural design," write "reached for a locking approach on edit conflicts first, then moved to a different one when asked about the cost." Notes containing only conclusions can't have their reasoning reconstructed three days later.

The timing is after screening, the step where applications alone decide who moves forward. Only people who weren't filtered there arrive here, and whatever screening deliberately deferred as unverifiable from a document becomes what this interview verifies.

When it runs alongside a take-home assignment — practical work completed at home — one of the two shrinks. With an assignment submitted, the thirty-minute stretch becomes a session reading through it together. Examining the same thing twice only consumes more of the candidate's time. After this come the culture interview, which looks at whether working style and judgment match, and the reference check, where former colleagues are asked directly.

"This round goes deep on one past project only. We covered the list in the application."

A commitment not to verify the same information twice, and a signal that breadth was already covered.

"I'm reading the approach rather than the answer. Say so if you get stuck."

Telling the candidate in advance what is being assessed, which removes a whole category of wasted guessing.

"The notes only have conclusions, so I can't tell why they scored it that way."

The problem with a record that kept the verdict and dropped the scene it came from.

Pagedeck changed its format after hiring the fluent talker and living with it for two months. One problem for the thirty-minute stretch got fixed, and the note template gained a separate field for scenes.

Twelve candidates then went through the same problem. Once the range of twelve answers was visible, judgment got faster. Theo took the notes, and from the third interview onward he could write while comparing against how earlier candidates had approached it. Two of the twelve joined, and both shipped an assigned feature to release in their first month — the outcome the old format had failed to predict.

The most common reading is that a technical interview is where you set a hard problem. It examines technical ability, so difficulty seems like the point. But what a hard problem separates is people who practiced that type recently from people who didn't. The thing to aim for isn't difficulty; it's overlap. A problem that overlaps with what the role does every week is what makes the result connect to performance after joining. In organizations that insist on hard problems, the list of people who pass interviews and the list of people who do the job well are two different lists, and nobody notices because the second list is never written down.

The other misreading, common on both sides of the table, is that the interview checks whether the answer is right. Problems that resolve completely inside an hour barely exist in real work. What gets read here is whether they ask back when the requirements are thin, whether assumptions get spoken, whether they name the weakness in their own answer. Passing people purely on correct answers selects for solving accurately alone and filters out people who solve by working things through with whoever is next to them.