Engineering Manager Interview Questions

An engineering manager interview evaluates how you manage engineers, how you keep technical judgment while handing over the work, how you deliver and set priorities, how you work with product and other teams, and how you hire and grow a team. It is usually less technical than an engineer's loop and more technical than other management interviews, and the simplest question is the easiest to get wrong: how much do you still code? This page gives the question forms for each area, what strong answers include, the mistakes that cost the role, the follow-ups, how system design fits an EM loop, and how expectations change from EM to director.

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.

Mt

About the author

Mock Interview Pro team · Interview coaching and practice

Mock Interview Pro runs mock interviews and practice sessions with per-answer feedback. Our guides are built from the questions and answer patterns we see in those sessions and reviewed against the platform's coaching standards.