The Hour That Tells You Who You Are Hiring: A Calmer Way to Interview Senior Developers

Note: This story was written with AI assistance and edited by me. The AI-generated content label was applied at submission. The ideas and experience behind it are mine, and the examples are hypothetical.

Imagine a candidate with twelve years of production experience who has kept a busy system alive through several migrations. She sits down for an interview and is asked to reverse a linked list on a whiteboard, a trick she has not needed in a decade. She stalls, the room cools, and the verdict forms before anyone asks about the work she is actually good at. Nothing about this scene is rare, and that is the point: puzzle interviews often feel like a test of recall, not of judgment. That feeling shaped how I think about interviews now.

Problem

Puzzle-style interviews measure recent practice. A person who spent last month grinding problem sets will beat a person who spent last month keeping a system healthy. For a junior role that trade can be reasonable, since you have little else to go on. For a senior role it is backwards. You are not hiring someone to produce clever code under a timer. You are hiring someone to make good decisions with incomplete information, explain them clearly and bring other people along.

There is also a cost on the candidate side. Experienced engineers have options, and many read a hazing-style process as a preview of the culture. Some quietly drop out. The ones who stay may be the people most willing to tolerate being tested like students, which is not always the trait you want in a leader of other engineers.

The goal, then, is simple to state and harder to run: learn how someone thinks, decides and collaborates, in about an hour, in a way you can compare across candidates.

Method

Use four blocks and keep the clock honest.

Minutes 0 to 10: Context. Describe the role and one real problem your team faces right now. Then stop talking and let the candidate ask questions. Strong seniors ask about constraints, users, failure costs and team shape. The quality of their questions is already data.

Minutes 10 to 30: A past project. Ask them to walk you through one system they built or owned. Then probe:

• What was the hardest decision, and what did you reject?

• What broke in production, and what did you do?

• What would you change today?

• Who disagreed with you, and how was it resolved?

Listen for specifics: names, numbers, dates, tradeoffs. Notice whether successes are always "we" and failures are always "they." Ownership shows up in how someone talks about mistakes.

Minutes 30 to 50: A small, real design problem. Pick a scenario from your own business, not a trick question. There is no single right answer. Watch how they scope the problem, which assumptions they state out loud, and how they talk about risk. A good answer includes a few options, a choice and a plain description of what could go wrong with it.

Minutes 50 to 60: Their turn. Let them interview you. Senior people tend to ask about how decisions get made, how incidents are handled and what happens when priorities collide. Those questions reveal what they value.

Then score right away, before talking to anyone else. Use the same four areas for every candidate: communication, technical judgment, ownership and collaboration. Rate each from 1 to 4. A 1 is a clear concern, a 2 is mixed, a 3 is solid and what you would expect from a senior, and a 4 means they taught you something. Write one sentence of evidence beside every number. Compare notes with the panel only after everyone has scored independently, so one confident voice does not decide the outcome.

Example

This example is hypothetical, built only to show how the rubric works. Suppose the scenario is: "Customers upload large files and the processing step keeps timing out. How would you approach it?"

Consider a hypothetical Candidate A, who immediately names a favorite queueing tool and starts describing its configuration. It sounds fluent, but nothing has been asked about the problem.

Now consider a hypothetical Candidate B, who asks how large the files are, how often uploads happen, what a failure costs the customer and whether results are needed instantly. Then B offers three approaches: raise timeouts, process in the background with status updates, or split the files into chunks. B picks the background option and says, "The risk is that users see a delay and think it failed, so I would show progress and send a notification." Imagine that in the earlier project walk-through, B also described a migration that went badly and what the team changed afterward.

On the rubric, A might get a 2 for judgment and a 2 for communication. B might get 3s or 4s and has written evidence to back them. If a smooth talker with no specifics ever outscores a quiet engineer with concrete answers, the notes will show it.

Limits

An hour of conversation will not prove that someone can deliver steadily for two years. It cannot reveal how they handle boredom, a bad quarter or a difficult teammate. It also favors people who explain well, which is a real skill but not the only valuable one, so be careful with candidates who are strong but reserved, or who are interviewing in a second language.

Pair the hour with something that fills the gap. A short, paid trial task of a few hours at most gives you real work to review. A reference call with someone who worked directly with the person adds a different view, especially if you ask what the person was like when a project went badly. Neither replaces the interview, and the interview does not replace them.

Tools that record or summarize interviews can help keep notes consistent, but the judgment should stay with the people in the room. I took a firm from $6M to $60M, and the lesson I took from it is that interview structure matters more than interview cleverness.

Takeaway

A structured hour built on past work, a realistic problem and a written rubric gives you more comparable evidence than a puzzle does, and it treats the candidate with more respect. Try it once with a single candidate, score it, and see whether the notes tell you something you would not have learned from a whiteboard.