👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.
Your senior engineer interviews are probably testing the wrong things.
Think about the last senior hire who didn’t work out. I’d bet it wasn’t because they couldn’t implement a binary search tree. It was something harder to pin down - they couldn’t navigate the existing codebase, struggled to explain technical tradeoffs to stakeholders, or made decisions in isolation that created problems downstream.
And yet, when you designed your interview loop, you probably spent 80% of the time on algorithmic problems and coding exercises. You’re hoping to catch the skills that actually determine success in the role in a 45-minute “behavioural” round.
The job description nobody writes
Here’s what senior engineers actually do, day to day:
They inherit systems with years of accumulated decisions - some brilliant, some baffling, most undocumented. They figure out which constraints are load-bearing and which are historical accidents. They translate between engineering reality and business needs. They make judgment calls with incomplete information. They explain why the “obvious” solution will create problems six months from now.
None of this shows up in a LeetCode problem.
The irony is that we all know this. Ask any experienced engineering leader what makes a senior engineer valuable, and they’ll talk about judgment, communication, systems thinking, navigating ambiguity. Ask them what their interview process tests for, and you’ll get algorithms, data structures, and maybe a system design whiteboard.
We’re testing for the interview, not the job.
This matters more than you think
When your interview process optimises for the wrong signals, three things happen:
You hire people who interview well but underperform. They can solve puzzles under pressure, but they struggle when the problem isn’t clearly defined. They write elegant solutions to the wrong problems. They make technically correct decisions that ignore organisational context.
You reject people who’d be excellent. That staff engineer who’s spent the last five years making a legacy system maintainable might be rusty on dynamic programming. But she has exactly the judgment you need. Your process filtered her out though.
Your existing team gets the message. They see what you reward in interviews, and they optimise accordingly. Why develop the messy, relationship-dependent skill of stakeholder communication when the path to the next level is clearly “get better at coding puzzles”?
If you’re enjoying this article, consider subscribing to get:
✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide
Rethinking what you’re actually hiring for
Before you can fix your interview process, you need to get clear on what senior engineers actually need to do in your organisation. Not what sounds impressive - what actually creates value.
For most teams, it’s something like:
Navigate existing systems. Understand code they didn’t write, identify where changes are risky, work within constraints they didn’t choose.
Make decisions under uncertainty. Choose approaches when requirements are fuzzy, timelines are aggressive, and there’s no obviously correct answer.
Influence without authority. Convince other engineers, stakeholders, and leadership to support their technical direction.
Explain tradeoffs clearly. Help non-technical people understand why something is hard, why it costs what it costs, and what the alternatives look like.
If that’s the job, your interview should actually test for it.
What better interviews look like
I’m not suggesting you throw out technical evaluation entirely. You need to know someone can code. But there’s a difference between “can code” and “can solve novel algorithmic puzzles under time pressure with a stranger watching”.
Here’s what I’ve found works better:
Use real problems from your codebase. Not production code with NDA issues - but realistic, messy problems. “Here’s a service that’s having scaling issues. Walk me through how you’d diagnose it”. You’re looking for how they think, what questions they ask, what assumptions they surface.
Evaluate their relationship with constraints. Give them a problem with annoying limitations - technology choices they wouldn’t have made, timeline pressure, incomplete requirements. Do they fight the constraints or work within them? Do they ask clarifying questions or barrel ahead with assumptions?
Have them explain something complex to a non-expert. This is difficult to fake. Ask them to explain a technical decision from their past work as if they were talking to a product manager or a junior engineer. Listen for clarity, patience, and the ability to adjust their explanation based on feedback.
Focus your behavioural round on real situations. Not “tell me about a time you showed leadership”. Instead: “Tell me about a technical decision you made that you later realised was wrong. What did you miss? What would you do differently?” You’re looking for self-awareness, intellectual honesty, and the ability to learn from mistakes.
Have senior engineers do the interviewing. This seems obvious, but it matters. Junior interviewers often default to “did they get the answer” rather than “did they approach the problem the way I’d want a colleague to approach it”.
One change you can make this week
Pull up your current interview rubric - the criteria your team uses to evaluate candidates. Look at how the points are distributed.
What percentage tests for things you can learn in a few weeks on the job (specific technologies, particular algorithmic patterns)?
What percentage tests for things that take years to develop (judgment, communication, navigating ambiguity)?
If that ratio is backwards - and for most teams, it is - you have your answer. The skills you’re testing for aren’t the skills you actually need.
Fixing your interview process isn’t about finding the perfect set of questions. It’s about getting honest with yourself about what the job actually is, and having the discipline to evaluate for that job instead of some idealised version that doesn’t exist.
If you enjoy articles like these, you might also like some of my most popular posts:
See you in the next one,
~ Stephane
This matches exactly what I see running technical interviews day to day. I'd add one more piece: even once you fix what you're testing for, how you test it still matters. A messy, realistic problem still needs a clear rubric behind it, otherwise you're just trading algorithmic-puzzle bias for interviewer-gut-feel bias, which is its own kind of noise. I've also found you don't need five rounds to get this signal. One well-designed session built around a real problem tells me more about judgment and communication than three loosely defined "culture fit" conversations ever do, and it respects the candidate's time. Have you run into pushback internally when you try to shorten the process, even as you improve what's inside it?
Certainly the focus for senior hires should be behavioral and system design.
I love that you encourage leaders to start with understanding what works in their organization. This will allow them to pick structured signal areas to assess throughout the process, leading to better decision making and reducing bias.
I would also encourage teams to share that structured rubric with candidates, which will result in them being better prepared for the more precise interview questions you recommend.
(I think these precise questions are a double edge sword btw since they often assess preparation coverage and/or don't get to the candidate's most relevant stories. You and the candidate need to know how to guide the conversation to discuss and assess the signal areas despite question/story fit, and that takes a bit of skill and practice.)