Engineering Manager Interview: People, Delivery and Technical Rounds Explained

They answer like an engineer, not like a manager. In an engineering manager interview, the panel wants proof that you grow people and deliver through a team. Clever code you wrote yourself does not answer that.

Picture a common setup. A senior backend engineer in Bengaluru has informally led four engineers for a year and now has a five-round manager loop. The setup is made up, but the rounds match public hiring pages quoted below.

In the people round, they are asked about an engineer who kept missing commitments. They explain how they rewrote that engineer's code over a weekend. The interviewer hears a hero story, not a management story.

In the project round, they spend twenty minutes on database choices. They never mention how they split the work, handled a slipping date or told the product manager. The technical detail was correct, but it answered a different question.

This guide follows that candidate through the whole loop. Each section shows what the round is for, what public frameworks say managers do, and how to shape your answer.

You need about ten words. Each one shows up in job pages, interview feedback and the questions themselves.

An engineering manager interview is a loop of conversations that tests whether you can lead a team of engineers. The rounds to prepare for cover people, delivery, a past project and technical judgement.

Companies publish very different amounts about their loops. GitLab publishes its manager process openly, in its public handbook. As of 25 October 2026, it lists these steps in order.

Some companies label rounds by theme rather than by who runs them. The table below groups the themes you are likely to meet. It is a planning aid built from the sources in this guide, not any one company's official list.

Beginners can stop here and still walk into a loop knowing what each round is for. The rest of the guide shows how panels score and how to answer each round.

Well-run panels score evidence against a rubric, not general impressions. The US Office of Personnel Management (OPM), the federal government's HR agency, describes structured interviews as using rules for asking, observing and evaluating answers.

OPM's guidance says panel members rate answers on their own first, then discuss large differences as a group. Google's re:Work site says Google often documents what poor, borderline, solid and outstanding answers would cover.

We could not find a large company's full manager rubric published as of 25 October 2026. Two public sources come close and overlap a lot, so they make a good map for preparation.

• Project Oxygen, Google's research on managers, lists ten behaviours on re:Work. Examples are "Be a good coach", "Support career development and discuss performance" and "Have key technical skills".
• Dropbox's public engineering career framework groups manager expectations into Results, Direction, Talent and Culture, plus a Craft section on technical and business skills.

Show the whole arc: what you noticed, the conversation you had, the support you gave, the deadline you set and the result. Panels want to see that you act early and treat people fairly.

If you already use STAR (situation, task, action, result) for behavioural answers, keep it. Amazon's public interview guide calls STAR the cornerstone of its behavioural interviews. Manager answers just need extra detail inside the action part.

The manager's version of an action

1. 1

   Noticing

   Say what signal you saw and when, such as missed reviews for three weeks. This shows you watch the work and the person.

2. 2

   Conversation

   Say what you told the person, in close to the words you used. Panels probe this, so prepare the real sentence.

3. 3

   Cause

   Say what you learned was behind it: unclear expectations, a skill gap, a personal issue or a poor fit.

4. 4

   Support and expectation

   Say what help you gave and what clear goal you agreed, with a date to check it.

5. 5

   Outcome

   Say what happened to the person and to the team. Not every story needs a happy ending, but it needs an honest one.

6. 6

   Reflection

   Say what you would do earlier or differently next time. This is often what separates a solid answer from an outstanding one.

A weak and a strong answer, side by side

Back to our candidate. The question is: "Tell me about an engineer on your team who was struggling." Here are two versions of the same story.

What just happened? The facts barely changed, but the stronger answer shows coaching, a clear expectation and a fix that helps the next person too. The weak answer shows a manager doing an engineer's job.

Questions you should have a story for

• An engineer who was struggling, and what happened in the end.
• Two engineers in conflict, and how you resolved it without taking sides early.
• Someone you helped grow into a bigger role or a promotion.
• Hard feedback you gave to a strong performer.
• A hire you made, how you judged the candidate, and a hiring mistake you learned from.
• A time you changed your own behaviour after feedback from your team.

For performance problems, also say who you involved. Dropbox's framework expects a manager at its first manager level (M3) to address performance issues with support from their own manager. Naming your manager or HR partner shows you know you are not working alone.

Show how you plan, how you spot risk early and what you do when a date is in danger. The panel wants a repeatable way of working, not one heroic save.

• Planning: how you broke a goal into pieces, estimated them and agreed a date with the people who depend on it.
• Risk: what early warning you watched, such as unfinished dependencies, and when you raised it.
• Trade-offs: what you cut, delayed or added people to, and who agreed to that change.
• Communication: how often stakeholders heard from you, and how you told them bad news.
• Incidents: how you ran a review after an outage and what changed afterwards.

For incident questions, the language of blameless postmortems helps. A postmortem is a written review of what happened after an outage. Google's Site Reliability Engineering book says a blameless postmortem focuses on contributing causes without blaming any person or team. Show that you fixed the system, not just the person.

Debugging a team that keeps missing dates

Expect a scenario question like "Your new team has missed its last three deadlines. What do you do?" This is a hypothetical question, and it rewards a diagnosis before a fix.

Pause and predict: which would you check first, the team's skill or whether the team knows what done means? The tempting answer is to blame skill or to add process.

A sound frame comes from Project Aristotle, Google's study of 180 teams, published on re:Work. It found that how a team works together mattered more than who is on it. It lists five dynamics.

The five dynamics, in the order re:Work lists them, are psychological safety, dependability, structure and clarity, meaning and impact. Psychological safety means people feel safe to take risks, such as admitting a mistake, in front of teammates.

In an answer, say how you would find out, not just what you would change. For example, you might hold 1:1s in your first two weeks, read the last few project plans and sit in on planning meetings.

Think of it like a doctor seeing a patient with a fever. The doctor asks questions and runs checks before prescribing anything, because many causes look the same from outside. Where the picture breaks: a team can tell you what is wrong if you make it safe to say.

Pick one large project where you made real decisions, then prepare to explain your part at three levels: the business goal, the team plan and the technical choices. Expect the interviewer to keep asking why.

The trap to avoid is telling only the team's story. Amazon's interview guide advises using "I" statements to show your personal contribution. It also advises giving precise numbers that show your impact.

1. 1

   Context in two minutes

   Say what problem the project solved, for whom, how big the team was and how long it took.

2. 2

   Your role

   Say exactly what you owned: hiring, planning, the design review, stakeholder updates or all of these.

3. 3

   Two or three key decisions

   For each one, give the options, what you chose, why, and who disagreed.

4. 4

   What went wrong

   Name a real problem, such as a slipped milestone or a bad estimate, and what you did about it.

5. 5

   Results with numbers

   Give before and after figures, such as release time or support tickets, and say how you measured them.

6. 6

   What you would change

   Say what you would do differently with what you know now.

Prepare a backup project too. If the interviewer finds the first one too small or too old, you can switch without freezing.

Our candidate's project round failed because the database choice was the whole story. A better version spends two minutes on that choice, then covers how they staffed the work, cut a feature to protect the date and told the product manager early.

Technical enough to judge designs, spot risks and earn engineers' trust, but you are not judged as the team's best coder. Public frameworks keep technical skill on the list without making it the whole job.

• Project Oxygen lists "Have key technical skills" as one of its ten manager behaviours, as of 25 October 2026.
• Dropbox's page for its first manager level (M3) expects the manager to identify technical risks before they jeopardise the project.
• GitLab's engineering manager page asks managers to foster technical decision making on the team, but make final decisions when necessary.

Technical rounds for managers can be system design conversations, but formats vary. Some companies add coding or code review and others do not. Ask your recruiter which one you will get, and practise that format.

The SevyDevy guide System Design Interview Levels: Junior vs Senior vs Staff shows how design answers deepen with seniority. Managers can use the senior and staff answers there as a benchmark.

Spend most of your time on stories, because the people, delivery and project rounds all ask about your past. The plan below is our advice for someone working full time, at about an hour a day.

1. 1

   Week 1: collect stories

   List ten real management moments, then tag each with rows from the signal table. Fill any empty row with a new story.

2. 2

   Week 2: write and trim

   Write each story as short notes in the six action parts. Aim for two to three minutes spoken, as Amazon's guide suggests.

3. 3

   Week 3: project and design

   Prepare one main and one backup project for the deep dive. Practise one system design question in the format your recruiter named.

4. 4

   Week 4: mock loops

   Ask a manager you trust to run two mock rounds and probe hard. Record yourself and listen for "we" where you mean "I".

5. 5

   Before the loop

   Ask the recruiter for the round names and who runs each one. Prepare three questions about the team for every interviewer.

How do you check the prep worked? Ask a friend to read your story notes and name which signal rows each one hits. If they cannot name two rows, the story needs more management detail.

The SevyDevy guide Behavioral Interview Prep for Engineers covers building a story bank and STAR in more depth. Use it for the basics and this guide for the manager layer.

The mistakes below mostly come down to answering a different question than the one asked. These are patterns to watch for in your own practice answers; they are our advice, not published pass rates.

• Saying "we" all the time, so the panel cannot tell what you did.
• Fixing a person's work yourself instead of coaching them, then calling it leadership.
• Jumping to firing or to new process before describing what you learned.
• Blaming the previous manager, another team or the product manager.
• Giving no numbers, so the result sounds like an opinion.
• Spending the project round on technical detail and skipping planning, people and stakeholders.
• Having no failure story, or a failure that was secretly a success.

Disagreement questions need care too. Amazon's leadership principles say leaders should respectfully challenge decisions they disagree with, then commit fully once a decision is made. A good answer shows both halves.

Answer the design first, then add the manager layer: who builds it, in what order, how you roll it out and how you keep it running. Use the round to show you think about people and delivery, not only boxes.

1. 1

   Clarify the goal

   Ask who the users are, what success means and what the deadline is. Say which of these would change the design.

2. 2

   Sketch a simple design

   Draw the main parts and one request flowing through them. Keep it small enough to explain in five minutes.

3. 3

   Name the risky parts

   Point to the one or two parts most likely to fail or slip, and say how you would test them early.

4. 4

   Plan the team and phases

   Say how you would split the work across engineers and what ships in the first milestone.

5. 5

   Plan rollout and support

   Describe a gradual rollout, the alerts you would add and who is on call, meaning ready to respond to alerts, after launch.

6. 6

   Close with trade-offs

   Say what you chose not to build yet and what would make you change your mind.

When the loop ends and an offer arrives, the SevyDevy guide Salary Negotiation for Engineers covers the next conversation.