Technical Interviews: A Hiring Manager's Guide

Most technical interviews are broken. Here's how to design interviews that actually predict job performance while respecting candidates' time.

Most technical interviews are broken

I have sat on both sides of hundreds of technical interviews. Most are not good. They are stressful, generic, and weakly correlated with how people actually do the job. Candidates leave annoyed, hiring managers leave unsure, and the offers that come out of the process succeed or fail at a rate I would generously call "coin flip."

The good news is that this is fixable, and the fixes are not expensive. This piece is the playbook I use when I help teams design a hiring loop, often as a start project engagement.

What a technical interview is actually for

The job of a technical interview is to predict job performance. Not to filter for cleverness. Not to weed out impostors. Not to make the company feel rigorous. Just to predict, with as little noise as possible, whether this person will do the work well.

Once you anchor on that, a lot of common practices fall away. Whiteboard algorithms predict whiteboard algorithms. Domain trivia predicts domain trivia. The thing that predicts work is work-shaped.

Define the bar before you write any questions

Before I design a single interview round, I write down what "good at this job" looks like. Not generic adjectives. Specific behaviours.

For a senior engineering hire that might be:

• Can pick a sensible architecture for a new service in under a day
• Can read unfamiliar code and find the bug
• Can disagree with a teammate respectfully and change their mind when wrong
• Can communicate a tradeoff to a non-technical stakeholder

Now I have something to interview for. Each round in the loop should map to at least one of these behaviours, and I should be able to tell you which one before I start.

Make the interview look like the job

The strongest predictor I have used is a scoped, paid, work-shaped exercise. A small piece of real work, done the way real work is done, with the candidate's choice of tools and a reasonable time box.

I prefer paid take-homes, capped at a few hours, with a debrief afterwards where the candidate walks me through their decisions. This format lets the candidate work in their natural environment, lets me see code that resembles what they would actually write, and gives both sides a real conversation to have.

Live coding is not pointless, but I use it sparingly and I never use it as the sole technical signal. It selects for people who can think under artificial pressure, which is not the same as people who can think.

A loop I keep coming back to

For most engineering roles I run a four-step loop:

1. A 30-minute conversation. Mutual fit, the work, the company. No technical screening
2. A scoped technical exercise. Take-home or paired session, sized to a few hours
3. A debrief and design discussion. We walk through their submission and then explore an adjacent problem out loud
4. A team conversation. Two future peers, no founders or hiring managers, candid both ways

The whole thing fits in two weeks of calendar time and roughly four hours of candidate effort. That is the minimum I can run while still gathering enough signal to be confident.

What to actually look for

In the design discussion I am watching for a small set of behaviours:

• Do they ask clarifying questions before diving in?
• Do they articulate tradeoffs, or do they pretend there is one right answer?
• Do they recover gracefully when I push back?
• Can they hold the problem in their head while exploring a side path?
• Do they acknowledge what they do not know?

I am not watching for them to nail every detail of the textbook answer. The best engineers I have hired routinely got pieces of the design wrong on the spot, then revised them when given new information. That is how the job works.

The biases hiding in plain sight

A few habits I keep enforcing on myself.

• Calibrate before you decide. Run the same problem with at least three other interviewers before you trust your own bar
• Score against the rubric, not the gut. Write down what good would have looked like before the interview, not after
• Treat similarity bias as the default. "Reminds me of myself" is not a hiring signal
• Hold the line on lying-by-omission. A candidate who hides what they do not know is a worse hire than one who tells you up front

The reason most interviews are noisy is that we let the gut do the work the rubric was supposed to do.

Respect the candidate's time

The candidate is also evaluating you. Every part of the process should be considerate.

What I always do:

• Tell them the full loop up front
• Pay for any exercise that takes more than two hours
• Give meaningful feedback within a week
• Honour their time when you cancel: reschedule fast and apologise

I have lost candidates I wanted to teams that ran a worse process but treated them better. The ones I kept remembered the details years later.

What to do with the signal

After the loop I write a short hiring memo: the bar, what we saw, what we did not see, the open questions, the recommendation. I share it with the team and we decide together.

If there is genuine disagreement, "no" usually wins. The cost of a bad hire on a small team is huge. The cost of missing a marginal one is usually smaller than founders fear, because most candidates eventually come around or are replaced by someone equivalent.

The takeaway

A good technical interview is not a gauntlet. It is a structured way of finding out whether someone will be good at the job, designed with respect for everyone's time. Define the bar, make the rounds work-shaped, calibrate the team, and be honest about what you saw. Done well, you hire better and get fewer cultural surprises a year in. Done poorly, you keep coin-flipping and blaming the candidates.

This is also the lens I bring to my first engineering hire writeup, where the same principles apply with extra weight.

References

• Aline Lerner on interviewing
• Google's structured interviewing research
• First Round Review on hiring