Engineering Manager interview questions, with worked answers

How to use these questions

Most of these are behavioural questions: the interviewer wants a case from your own work. Answer with the situation in one or two sentences, then what you did and why, then the result, then what you learned. Keep names and confidential details out; the shape of the story is what counts.

What an engineering manager is expected to know

• People: leadershipAsked in 8% of engineering manager ads (as of 5 Nov 2026).Lead people who know more than you about their code: set direction, give feedback, grow them, decide. of engineers, one-to-ones, feedback, growth and hiring, and communicationAsked in 36% of engineering manager ads (as of 5 Nov 2026).Say the hard thing clearly and kindly, in one-to-ones, in writing and in front of leadership. that is clear in both directions.
• Delivery: agileAsked in 0% of engineering manager ads (as of 5 Nov 2026).Run a team's way of working so it ships often and learns from each release, whatever the method is called. ways of working, planning across teamsAsked in 36% of engineering manager ads (as of 5 Nov 2026).Plan larger deliveries across teams: milestones, dependencies, risks and an honest date range., estimates with honest ranges, and goals that some firms set as OKRs.
• The business: stakeholder managementAsked in 10% of engineering manager ads (as of 5 Nov 2026).Keep product, design, sales and leadership informed and agreed on what the team does and why. with product, sales and leadership, and presentingPresent a plan, an incident or a headcount request to leadership in a few clear slides. a plan or a problem.
• Enough technology: what the delivery pipelineAsked in 7% of engineering manager ads (as of 5 Nov 2026).Understand the delivery pipeline well enough to judge release risk and to back the team's investment in it., the architecture and the cloud bill mean for risk and speed, so you can weigh trade-offs with the engineers.

The tools are named in ads side by side and none is a must everywhere: Jira, Linear or Azure DevOps to track work, Confluence or Notion for documents, and Lattice or Culture Amp for reviews and feedback in some companies. What interviewers test is how you used them to help the team, not the tool itself.

People: one-to-ones, feedback and growth

How do you run one-to-ones, and what do you do when an engineer has nothing to say?

What they check: that one-to-ones are for the engineer, not a status meeting.

Short answer: "A one-to-one is a regular private talk, usually weekly or every two weeks, that belongs to the engineer. I let them set the topics, keep notes we both can see, and leave status for the team's channels. When someone has nothing to say, I ask about energy, blockers, what they want to learn and what they would change in the team."

The full answer: Silence often means trust has not been built yet, or the person does not see the point. Keep the meeting, shorten it, and follow up on what they said last time: acting on small things is what makes people bring big ones. Move career talk to its own slot every few months.

A weak answer: "We go through the tickets together." Follow-up: "How do you know your one-to-ones are working?" Name a signal, such as problems raised early.

Tell me about a time you gave difficult feedback to a strong engineer.

What they check: courage, care and a clear message.

Short answer: "A senior engineer's code reviews were blunt and newer people stopped asking for them. I told him privately, soon after one example, what I saw, the effect on the team and what I needed instead, and asked how he saw it. We agreed on a change and I checked back two weeks later."

The full answer: Good feedback is specific, about behaviour and its impact, given early and in private. Strong performers often hear only praise, so they need honest feedback most. Follow up: notice the change and say so.

A weak answer: "I waited for the annual review." Follow-up: "He disagreed with you." Say how you would listen and still hold the line.

An engineer has been underperforming for two months. What do you do?

What they check: fairness, speed and documentation.

Short answer: "First I find out why: unclear expectations, the wrong work, a skill gap or something outside work. I state the gap with examples, agree what good looks like and by when, and support it with pairing or a mentor. If nothing changes after a fair period, I work with HR on a formal plan."

The full answer: Most underperformance is fixed by clarity and support; some needs a different role. Write things down from the start so the person is never surprised. Protect the team from carrying the gap for months. In some countries the formal steps are set by law or by a works council agreement, so HR leads them.

A weak answer: "I would move them to another team." Follow-up: "The person tells you they are dealing with an illness." Explain how that changes the plan.

How would you set up hiring for your team, and how do you make onboarding work?

What they check: a fair, structured process and new people productive quickly.

Short answer: "I agree with the team what the role needs, then run a structured process: the same questions for each candidate, a realistic work sample, and interviewers who score before they talk. For onboarding I prepare a buddy, access on the first day, a small change shipped in the first week and clear goals for the first three months."

The full answer: Hiring well is the most lasting thing a manager does. Watch for bias: diverse panels, written criteria and the same chances for every candidate. Measure onboarding by how soon a new engineer works on their own, and ask them what was missing.

A weak answer: "I hire people I would like to have a beer with." Follow-up: "You need three engineers in a hard market." Say where you would compromise and where not.

How do you decide who is ready for a promotion, and how do you use a career ladder?

What they check: that promotions rest on evidence, not on who is loudest.

Short answer: "A career ladder describes what each level means in scope, impact and behaviour. I use it in career talks to agree the next step with each engineer, help them find work at that level, and collect evidence as we go. When the evidence shows they already work at the next level, I make the case."

The full answer: Promotion should confirm what is already happening. Calibrate with other managers so levels mean the same across teams. Be honest about gaps early, so nobody is surprised by a no.

A weak answer: "After two years people are due." Follow-up: "Two engineers want the same senior role on a small team." Explain how you would handle it.

Two senior engineers disagree strongly on a design and the team is split. How do you handle the conflict?

What they check: that you resolve conflict without becoming the bottleneck.

Short answer: "I make sure both sides write down the options and the trade-offs against the same criteria, such as cost, risk and how hard it is to change later. Often the choice becomes clear. If not, I name who decides, often the tech lead or the architect, set a date, and ask everyone to commit even if they disagreed."

The full answer: Separate the technical question from the personal friction and deal with both. A decision record helps the team remember why. If the same two people clash again and again, that is a people matter for one-to-ones.

A weak answer: "I pick the option I like best." Follow-up: "The decision turns out wrong six months later." Say how the team should react.

How do you spot burnout in a team, and what do you change?

What they check: attention to people's limits and to the causes, not only the symptoms.

Short answer: "Signs are late messages, short tempers, more mistakes, people going quiet in meetings and more sick days. I ask directly in one-to-ones, then fix causes: too much work in progress, an unfair on-call rotation, constant interruptions or unclear priorities."

The full answer: Psychological safety, the feeling that you can speak up without being punished, makes people tell you before it is too late. Protect focus time, share on-call fairly, and push back on dates that need overtime as a plan.

A weak answer: "Everyone is busy; that is the job." Follow-up: "Leadership wants the release next month anyway." Say what you would offer.

Delivery: estimates, priorities, debt and incidents

How do you estimate a large piece of work and give stakeholders a date?

What they check: honest ranges and early warnings.

Short answer: "I let the engineers break the work into smaller parts and estimate those, compare with similar past work, and give a range with the main risks, not a single day. I share what would make it earlier or later and update the range as we learn, so a slip is never a surprise."

The full answer: Fixed dates are sometimes real, such as a law or an event; then scope is what moves. Agree early which parts are must-haves. A short first slice that ships tells you more about the estimate than any meeting.

A weak answer: "I add fifty percent to whatever the team says." Follow-up: "Halfway through, you see the date will not hold." Say when and how you tell people.

Product wants three features this quarter and the team can deliver two. How do you set priorities with the product manager?

What they check: partnership with product and saying no with reasons.

Short answer: "The product manager owns what matters most to customers; I own what the team can do and at what cost. We look at the value and effort of each together, and I offer options: two full features, or three smaller versions. The choice is theirs, with the trade-off clear."

The full answer: Keep a visible roadmap, the plan of what comes next and why, so trade-offs are made in the open. Protect a share for reliability and debt that both of you have agreed. Escalate together, not against each other.

A weak answer: "We will just work harder." Follow-up: "The CEO promised the third feature to a customer." Explain what you would do.

How much time should a team spend on technical debt, and how do you argue for it?

What they check: that you can explain engineering needs in business terms.

Short answer: "Technical debt is the cost of past shortcuts that slows every change today. I argue for it with its effect: slower releases, more incidents, longer onboarding. Many teams keep a steady share of each sprint or quarter for it, and fix the debt that sits in the parts they change most."

The full answer: Not all debt needs paying. Track the few items that really hurt, tie each to a measure, and report what changed after fixing it. That earns the next round of trust.

A weak answer: "We will rewrite it when we have time." Follow-up: "Product says debt work has no visible value." Give a one-sentence answer.

Walk me through how your team handles an incident, from the alert to the review.

What they check: calm process and learning without blame.

Short answer: "The on-call engineer, the person on duty that week, gets the alert, takes the lead or calls for help, and someone keeps users and stakeholders informed. Once it is fixed we hold a blameless postmortem: what happened, why our systems allowed it, and the actions that make it less likely, each with an owner."

The full answer: My job during an incident is mostly to protect the people fixing it: clear roles, no crowd of managers asking for updates, and a break for whoever was up at night. After, I make sure the actions get done and are not lost behind new features.

A weak answer: "We find out who made the mistake." Follow-up: "The same kind of incident happens again." Say what that tells you.

Which metrics do you use to understand delivery, and which ones do you refuse to use?

What they check: that you measure the system, not individuals.

Short answer: "I look at team-level flow: the DORA metrics, named after a research programme and not the EU's financial rules of the same name, which are how often we deploy, how long a change takes to reach users, how often a change fails and how fast we recover, plus cycle time and how much work is in progress. I refuse to rank people by tickets closed or lines written."

The full answer: Metrics start conversations; they do not end them. Use them as trends for the team, combine them with how people feel and what customers say, and be careful where a works council or local rules limit tracking.

A weak answer: "Story points per developer." Follow-up: "Leadership wants one number for productivity." Explain what you would offer.

How do you run a remote or distributed team well?

What they check: deliberate habits, not hope.

Short answer: "Write things down: decisions, plans and meeting notes. Keep a few shared hours for live talk and protect the rest for focus. Make sure people in other time zones are not always the ones joining late at night, and meet in person from time to time."

The full answer: Remote teams lose the small talk where problems surface, so one-to-ones and open channels matter more. Watch that people far from the office get the same visible work and the same chances of promotion.

A weak answer: "I check that people are online." Follow-up: "One engineer never speaks in calls." Say what you would try.

Senior rounds: managers, budgets and stakeholders

How would you plan headcount and a budget for next year?

What they check: linking people and money to the plan.

Short answer: "I start from what the business wants next year, what the teams can deliver now, and the gap. That gives a headcount ask with a reason for each role, plus tools, cloud costs and training. I show what we can do with less and what we would drop."

The full answer: Hiring takes months, so plan when people start, not only how many. Keep the span of control, the number of people reporting to one manager, sensible as teams grow; at around eight to ten it is time to add a lead or a manager.

A weak answer: "I ask for as many people as possible." Follow-up: "The budget is cut by a fifth." Say what goes first.

You take over a team with low trust and missed deadlines. What do you do in your first ninety days?

What they check: listening before acting, then a few clear changes.

Short answer: "The first weeks I listen: one-to-ones with everyone, the product manager and the main stakeholders, and I look at how work really flows. Then I pick two or three changes with the team, such as clearer priorities or smaller releases, and show early results."

The full answer: Trust comes back through kept promises, so make few and keep them. Be honest with stakeholders about a reset of dates. If one person is the cause, deal with it, but check the system first.

A weak answer: "I bring in my own process on day one." Follow-up: "Your best engineer resigns in week three." Say what you would do.

How do you work with stakeholders outside engineering, such as sales or leadership, when they push for a commitment you cannot make?

What they check: firm, friendly and with options.

Short answer: "I find out what they really need and by when, then offer what we can do: a smaller version, a later date or a trade against other work. I put the agreement in writing and keep them updated, so they trust the next answer too."

The full answer: Saying yes to everything breaks teams and trust. Build relationships before you need them, learn the business words of sales and finance, and bring the product manager into every such talk.

A weak answer: "I promise it and the team will find a way." Follow-up: "The deal is large and the CEO is in the room." Answer in two sentences.

Your CV for these questions

Each job on your CV invites the questions above: how many people, what you changed, what shipped and what you learned. Give those stories a line each, written so a director wants to hear more:

Check your CV against an engineering manager job you want with the free score; any area it finds thin is the one to rehearse first, with a story from your own work.