← All posts
general

50 Engineering Manager Interview Questions by Round

The engineering manager loop tests a different muscle than the one that got you the interview. A senior engineer who prepares as always, by drilling design and code, walks into the people round with opinions and no stories. A career manager who prepares by polishing leadership stories walks into the technical round and cannot defend a schema. Both get the same debrief verdict: strong in places, not a hire.

This post lists fifty engineering manager interview questions grouped by the five rounds most companies run, with what the interviewers in each round are listening for and a sketch of an answer that would pass. It is the question bank; the engineering manager interview guide covers the loop itself and a preparation plan.

The shape of an EM loop

Most companies run some version of five rounds, each 45 to 60 minutes, after a recruiter screen and a first conversation with the hiring manager:

  1. People management. Performance, growth, conflict, hiring and retention. This round decides more EM loops than any other.
  2. Project and execution. Planning, prioritisation, estimates, the project that slipped, and how you report upward.
  3. Technical or system design. A design discussion graded on judgment, or a deep dive into a system your team owned. Coding is rare for EMs but not extinct; ask the recruiter.
  4. Cross-functional and product. Working with product, design, other engineering teams, and the people who outrank you.
  5. Hiring manager. Your future manager, checking fit for one team and whether your philosophy survives contact with their problems.

Variations candidates report (none of these companies publish their loop):

  • Amazon grades every round against the leadership principles, with a Bar Raiser in the loop; Hire and Develop the Best, Earn Trust and Deliver Results come up repeatedly for managers. A system design round is usual and a coding round depends on the team; the Amazon interview process guide covers the stages.
  • Google separates leadership, "Googleyness" and technical rounds, and the technical round is more likely to contain a real design or coding exercise. Candidates report a hiring committee, not the interviewers, makes the call.
  • Meta runs a people-management round and a project-retrospective round separately, plus a system design round at roughly a senior engineer's bar. Candidates consistently describe the level call (M1 against M2) being made from the scope of the stories.

If this is your first management role, read how to move from IC to manager first. Several questions below assume you have managed people; the honest answer for a tech lead is "here is the closest thing I have done", not a stretched story.

People management questions

  1. Tell me about the lowest performer you have managed. What did you do, and how did it end?
  2. Walk me through a piece of hard feedback you gave. How did you prepare, and what changed afterwards?
  3. Describe a time you lost someone you wanted to keep. What did you learn from the exit conversation?
  4. How do you decide who gets promoted? Tell me about a case where you argued for someone and lost, or chose not to argue.
  5. Two of your reports are in conflict and the team can feel it. What do you do, step by step?
  6. Tell me about managing someone more technically experienced than you.
  7. How do you run one-to-ones? What do you do when a report says nothing is wrong and you believe something is?
  8. Tell me about a time you let someone go. How did you reach the decision, and how did you handle the team afterwards?
  9. How have you grown an engineer from mid-level to senior? What did you do that they could not have done alone?
  10. Describe a time your team's morale dropped. What caused it, and what did you change?

What they listen for. Mechanism and follow-through. Everyone in this round has managed people, and they can tell a story that happened from one assembled for the interview by the uncomfortable middle: the week the feedback did not land, the report who disagreed with the rating, the exit handled rather than avoided. They want what you said in the room, roughly how long each step took, and an outcome stated plainly even when it is "they left, and the team got better". The red flags: every story ending "and they turned it around" with no visible mechanism, and a manager who has never lost anyone or let anyone go.

Answer sketch for question 1 (invented, for shape only). "I inherited an engineer rated below expectations twice without anyone telling him. In our second one-to-one I said so directly, with his previous manager's two written examples. We agreed a six-week plan: one visible deliverable each fortnight, a written check-in after each. He hit two and missed the third because he had picked up unrelated work, so the problem was prioritisation, not ability. I moved him to a single stream of work with daily visibility. By quarter end he was meeting the bar; eighteen months later I promoted him. Had he missed the third checkpoint for the original reason, HR was already briefed and I would have started a formal process."

Project and execution questions

  1. Tell me about a project that was going to miss its date. When did you know, what did you do, and what did you tell your stakeholders?
  2. Walk me through how your team decides what to work on next. Use a real quarter.
  3. Describe a time you cut scope to ship. Who pushed back, and what did you tell them?
  4. How do you estimate? Tell me about an estimate you got badly wrong and what you changed.
  5. What does your team measure, and what have you stopped measuring?
  6. Tell me about delivering something you disagreed with. What did you tell your team?
  7. Your team is spending most of its time on incidents and support instead of roadmap work. What do you do?
  8. Describe a project whose requirements changed halfway through. How did you re-plan, and what did it cost?
  9. How do you report status upward? What did you do the last time the honest status was bad news?
  10. Tell me about the hardest technical debt decision you have made as a manager: pay it down now, or ship the feature.

What they listen for. Early detection and honest reporting. A manager who knew in week three and said so is worth more than one who found out in week eleven and recovered heroically. They also want mechanisms that outlive the project: a planning cadence, a definition of done, a risk list that someone reads. Numbers matter here more than in any other round: team size, how long, how late, what was cut, what shipped. "We delivered on time" with no numbers reads as a passenger's view of someone else's project.

Answer sketch for question 1 (invented, for shape only). "A payments migration had a hard date because a vendor contract was ending. Three weeks in, the burn-down showed us missing by about a month. I told my director that week, with two options: cut the reporting module and ship the core path on time, or ask the vendor for a two-month extension at a cost finance had already estimated. We chose the cut. I wrote to the two downstream teams losing reporting and committed to a date for it. The core path shipped four days early and reporting six weeks later. Afterwards I changed the planning: every project with an external deadline now has a scope-cut line agreed on day one."

Technical and system design questions

  1. Walk me through the architecture of the most complex system your team owned. Where would you change it, and why have you not?
  2. Design a notification system for a product with ten million users. Tell me where you would want your senior engineers' opinion.
  3. Tell me about a technical decision you overruled. How did you know you were right, and were you?
  4. How do you review a design document? What was wrong with the last one you sent back?
  5. Your team proposes rewriting a core service. How do you decide?
  6. Tell me about a production incident where your team was at fault. What did the postmortem change?
  7. How do you keep your technical judgment current now that you do not write code every day?
  8. A senior engineer wants to adopt a new database or framework. Walk me through the conversation.
  9. How do you decide what gets tested, monitored and alerted on, and who carries the pager?
  10. Explain a consistency and availability trade-off your team made, in a system you can describe end to end.

What they listen for. Credibility, not virtuosity. The real question is whether senior engineers will respect you and whether you can tell a sound design from a persuasive one. They want to hear you ask about requirements before drawing boxes, name trade-offs rather than best practices, and say "I would want my staff engineer in this conversation" at the right moment without hiding behind it. For the design prompt itself the bar is roughly a senior engineer's: a working high-level design, a defensible data model, failure modes and operations considered; the system design questions by level guide shows that bar. Rustiness is forgiven in this round; bluffing is not.

Answer sketch for question 3 (invented, for shape only). "Two engineers proposed moving our event pipeline from a managed queue to a self-hosted streaming cluster, for cost. The cost case was real, about a third of the bill. I overruled it because nobody on the team had operated that cluster in production and we were about to lose our one infrastructure-leaning engineer to another team. I said so, with the on-call rota as evidence, and set a condition: a quarter of stable operation in staging with two people trained, and I would revisit. A year later, with a different team, they met it and we migrated. I was right for that year and wrong about the general idea, and I told them so."

Cross-functional and product questions

  1. Tell me about a disagreement with a product manager over priorities. How was it resolved, and who decided?
  2. Describe a time another engineering team blocked yours. What did you do before escalating, and did you escalate?
  3. How do you handle a stakeholder who goes around you to your engineers?
  4. Tell me about a time you said no to a senior leader.
  5. How do you explain a technical delay to a non-technical leader whose launch depends on it?
  6. Describe a time your team built the wrong thing. How did it happen, and what did you change?
  7. How do you work with design and product on a roadmap? Who owns what, concretely?
  8. Tell me about influencing a decision in a team you had no authority over.
  9. How have you handled a dependency on a platform or infrastructure team with different priorities from yours?
  10. Tell me about carrying out a decision you disagreed with. What did you tell your team?

What they listen for. Whether you treat other functions as peers or as obstacles. A strong answer names the other person's constraint accurately, shows you understood it before you argued, and ends with a decision that someone owned, including the times you lost. They are also checking how you represent your team's work sideways and upward: can you turn a migration risk into a launch risk a marketing director can act on. Blaming product or the platform team, or escalating as a first move rather than a last, each cost the round.

Answer sketch for question 1 (invented, for shape only). "Our PM wanted self-serve onboarding in the quarter I had planned to replace an authentication library with a known vulnerability. We disagreed for two weeks. What settled it was one page with both risks side by side: the likelihood and cost of the vulnerability being exploited, against her own revenue projection for self-serve. Read together, it was clear two engineers could do the library in four weeks while the other four started self-serve, two weeks later than she wanted. She agreed, on condition the self-serve date became my commitment too. It shipped a week late, which I had told her director in advance."

Hiring manager questions

  1. Why are you leaving your current role, and why management rather than a senior individual contributor path?
  2. Describe your management style in concrete terms. What would your reports say about you that you would not say about yourself?
  3. What would you do in your first 90 days with this team?
  4. Tell me about the manager you learned the most from, and what you do differently because of them.
  5. What kind of engineer do you find hardest to manage?
  6. How do you hire? Walk me through your last loop: the role, the sourcing, the decision, how it turned out.
  7. What is the biggest mistake you have made as a manager?
  8. How much do you want to stay technical, and how would you do that here?
  9. Tell me about disagreeing with your own manager. How did you handle it?
  10. What questions do you have for me about the team?

What they listen for. Fit with their specific problems, and whether they can picture handing you their team on Monday. The hiring manager has usually read the other interviewers' notes and is probing the gaps. They want self-awareness that is specific (a real mistake with a real cost, not "I used to care too much"), a 90-day plan that starts with listening rather than reorganising, and a hiring record you can describe in detail. Your questions at the end are graded too; nothing to ask about attrition, on-call, the last reorg or performance calibration reads as not having thought about the job.

Answer sketch for question 7 (invented, for shape only). "I kept a senior engineer on a project he had told me twice he wanted off, because he was the only one who knew the system and the date was close. He resigned the week after we shipped. The cost: the one person who understood a system we then spent four months re-learning. Now I treat 'I want off this project' as a deadline of its own, and I keep a written list of single points of failure that I review with my manager every quarter. On my current team nobody has been sole owner of a critical system for more than two quarters."

Level differences

The same fifty questions are asked at every level; what changes is the altitude of the story expected. Titles vary by company, so the table uses the three bands most loops calibrate against.

Engineering manager Senior engineering manager Director
Team One team, roughly 5 to 10 engineers, all direct reports Two or three teams, often through a tech lead or first-time manager Several teams through managers, typically 30 to 100 engineers
Time horizon This quarter and the next Two to four quarters; a roadmap you own One to three years; a strategy you set and a budget you defend
Who you influence Your team, your PM, adjacent teams Peer managers, your director, product leads across an area Directors and VPs elsewhere, other functions, sometimes customers
What "technical" means You can review a design and spot the risk You set technical direction across teams and arbitrate between them You decide where the organisation invests: build or buy, platform or product
What the people round probes Managing one engineer: performance, growth, conflict Managing managers, calibration across teams, hiring a manager Organisation design, succession, a reorg you led

So "tell me about a low performer" is about one engineer at EM, a manager who reports to you at Senior EM, and a whole team at Director, where the question becomes whether to restructure it. Answer at the level you are interviewing for. If your stories come from one level below, say so and explain what you would do differently with the larger scope; interviewers down-level pretenders, not honest candidates.

Answers that fail

Each of these recurs in EM debriefs and is fixable once you can see it.

  • Taking the team's credit. "We shipped the platform" tells the interviewer nothing about you. Say what you decided, what you said, and what you would have done differently.
  • No hard conversation stories. Three years of management with no firing, no exit, no performance plan and no disagreement with your own manager reads as either not doing the job or hiding the stories. Both grade the same.
  • No numbers. Team size, attrition, time to hire, how late, how much was cut. Managers who do not know their own numbers read as passengers.
  • Blaming the previous manager, the PM or the platform team. Even when true, it signals that the next company's problems will also be someone else's. Describe the constraint, then what you did inside it.
  • Hiding the technical gap. Interviewers would rather hear "I would have my staff engineer review the sharding decision, and here is what I would ask them" than a confident design that falls apart on the second follow-up.
  • Philosophy instead of mechanics. "I believe in servant leadership" answers nothing. "I meet each report weekly for thirty minutes, I write the notes, and I review growth plans every quarter" does.
  • One story told five times. Interviewers compare notes. Prepare eight to ten stories from the last two years before the loop; the story bank method is built for this, and the STAR shape keeps each one under three minutes.

Where coaching fits

The people and hiring manager rounds are where solo preparation runs out: the difference between empathy and evasion is in the delivery, and you cannot hear your own. The free practice interview (free, sign in with LinkedIn) runs a behavioural round with an AI interviewer and gives you a written recap of what worked and what to drill. For the delivery itself, the engineering management coaches here are or were engineering managers, and one is a VP of Engineering; they have sat in the debriefs where these answers are graded. One mock of the people round usually shows which of the patterns above you have.

Related guides