An engineering manager interview covers managing engineers, keeping technical judgment while delegating, delivery and priorities, working with product, and hiring. It is usually less technical than an engineer's loop and more technical than other management interviews. This page opens with twelve questions and sample answers, then covers what strong answers include, the common mistakes, the follow-ups, system design in an EM loop, and how expectations change from EM to director.
Table of Contents
- 12 Engineering Manager Intervi...
- How the interview is evaluated
- What an engineering manager in...
- Managing engineers
- Technical judgment and delegat...
- Delivery, process and prioriti...
- Working with product and other...
- Hiring and building the team
- System design in an engineerin...
- From tech lead to manager
- How expectations change with s...
- Practice the loop out loud
12 Engineering Manager Interview Questions and How to Answer Them
Question 1
Tell me about an engineer on your team who was not performing. What did you do?
What it tests
Whether you can diagnose the cause before acting, hold the direct conversation, and describe a change in the engineer's work rather than a process you introduced.
What a strong answer includes
A strong answer separates a skills gap from a scope or expectations problem and names the evidence used to tell them apart. It describes the conversation in the engineer's words as well as yours, the plan and the support attached to it, and ends with what changed in the work. It is honest about the timeline and about the outcome, including the cases that ended in a move or an exit.
Sample answer
One engineer on my team had missed three delivery dates in a row and his reviews were coming back with long comment threads. My first assumption was a skills gap, so before acting I read his last two projects and sat in on a design review. What I found was mostly scope: he had been handed a service with no clear owner and was making architecture calls alone, at a level he had not worked at before. I told him plainly that the work was not landing and that I thought the shape of the job was part of it. We narrowed his ownership to one component, paired him with a senior engineer on design calls for six weeks, and wrote down what a good month looked like. The missed dates and the review threads mostly went away once the scope was right. What remained was a real skills gap in testing, and we worked through it with smaller tasks and review time. Within a quarter he was shipping on his own estimates, and he kept the component permanently.
Question 2
How do you handle a senior engineer who disagrees with the team's technical direction?
What it tests
Whether you can hold a technical disagreement with someone deeper in the codebase than you, without overruling them by title and without letting the decision drift.
What a strong answer includes
A strong answer treats the disagreement as information first: what the senior engineer knows that shaped their position, and what would change your mind. It describes how the decision was actually made, who made it, what you did to keep the person committed once it went against them, and what you would revisit. If you have a case where you changed your own position, name it.
Sample answer
A senior engineer pushed hard against splitting our main service, and I had already told product we would. I asked him to write a page on what breaking it up would cost us, and I wrote one on why I wanted it. His page had two things I had not weighed: our deploy tooling assumed a single artifact, and two of the four boundaries I wanted were guesses. We agreed to extract only the boundary that was already stable, and to fix the deploy tooling first. I made that call and said clearly it was mine, then asked him to own the extraction so the work sat with the person who knew the risks. It shipped in about two months with no rollback, and we left the other boundaries alone. I still think a full split would have been wrong, and I would not have known that from my own page.
Question 3
Describe how you grew someone from mid-level to senior.
What it tests
Whether you can point to capability that did not exist before, and to the opportunities and feedback you arranged, rather than to training budget or a promotion cycle.
What a strong answer includes
A strong answer names the capability the person gained, such as owning an ambiguous project end to end or making a call under time pressure. It shows the work you chose for them, the feedback you gave while it was in progress, what you stopped doing yourself so they could do it, and where you let them get something wrong. The promotion is the result, not the story.
Sample answer
A mid-level engineer on my team wrote good code but had never scoped anything bigger than a ticket. The gap was ambiguity, not skill. I gave her a piece of work with a real problem statement and no design, our slow onboarding job, and told her the design review was hers to run. I reviewed her plan twice before it went out and pushed back on the parts where she was solving problems nobody had. In the review she got hit with a data migration question she had not considered, and I let that sit rather than answering for her. She came back a week later with a migration plan better than mine would have been. Over the next two quarters she scoped two more projects and started reviewing other people's designs. She was promoted at the next cycle, and what made the case was that she was already doing the work.
Question 4
How much do you still code, and how do you decide?
What it tests
Whether you have a rule for where your hands belong rather than a number, and whether that rule keeps you close enough to make technical calls without taking work away from the team.
What a strong answer includes
A strong answer gives the rule and the reasoning behind it: what you keep, such as prototypes, internal tooling, or enough reading of the code to know its shape, and what you no longer take, such as anything on the critical path or the on-call rotation. It admits the tension honestly and names how you would know you had drifted in either direction. A percentage on its own answers nothing.
Sample answer
Not much, and it is deliberate. My rule is that I take nothing on the critical path, because when I was newer to managing I did and I became the bottleneck twice in one quarter. What I keep is work nobody is waiting on: internal tooling, a spike when we are choosing between two approaches, and enough reading of pull requests to know the shape of the code. I stay on the review rotation for design documents but not for production changes. That comes to about half a day a week in the codebase. The check I use is whether I can hold a real conversation about a trade-off my team is making without them explaining the basics first. When I could not do that for our data pipeline, I spent two weeks reading it and sitting in on their planning until I could.
Question 5
Tell me about a technical decision you delegated that you would have made differently.
What it tests
Whether you can hand over a decision and let it stand, and whether you can judge the result afterwards without rewriting the history in your own favour.
What a strong answer includes
A strong answer names the decision, why you thought it was wrong, and why you let it go anyway, usually because the person owning it would live with the consequences and the choice was reversible. It says what actually happened, including the case where the other choice turned out better, and what you now check before stepping in.
Sample answer
My team was picking a queue for a new job runner and I wanted the one we already ran in production. The engineer who owned the project wanted a managed service, mostly because our existing setup had no dead letter handling and he did not want to build it. I thought the migration cost was not worth it and I said so once, in the design review, with my reasoning written down. Then I let him decide, because it was his project and it was reversible inside a quarter. He was right and I was wrong. The managed service took about three weeks to get working and it removed a class of on-call pages we had lived with for a year. What I took from it is that I was weighting my own familiarity as if it were a cost to the team. Now when I disagree I say it once, in writing, then ask what would have to be true for my objection to matter.
Question 6
How do you stay technical enough to make good calls without doing the work?
What it tests
Whether you have habits that keep your technical judgment current once you are no longer the person writing the code, and whether you know the limits of that judgment.
What a strong answer includes
A strong answer describes concrete habits with a cost attached: reading designs before the review rather than during it, sitting in on incident reviews, keeping a working local setup, asking to be walked through a system you do not know. It also names the limit, that you will be less deep than your engineers, and explains how you decide when their judgment is better than yours.
Sample answer
Three habits. I read every design document before the review rather than during it, so my questions are about the trade-off and not about the context. I go to incident reviews even when my team did not cause the incident, because that is where I learn what is actually fragile. And I keep the project running locally so I can read a stack trace without asking someone to translate it. What I gave up is depth. When we chose a search backend, two of my engineers understood the query patterns better than I did, so my job was to make sure the choice was written down with the reasoning and the cost of reversing it, not to pick it myself. The line I hold is that I should be able to explain any decision my team made to a director, and if I cannot, I do not know enough yet.
Question 7
Tell me about a project that was late. What did you do and what did you tell stakeholders?
What it tests
Whether you manage a slip by making a trade-off and saying so early, rather than absorbing it quietly and hoping the team catches up before anyone notices.
What a strong answer includes
A strong answer says when you knew, what you cut or moved, what you protected and why, and who heard about it and when. It names the trade-off in the terms the business cared about rather than in engineering terms, and it separates the recovery from the lesson. Blaming the estimate, or a slip stakeholders learned about at the deadline, undercuts everything else in the story.
Sample answer
We committed to a billing migration for the end of the quarter, and by week four it was clear we were about three weeks over, mostly because the old data was worse than the sample we had checked. I told our product manager and the finance lead that week rather than at the deadline, and I brought two options instead of a problem: ship the migration for new accounts on time and move the historical backfill out by a month, or hold everything and slip the whole thing. We took the split. I protected the reconciliation checks, because getting billing wrong quietly was the real risk, and I cut a reporting view that one team used. The new account path shipped on the original date and the backfill landed five weeks later. What I changed afterwards is that we now sample the ugly end of a dataset before committing to a date, not the clean end.
Question 8
How do you decide how much time the team spends on technical debt?
What it tests
Whether you can make the cost of debt visible to people outside engineering and decide with them, rather than defending a fixed share of the sprint on principle.
What a strong answer includes
A strong answer ties the debt to something the business feels: incident load, how long a typical feature takes, onboarding time, or a release that keeps slipping. It describes how you brought that evidence into the roadmap conversation, what you traded to get the time, and how you knew afterwards that it worked. A fixed percentage with no reasoning behind it is the weak version.
Sample answer
I do not hold a fixed percentage, because the number is never the argument. What I do is keep the cost visible. On my last team we tracked how long a feature took from start to release, and it had drifted from about two weeks to nearly four, almost all of it in a test suite that ran for forty minutes and failed randomly. I took that to our product manager as a delivery problem rather than a code quality problem, and asked for one engineer for three sprints. She agreed because the trade was concrete: one engineer now, or an extra week on every feature. The suite came down to eight minutes, the flakiness went away, and lead time came back under three weeks. When there is no number like that available, I keep a standing share of the sprint for the work and let the team choose what goes in it, but I still expect them to say what it bought.
Question 9
Describe a disagreement with your product manager and how it was resolved.
What it tests
Whether you own the outcome jointly with product or argue engineering's case against them, and what you tell your own team while the disagreement is still open.
What a strong answer includes
A strong answer starts from the goal you shared, names the constraint the other side was working under, and shows how the decision was actually made rather than who won. It says what you told your team while it was unresolved, and it includes a case where you changed your plan because of something product knew. An answer where product is the source of unreasonable requests is the failure mode.
Sample answer
Our product manager wanted a redesigned onboarding flow in six weeks and my estimate was eleven. My first instinct was to defend the estimate, which would have gone nowhere. Instead I asked what the six weeks was tied to, and it was a partner launch with a contract date I had not known about. That changed the problem from schedule to scope. We went through the flow together and found the partner only needed two of the five steps rebuilt, while the other three could keep the old behaviour behind the new styling. That version was seven weeks, and we agreed to move the launch by a week rather than cut the checks in the payment step. While it was open I told my team exactly where it stood, that the date was real and the scope was still being argued, because the worst version of this is engineers hearing a commitment from someone else. We shipped in seven weeks and the rest of the flow landed the next quarter.
Question 10
Tell me about a hiring mistake and what you changed.
What it tests
Whether you take responsibility for a hire that did not work, and whether you changed something in the loop rather than concluding that the candidate misled you.
What a strong answer includes
A strong answer names what the loop failed to test, not only what the person turned out to be like. It describes what you did once you knew, including the conversation with the person and how long you waited to have it, and the specific change you made afterwards: a new exercise, a different question, a decision rule for a split debrief. Hiring people who resemble you is worth naming if that is what happened.
Sample answer
I hired a strong senior engineer onto a team that had almost no existing structure, and it did not work. In the loop we tested design and coding depth carefully and every signal was good. What we never tested was how she worked when nothing was specified, and that was most of the job on that team. Three months in she was frustrated and blocked, and I had been reading it as ramp-up time rather than a mismatch. I had the direct conversation late, which is the part I regret. We moved her to a team with a clearer roadmap and she did well there for years. What I changed is that I added a scoping exercise for any role on an early team: a one page problem statement, no requirements, and forty minutes to say what they would build first and what they would need to ask. It has changed two hiring decisions since, one in each direction.
Question 11
Design a notification service for us. What would you build first?
What it tests
Whether you can scope an open problem, name the trade-offs that matter and explain each choice clearly. Prepare to show that alongside your technical depth.
What a strong answer includes
A strong answer spends real time on the requirements and constraints before drawing anything, states the two or three decisions that actually matter and what each costs, and picks a first slice that could ship and teach you something. Explain each trade-off in terms a product manager could repeat rather than leaning on the name of a technology, and say what you would defer.
Sample answer
Before designing anything I would want three numbers: how many events a day, how fresh the data has to be, and what it costs us to lose one. Say it is a few million notifications a day, near real time, and losing one is bad but not fatal. Then the decisions that matter are how we record what we have sent, whether delivery is at least once or exactly once, and what happens during a provider outage. I would take at least once with idempotency keys, because exactly once buys complexity everywhere for a problem the receiving side can absorb. The first thing I would build is the highest volume notification type end to end, with the queue and the deduplication in place, because that proves the delivery path under real load. Templating, per user preferences and batching all come after. If I were wrong about the freshness requirement, the queue choice is what I would have to revisit, so I would confirm that number first.
Question 12
You have led technically but not managed. What makes you ready for this role?
What it tests
Whether you can draw management evidence from tech-lead work honestly, and whether you understand what changes when the team's results rather than your own output are what gets judged.
What a strong answer includes
A strong answer is exact about scope, including that you did not hold the title, then carries the weight with evidence: someone you grew, a decision you handed over and let stand, a conflict you settled, direction you set without authority. It also names what you have not done, such as running a performance cycle or managing someone out, and how you plan to learn it. Do not claim the title informally.
Sample answer
I have not held the title, so let me be exact about what I have done. For the last two years I was tech lead on a team of six. I did not run performance reviews or set compensation, and I have never managed anyone out, which is the biggest gap and I know it. What I have done is most of the rest. I onboarded three engineers, and one of them now owns the service I used to own. I settled a month-long disagreement between two engineers about our API versioning by getting both positions written down and then making the call, and both of them stayed committed to it afterwards. I set the direction for our migration with no authority to make anyone follow it, which meant making the case repeatedly to people who could have ignored me. The part I would need support on is the formal side: reviews, compensation conversations, and the underperformance path. I would want a manager willing to sit in on the first few of those with me.
How the interview is evaluated
What an engineering manager interview evaluates
Prepare an engineering manager loop as a management interview with a technical component, not the other way round. Expect some technical rounds, often a system design conversation and sometimes a coding or architecture discussion, and prepare them for judgment and communication as much as for depth: can you scope a problem, name the trade-offs, and explain them to someone who is not an engineer. Prepare the people-management rounds as the ones that matter most.
It helps to think of the loop as six areas, each with its own questions:
- Managing engineers: performance, feedback, growth, conflict on the team.
- Technical judgment and delegation: what you decide, what you hand over, and how you stay close enough to decide well.
- Delivery, process and priorities: estimates, scope, incidents, technical debt.
- Working with product and other teams: alignment as a manager rather than as a tech lead.
- Hiring and building the team.
- The shift from tech lead to manager, which runs underneath all of the others for a first-time EM.
The management interviews guide explains how management answers are evaluated across every role. The rest of this page is specific to engineering.
Managing engineers
For a candidate coming from a tech-lead role this is the half with the least practice behind it, and the half worth preparing hardest.
Question forms you may hear:
- Tell me about an engineer on your team who was not performing. What did you do?
- How do you handle a senior engineer who disagrees with the team's technical direction?
- Describe how you grew someone from mid-level to senior.
A strong performance answer starts with the diagnosis, because on an engineering team two frequent causes look alike from the outside: a skills gap, and a scope or expectations problem, where the engineer is capable but the work was badly shaped or never clearly owned. Show how you told them apart, the conversation you had, the plan and the support, and what changed in the engineer's work. A strong growth answer names the specific things the person could do afterwards that they could not before, and what you did to create those chances.
Failure modes: fixing the code instead of having the conversation; hiding behind process (sprints, reviews, rituals) when the question is about a person; and describing growth as sending someone to a conference.
Follow-ups to expect: "How did the engineer react?", "How did you know it was a skills gap and not the work?", and "What did the rest of the team see?" Underperformance and feedback are their own competency; the performance management interview questions page covers the sequence in full. Disagreement with a senior engineer about direction is often a conflict question in disguise; the conflict management interview questions page covers how to tell it.
Technical judgment and delegation
This is the tension specific to engineering management: staying credible enough to make good technical calls without being the person who makes all of them.
Question forms:
- How much do you still code, and how do you decide?
- Tell me about a technical decision you delegated that you would have made differently.
- How do you stay technical enough to make good calls without doing the work?
The "how much do you code" question rarely has a right number, and answering with one misses the point. A strong answer explains the rule you use: what you keep (architecture reviews, the decisions that are hard to reverse, enough reading of the code to know its shape) and what you have handed over (implementation, most design decisions, the on-call rotation), and gives an example of a decision you let stand even though you would have made it differently, and what happened.
Failure modes: still the tech lead, where every story ends with you writing the critical piece; abdicating technical judgment entirely, so you cannot describe a single technical trade-off your team made; and answering the coding question with a percentage and nothing else.
Follow-ups to expect: "What is the last technical decision you overruled, and why?", and "What would your engineers say about how much you get involved?" Handing over decisions, not only tasks, is the competency underneath; the delegation interview questions page covers it.
Delivery, process and priorities
Question forms:
- Tell me about a project that was late. What did you do and what did you tell stakeholders?
- How do you decide how much time the team spends on technical debt?
A strong delivery answer names the trade-off you made when the plan slipped: what you cut, what you protected, whom you told and when. A strong technical-debt answer describes how you make the cost visible to people outside engineering and how you decide, rather than asserting a fixed share of time.
Failure modes: blaming estimates or requirements; describing process changes as the outcome; and stakeholders who learned about the slip at the end.
Working with product and other teams
Question forms:
- Describe a disagreement with your product manager and how it was resolved.
- How do you handle another team's dependency blocking yours?
As a tech lead you argued engineering's case; as a manager you own the outcome with product. A strong answer starts from the shared goal, names the constraint the other side was working under, shows how the decision got made when you disagreed, and says what you told your team while it was unresolved.
Failure modes: engineering-versus-product framing, where product is the source of unreasonable requests; going around the other team's manager; and having no story of changing your own plan because of what product knew.
Influence over people you do not manage is its own competency; the stakeholder management interview questions page covers it, including how the question differs for product and project roles.
Hiring and building the team
Question forms:
- How do you run a hiring loop, and what do you look for?
- Tell me about a hiring mistake and what you changed.
A strong answer describes what you actually test for and how, how you decide between candidates who are strong in different ways, how you close, and what onboarding looks like in the first month. Prepare a hiring-mistake story, with what you changed in the loop afterwards.
Failure modes: hiring for yourself, where every good hire resembles you; no onboarding plan, so the story ends at the offer; and describing the company's process rather than your own judgment inside it.
System design in an engineering manager loop
Many EM loops include a system design conversation, and it is easy for a candidate coming from a senior engineering role to prepare for it as if it were an engineer's round. Prepare for it as a manager: the evidence to show is scoping an ambiguous problem, naming the trade-offs and their costs, deciding what to build first and what to defer, and explaining the choice in terms a product manager could repeat. Prepare to show judgment across the design rather than depth in any one component.
Prepare enough to hold a coherent design conversation on the kinds of systems your target team runs. Do not spend the week before the interview on distributed systems drills at the expense of the people-management stories, which are harder to improvise.
From tech lead to manager
If you are interviewing for your first EM role, this shift runs underneath every answer. The change is in what the story is about: as a tech lead, the story is what you built and decided; as a manager, the story is what others built and decided because of how you ran the team.
You can draw management evidence honestly from tech-lead work: the engineer you mentored into owning a system, the disagreement you settled between two engineers, the decision you delegated and let stand, the project where you set direction without authority. State the scope plainly, including that you did not hold the title, and let the evidence carry it. The leadership interview questions page covers how to show direction and influence with and without formal authority.
How expectations change with seniority
- Engineering manager: one team, hands-on technical judgment, and evidence of growing individuals.
- Senior engineering manager: multiple teams or a large one, systems for performance and hiring rather than single cases, and ownership of a roadmap.
- Director: managing managers, organisational design, budgets and strategy. Prepare for questions about developing engineering managers and about structure, not only about engineers.
Practice the loop out loud
Five stories cover the areas above: an engineer whose performance you managed, a technical decision you delegated, a delivery that slipped, a disagreement with product, and a hire you got wrong or right. Rehearse them spoken, with the follow-ups asked immediately: "how did you know", "what did you tell them", "what would you do differently".
A manager mock interview built for an engineering manager target role runs the people-management rounds with feedback on each answer, so the story that is still about your own code shows up before the interviewer finds it.
Practice these questions out loud
Reading a list is silent rehearsal. Run a mock interview for your target role and get feedback on every answer.
Start a mock interview
About the author
Mock Interview Pro team · Interview coaching and practice
Mock Interview Pro runs mock interviews and practice sessions with per-answer feedback, so you can rehearse questions like these out loud before the real interview.
