Every technical opening attracts two kinds of interviews: the kind that measures whether someone can do the job, and the kind that measures whether they can survive your anxiety as an interviewer. The second is more common. Let’s talk about how to build the first.
The interview says more about you than the candidate
A poorly designed interview doesn’t reject bad candidates; it rejects good people for the wrong reasons. If your process depends on someone remembering the complexity of an algorithm they will never reimplement, you aren’t measuring competence—you’re measuring recent memory and luck.
Before writing a single question, answer this: what exactly do I need to know about this person before betting on them? Usually, it comes down to three or four things: solving real problems, communicating their reasoning, dealing with ambiguity, and working with other people. Everything else is noise you added out of habit.
A realistic task beats a whiteboard puzzle
The best technical interview looks like a normal Monday at work. Give the candidate a real, anonymized piece of code to review. Ask them to debug a plausible problem. Let them use the documentation, their own editor, and even search the web—because that’s how they’ll work on the job.
Whiteboard puzzles test people who have already practiced whiteboard puzzles. They favor those who had free time to study LeetCode and penalize those who were, you know, working. If the role doesn’t involve inverting binary trees under pressure, don’t ask for it.
Write the rubric before the conversation
A rubric is the antidote to gut decisions. Before the interview, list the signals you want to observe and define what weak, acceptable, and strong performance look like for each one. “Communicates well” is not a rubric. “Explains the trade-off before choosing an approach” is.
With the rubric ready, you evaluate each candidate against the same standard, not against the candidate who came before. And when the team disagrees, the conversation becomes about evidence (“they didn’t consider the error case”) instead of vibes (“I don’t know, I just didn’t feel confident about them”).
Bias doesn’t disappear on its own: reduce it deliberately
Your brain makes a decision in the first few minutes and spends the rest of the interview looking for evidence that it was right. This has a name, and it has an antidote.
Ask the same core questions of everyone. Take notes while the person is speaking, not afterward—memory is a machine for confirming prejudice. If possible, evaluate candidates before reading your colleagues’ notes, so you don’t anchor on their impressions. And be especially suspicious when you like someone too quickly because they remind you of yourself: affinity is not a technical signal.
Make room for thinking (and for mistakes)
Silence is not your cue to rescue the candidate. When you finish their sentence or give them the answer at the first sign of difficulty, you destroy the very data you came to collect: how this person thinks when they don’t know.
Say at the beginning that it’s okay to think out loud, make mistakes, and change course. When someone gets stuck, offer a small hint and observe what they do with it—recovering from a mistake is one of the most useful skills an engineer can have, and you only get to see it if you allow the mistake to happen.
Respect the other person’s time
A candidate isn’t an endless sales lead. Don’t schedule five rounds for a mid-level role. Don’t assign a weekend project that you wouldn’t do for free yourself. Show up on time, read the résumé, and save the last few minutes for their questions—the way you treat people who don’t work with you yet is the most honest preview of your company.
In the end, give feedback quickly, even if the answer is “no.” It takes five minutes and is the bare minimum you owe someone who set aside an afternoon for you.
Good interviewing isn’t about finding the genius. It’s about building a process that lets capable people show they’re capable—and lets you see that without fooling yourself. If your process only approves people who are like you, the problem was never the market.
