The Other Side Of Engineering Interviews

Dev Leader Weekly 109

Sep 13, 2025

TL; DR:

Does the interview represent the work?
Are you trying to support the candidate or gatekeep the role?
Join the livestream (or watch the recording) on Monday, September 15th, at 7:00 PM Pacific!

Interviewing That Actually Works

I’ve been on the interviewer side a lot lately, and it reminded me how bizarre our industry can make this process. We throw candidates into multi-round gauntlets, then judge them on puzzles they will never see again. You know, like that binary tree question you had to do or the graph theory one you were stumped on.

Meanwhile, the traits that matter at work--clarity, judgment, collaboration, and the ability to learn--get treated like extras. Some of the fundamental things that we want to see in software engineers get completely glossed over because we do this circus of ridiculous interview questions.

Here’s the approach I use now. It’s simple, human, and it maps to how we actually build software in the teams I've worked in. I was inspired to write this after interviewing candidates recently and reflecting on some of the interviews I had for my current role at Microsoft -- and you can hear more about that on Code Commute:

Start with intent and say it out loud

The first thing I tell candidates: “I’m not here to trick you. I want to understand how you think, how you work with people, and how you’d approach problems on this team. If you have a perfect example from your past, great. If you don’t, walk me through how you’d tackle it.”

That one minute of framing does two things:

Lowers fear (you get a clearer signal when people aren’t bracing for impact).
Aligns the conversation with the job’s reality: we collaborate through uncertainty, we don’t perform riddles.

I know from my own experience that I'm the kind of person who can draw a blank on exams and in interviews. It doesn't matter how much I practice or study -- if it happens, I'm spending all of my energy trying to calm my mind instead of demonstrating my skills and experience.

When I interview candidates, I want to make sure that they are comfortable. I want to make sure they have the best opportunity to demonstrate their own skills and experiences.

Use questions that look like the work

If you’re assessing coding, ask for code--but the kind you’d want to read in a code review:

A small, composable task in the candidate’s language of choice.
Space to discuss API seams, naming, and trade-offs.
Iteration under changing constraints (“What if this endpoint must stream?” “What if the data grows 100×?” -- bot not as a surprise or a trick).

This tests design sense, communication, and adaptation--far better than a gotcha where the “right” answer relies on a trick you learned once at 2 a.m when grinding LeetCode. This is especially helpful because software grows and evolves over time. We rarely write software completely from scratch -- so why do we put so much focus on hyper-specific algorithmic questions in isolation?

For architecture, let them choose a system they actually built (or a scoped hypothetical) and dig into trade-offs:

Why that boundary?
How did you evolve it as constraints changed?
When did it fail? When COULD it fail? What could you change to help with that?

If someone hasn’t done “planet-scale distributed systems,” fine--see how they reason from first principles on a system they do understand. Reasoning transfers. That's how I was treated when interviewing at Microsoft 5 years ago as a principal engineering manager and I've been able to perform well.

Replace the deception theater with real conversation

A lot of behavioral interviews are value checks in disguise. We ask, “Tell me about a time…” while silently grading whether the answer secretly maps to our values document. And I don't think there's anything wrong with "tell me about a time..." questions (I use them!), but be transparent about what you want the candidate to talk through.

Just ask what you mean:

“Tell me about a project that went sideways. Where did you personally misread the situation, and what did you change afterward? What was the lesson(s) you learned?”
“When you disagree with a tech lead, how do you make progress without stalemating?”
“Describe a moment you realized you were wrong mid-execution. How did you course-correct with stakeholders? What was the result of that and what did you learn?”

If you're trying to gauge specifically how someone handles interpersonal conflict vs technical conflict... put that detail in the question you're asking! If you want to see how someone takes bias for action... ask them about a time where they had to prioritize taking action while under pressure!

Adding layers and levels of indirection in the question makes it more confusing for candidates to answer and gives you a less clear signal -- so set them up for success!

Invite clarifying questions

Real work is full of ambiguity. Great teammates close the gap by asking sharp questions early. Bake that into the interview and let candidates know it's expected:

Leave problem statements deliberately underspecified.
Praise good clarifications (“Great callout--yes, latency is a hard constraint here.”).
Adjust scope in response to their questions, like you would in a planning meeting.

You’re testing how they collaborate into clarity, not how fast they guess what’s in your head. And things become worse if you're not clear that you expect questions and wait for them to assume that. Some people will have had experiences where they weren't allowed to ask or felt they were scored negatively for doing so.

Just be clear with your expectations. It makes everyone's lives easier.

Evaluate for learning velocity

The best hires aren’t walking encyclopedias; they’re people who diagnose gaps and move. Even very experienced engineers will find themselves in situations where they do not have experience and domain knowledge, but they are skilled at quickly learning, being curious, and making forward progress.

When a candidate hits a blank spot:

Look for how they decompose the unknown.
Listen for reasonable assumptions and explicit risks.
Ask how they’d validate or derisk the situation that's being discussed.

A gap is fine. Hand-waving isn’t. There's often more interesting information to uncover when listening to how someone works through something they don't currently know, because that's what they'll be doing a lot of in real life.

Curiosity, honesty, and a plan beat recall every time. You don't memorize software engineering.

Calibrate gaps against the actual role

Not every missing skill is equal. Some you can grow quickly; some are day-one must-haves. Be explicit:

If you’re hiring a team lead, never seeing them drive a project end-to-end might be a warning sign for you.
If they haven’t used your exact cloud queue but can articulate backpressure and idempotency, that’s coachable!
Hiring a junior and they've never written different types of coded tests before? That's easily something that could be taught to them!
A senior software engineer who can't walk through their approach to debugging their coded solution in their favorite language? That might be a red flag for you.
An engineering manager who hasn't had success coaching individuals or helping them grow in their careers, but whose code is good? Might not be the right role fit.

Decide what truly has to be present vs. what can be learned with support. This will look different for different companies too -- sometimes companies do not have the resources (time, people, etc...) to take someone from the very basics and get them skilled up. It's not ideal, but it's also reality for some companies given their current state.

Model the culture you want to live in

An interview is a candidate’s first (mini) sprint with you. Behave the way you intend to work together:

Offer context up front.
Make space for thinking.
Nudge, don’t trap.
When constraints change, explain the “why.”

If you wouldn’t treat a teammate like an adversary at 10 a.m. on a Wednesday, don’t do it to a candidate at 2 p.m. on Zoom. Some of the best interviews I have sat in as the candidate, I felt like my interviewers were friendly, welcoming, and asked questions in ways that made me feel that they wanted me to succeed.

When you feel like your interviewer is trying to trap you... what the hell are we even trying to achieve?

The payoff

When you strip out the gamified nonsense, two things happen:

Candidates show you their real operating system. You see judgment under uncertainty, not puzzle-solving and memorization stamina.
You build trust before day one. People remember how you made them feel. If the interview felt like working with a good team, they’ll want to work with your team.

You can still catch lots of warning signs when structuring interviews this way, especially because you're approaching it in a way that's much closer to how you'd work together in the role.

Interviews don’t need to be adversarial to be rigorous. Make them look like the job--and hire the people who make the work better.

Dev Leader Weekly