Engineering manager interviews are neither fully technical nor fully behavioral. They're both, and the mix trips people up if they're not ready for it.
ICs who have been out of hands-on coding for a few years often dread the technical parts. Managers who've stayed close to the code sometimes over-rotate to technical depth when the interviewer really wanted to understand how they make decisions. Getting the calibration right is the real preparation challenge.
How Technical Expectations Differ for Managers vs. ICs
When a company interviews a senior software engineer, they typically want to see that person write working code, debug real problems, and design systems at a detailed level. The technical bar is about depth and execution.
When a company interviews an engineering manager, the technical bar shifts. They're not expecting you to out-code your best engineer. They are expecting:
- That you can participate meaningfully in technical conversations
- That you can evaluate engineering work and make reasonable assessments of quality
- That you've made real technical decisions and can talk about the tradeoffs
- That you understand system design at a level that lets you guide architectural choices
- That you won't be fooled by bad engineering
The line varies by company. Some companies - particularly smaller startups - want manager-ICs who are still writing code. Others want pure people leaders who are deeply credible but not hands-on. Know which kind of company you're interviewing at and calibrate accordingly.
When in doubt, ask the recruiter before the interview: "What's the technical component of this process? Should I expect coding, system design, or something else?"
System Design Questions for Managers
System design questions are the most common technical component in EM interviews. You'll be asked to design a system - sometimes a familiar one like URL shortener, feed ranking, or ride-matching, sometimes something closer to what the company actually builds.
The evaluation here is different from an IC system design interview. They're less concerned with whether you can derive the exact right consistent-hashing algorithm and more focused on:
Do you identify the right requirements? Do you ask about scale, availability, consistency requirements, and latency constraints before you start drawing boxes? Or do you assume?
Can you make decisions and explain them? "I'd go with a relational database here because the data is highly relational and we need strong consistency" is better than "we could use either SQL or NoSQL, both have tradeoffs." Make a call.
Do you understand the implications of your design? If you propose a microservices architecture, you should be able to speak to the operational complexity it introduces. If you suggest an async queue, you should know what that means for latency and delivery guarantees.
Can you reason about tradeoffs at the right level? Not "we should optimize the byte count of our protocol" but "we have a tradeoff between consistency and availability here - given what you've told me about the requirements, I'd lean toward..."
Practice thinking through designs at this level. Use real systems you've worked with as examples. You don't need to memorize every caching algorithm - you need to show you can reason carefully about how systems behave under load, failure, and change.
Talking About Technical Decisions You've Overseen
One of the best sources of material for EM technical interviews is the decisions you've been part of as a manager. Think through:
- A migration or rewrite you led or influenced
- An architectural decision with lasting consequences (good or bad)
- A build vs. buy decision
- A time you pushed back on an approach and were right (or wrong)
- A technical failure you were close to and what you learned
For each of these, be ready to explain the technical context, the options you considered, how you influenced the decision, and what happened. You don't need to have written the code yourself to have a strong perspective on why a decision was right or wrong.
Be honest about your level of involvement. "I wasn't the architect, but I was deeply involved in the tradeoff discussion" is fine. Don't overclaim - experienced interviewers will probe and find out.
When to Show Depth, When to Admit You'd Delegate
This is a nuanced but important distinction.
There are topics where you should show genuine depth - areas central to your previous work, decisions you've owned, systems you've been closely involved with. Don't be falsely humble here. If you spent three years scaling a distributed data platform, own that expertise.
There are other topics where the right answer is honest about your limits. If an interviewer asks you about a technology outside your experience, it's fine to say: "I haven't worked with that directly, but here's how I'd think about evaluating it if we needed it on my team." Or: "That would be a decision I'd make in close partnership with the tech lead who has more context than I do."
Admitting you'd delegate on certain technical decisions is not a weakness - it's the right answer for a manager. The mistake is claiming false depth on things you don't know, or being so vague about everything that the interviewer can't assess your technical credibility.
A simple heuristic: show depth on things you actually know. Be honest about things you don't. Demonstrate sound judgment about how you'd approach the gap.
The Coding Question Problem
Some companies still include coding exercises in EM interviews. This varies widely - some companies skip coding entirely for managers, some require the same coding screen as ICs, and some include a lighter version.
If you've been out of regular coding for a while:
Do a refresher, but don't overdo it. Two to three weeks of LeetCode practice will get you back to basics. Focus on arrays, strings, hashmaps, and basic tree/graph problems. You probably won't need to solve hard dynamic programming problems - the expectation is usually adjusted.
Be transparent with the interviewer. "I want to flag that I've been less hands-on with coding over the last two years as I've moved into a management track - but here's my approach to this problem." That's honest and professional.
If you feel the coding screen is genuinely unfair - if they're requiring you to pass the same bar as senior IC engineers when you're interviewing for a management role - it's worth asking the recruiter whether that's the right evaluation format. Sometimes it's a miscalibration that can be corrected. Sometimes it's a real signal about what they want in the role.
Behavioral Questions with Technical Flavor
Expect behavioral questions that blend people management with technical judgment:
- "Tell me about a time you disagreed with a technical decision your team made."
- "How do you evaluate the quality of engineering work without being in the code yourself?"
- "Tell me about a time you had to make a significant architectural decision with limited information."
- "How do you handle it when an engineer proposes something technically sound but operationally risky?"
- "Tell me about a time technical debt affected your team's velocity. What did you do?"
For these, the STAR method applies, but your action component will often involve a combination of technical reasoning and people judgment. That mix is what makes a strong EM interview answer different from an IC answer.
The Real Goal
The company interviewing you for an engineering management role isn't trying to confirm you can still write code like an IC. They're trying to confirm that you can lead engineers credibly. That means you can have substantive technical conversations, make sound judgments about technical decisions, and earn the respect of strong engineers - without needing to be the best coder in the room.
Show that, and the rest follows.
Vidal Graupera
February 8, 2026