Interview questions / Engineering manager

Engineering manager interview questions - and what they are really asking

Strong answers show management judgment: how you grow engineers, keep delivery honest, stay technical enough to be useful, and own the calls your team did not make.

33 questions6 question areasIntent + answer approach

Most engineering manager interviews pull from six areas: people management and coaching, delivery and execution, technical judgment, hiring and team building, cross-functional work, and behavioral leadership. The bar for experienced candidates is judgment, not vocabulary. Interviewers are trying to work out what you personally decided, what you changed structurally, and what happened to the team afterwards. Use the questions below to map each area to a team you have actually run.

Use this for almost every answer

Separate the situation from your call, and end with what changed

A strong engineering manager answer makes your own decision visible, not just the team's outcome. Use this structure for people scenarios, delivery cases, and behavioral stories alike.

Context
Set the team size, the stage it was at, and the constraint you were working under.
Your call
State the decision you owned, clearly separated from what your engineers decided.
How you did it
Show the conversation, the sequencing, or the mechanism you used, not just the intent.
People impact
Say what it meant for the person or the team, including what was uncomfortable about it.
Result
Close with what changed in delivery, retention, or quality, and what you would do differently.

The same answer should change with the interviewer

Recruiter / HR

Credible and clear

Give team size, what the team owned, how long you managed it, and the outcome in plain language. Lead with scope and results rather than frameworks or tooling.

Hiring manager (director or VP)

Management judgment

Show how you make calls under pressure, where you push back, and what you escalate. They are hiring someone they will not need to supervise closely, so make your independent judgment visible.

Peer and team panel

What you are like to work for

Engineers and partner managers are assessing whether you are honest about trade-offs, generous with credit, and specific about how you support people. Vague warmth reads worse than a concrete example.

People management and coaching

Questions about growing, supporting, and correcting engineers

This is the core of the role and usually the round that decides the outcome. Interviewers want evidence that you handle hard conversations early, coach rather than rescue, and can describe a specific person you helped without turning it into a slogan.

“How do you handle an engineer who is underperforming?”

What they are trying to understand: Do you diagnose the cause before acting, and are you willing to have the hard conversation early?
How to approach your answer: Separate skill, clarity, motivation, and environment as causes, because the fix differs for each. Describe how you named the gap directly, agreed what good looks like with a timeframe, supported it, and were honest about the consequence if it did not move.

Avoid: Jumping straight to a performance plan, or a story where you were patient for months and never actually told the person.

“How do you run one-on-ones, and what do you use them for?”

What they are trying to understand: Is your management routine deliberate, or is it a status meeting with a different name?
How to approach your answer: Say who owns the agenda, how often you meet, and what you deliberately keep out of it. Explain how you use the time for growth, blockers, and feedback in both directions, and give one thing you learned in a one-on-one that changed a decision.

Avoid: Describing a weekly project update, or claiming you keep it informal with no structure at all.

“How do you grow an engineer to the next level?”

What they are trying to understand: Can you turn a promotion conversation into concrete work, or do you rely on time served?
How to approach your answer: Start from the gap between what the person does now and what the next level expects, then find real work that closes it rather than training. Explain how you made the expectations visible, gave the person scope with room to fail safely, and built the evidence a promotion committee needs.

Avoid: Promising a promotion you do not control, or coaching that never touches the work itself.

“One of your strongest engineers tells you they are leaving. What do you do?”

What they are trying to understand: Do you handle retention honestly, and do you protect the team from single-person risk?
How to approach your answer: Understand the real reason before reacting, and be clear about what you can and cannot change. Cover the handover and knowledge risk, keep the relationship intact either way, and say what you would look at across the rest of the team afterwards.

Avoid: A counter-offer as the first move, or treating the resignation as a surprise with nothing to learn from.

“How do you give critical feedback to someone who disagrees with it?”

What they are trying to understand: Can you hold a position under pushback without either caving or steamrolling?
How to approach your answer: Anchor the feedback in observed behavior and its effect, not personality. Show that you genuinely test whether their objection contains something you missed, then restate the expectation plainly and agree what changes.

Avoid: Softening the message until it disappears, or repeating the same point louder because you are the manager.

“How do you decide who works on what?”

What they are trying to understand: Do you balance delivery speed against growth, or always assign work to whoever is fastest?
How to approach your answer: Explain the trade-off between the safe assignment and the stretch assignment, and how you weigh it against deadline risk. Describe how you spread the unglamorous work and how you avoid one person becoming the only owner of a critical system.

Avoid: Always giving critical work to the strongest engineer, or rotating work with no regard for risk.

Delivery and execution

Questions about shipping predictably and handling it when you cannot

These questions test whether your team ships without you personally carrying it. Interviewers look for early honesty about slippage, a real view of quality against speed, and mechanisms rather than heroics.

“How do you know whether your team is delivering well?”

What they are trying to understand: Do you measure outcomes, or do you rely on how busy the team feels?
How to approach your answer: Name a small set of signals you actually watched, such as predictability against commitments, cycle time, incident or defect rates, and what the team is able to take on next. Say which signal you trusted least and why.

Avoid: Reciting a dashboard of metrics you never acted on, or measuring individual output like commits.

“Your team is going to miss a committed deadline. What do you do?”

What they are trying to understand: How early do you raise it, and do you bring options rather than an apology?
How to approach your answer: Confirm the size of the gap and the cause, then surface it as soon as you believe it rather than at the deadline. Bring the levers you have, such as cutting scope, phasing the release, or moving the date, and recommend one with the trade-off stated.

Avoid: Reporting green until the last week, or asking the team to absorb it with overtime as the first response.

“How do you balance feature work against technical debt and reliability?”

What they are trying to understand: Can you argue for engineering health in business terms, or do you frame it as a quality of life request?
How to approach your answer: Tie the debt to something the business feels, such as slowing delivery, incident load, or onboarding time. Describe the allocation you negotiated and how you kept it from being the first thing dropped under pressure.

Avoid: A fixed percentage with no justification, or letting debt work happen only when someone has spare time.

“Your team consistently underestimates. How do you fix that?”

What they are trying to understand: Do you address the system producing bad estimates, or push the team to try harder?
How to approach your answer: Look for the pattern first: missing work like review and testing, optimism about dependencies, or pressure to give the answer leadership wants. Describe the change you made, such as estimating in ranges, sizing against completed work, or separating the estimate from the commitment.

Avoid: Adding a silent buffer, or telling the team to be more careful without changing anything.

“Walk me through how you would run a project from kickoff to launch.”

What they are trying to understand: Is there a repeatable spine to how you deliver, and do you know where it usually breaks?
How to approach your answer: Cover how you agree the goal and success criteria, break the work down with the team, surface dependencies early, and set a cadence for tracking. Say where you expect the risk to sit and what you would check on before it becomes a problem.

Avoid: Describing a ceremony calendar, or a plan that assumes nothing changes after kickoff.

“How do you handle a production incident?”

What they are trying to understand: Do you know your role during an incident, and does the follow-up actually change anything?
How to approach your answer: Split the response from the prevention: during the incident you clear the path, manage communication, and protect the people fixing it rather than debug over their shoulder. Afterwards, run a blameless review and make sure the actions get scheduled like real work.

Avoid: Taking over the keyboard, hunting for who caused it, or a review whose actions are never picked up.

Technical judgment

Questions about staying technical enough to be useful

Interviewers are calibrating how much technical weight you can carry. The bar is not writing production code daily. It is whether you can judge a design, ask the question that exposes a weak assumption, and know when to defer to your engineers.

“How technical are you, and how do you stay technical as a manager?”

What they are trying to understand: Is your answer honest and specific about the level you operate at now?
How to approach your answer: State plainly what you can still do and what you have let go, then give the concrete habits that keep you current, such as reading designs, reviewing code occasionally, or joining incident calls. Frame the goal as being able to ask the right question, not to out-code the team.

Avoid: Claiming you are as strong as your engineers, or the opposite, that a manager does not need depth at all.

“When would you overrule a technical decision your team has made?”

What they are trying to understand: Do you know where your authority genuinely applies, and do you use it sparingly?
How to approach your answer: Draw the line clearly: you weigh in on cost, risk, timeline, and anything crossing team boundaries, and you defer on implementation. Give an example where you did overrule and explain how you kept the team's ownership intact afterwards.

Avoid: Saying you never override, which reads as absent, or describing yourself as the final technical authority by default.

“How do you evaluate whether a design or architecture proposal is sound?”

What they are trying to understand: Can you reason about a system you did not design?
How to approach your answer: Work from the requirements and constraints, then probe the failure modes, the operational cost, the migration path, and what happens at ten times the load. Say which alternatives were considered and why they were dropped, since that reveals whether the thinking was real.

Avoid: Approving on the strength of who wrote it, or reviewing only the parts you already understand.

“How do you decide between rewriting a system and improving it incrementally?”

What they are trying to understand: Do you resist the rewrite instinct and think in terms of risk and payback?
How to approach your answer: Default to incremental change and make the rewrite argue for itself. Compare the cost of the migration and the frozen feature work against the ongoing cost of the current system, and describe how you would carve it up so value lands before the end.

Avoid: Backing a full rewrite because the code is unpleasant, or refusing on principle.

“Two engineers disagree on a technical approach and it is blocking work. What do you do?”

What they are trying to understand: Can you unblock without either picking a favorite or letting the debate run?
How to approach your answer: Make sure both sides are arguing about the same problem and criteria first, because most of these are unstated assumptions. Set a decision point, use a spike or a trial where the cost is low, and if it still deadlocks, make the call and say what it was based on.

Avoid: Letting it drift toward whoever is more senior, or deciding by seniority to end the discussion.

“How do you keep code quality high without becoming a bottleneck?”

What they are trying to understand: Do you build standards into the system, or rely on your own review?
How to approach your answer: Push quality into things that scale, such as agreed standards, automated checks, review norms, and a definition of done the team owns. Explain how you spot-check rather than gate, and how you handle a persistent quality problem with a specific person.

Avoid: Reviewing every pull request yourself, or treating quality as purely the team's problem.

Hiring and team building

Questions about building the team you will manage

Hiring is one of the few things a manager cannot delegate. Interviewers want to see a deliberate bar, a real view of what your team is missing, and evidence that you can turn a group of individuals into something that works.

“How do you hire engineers, and what do you screen for?”

What they are trying to understand: Is there a defined bar, or do you hire on impression?
How to approach your answer: Describe the signals you screen for and how each round tests something different. Explain how you keep the bar consistent across interviewers and how you handle a candidate who is strong technically but a risk on collaboration.

Avoid: Culture fit as the deciding factor with no definition, or a process where every round asks the same thing.

“How would you build a team from zero?”

What they are trying to understand: Do you sequence hiring against the work, or fill headcount in order?
How to approach your answer: Start from what the team has to deliver in the first year, then hire the shape that unblocks it, usually experienced people who can set patterns before you add volume. Cover how you would keep the first hires productive while you are still recruiting.

Avoid: Hiring to a headcount number, or filling all levels at once with no dependency on the work.

“How do you onboard a new engineer?”

What they are trying to understand: Is onboarding designed, or does it depend on who happens to be free?
How to approach your answer: Give the shape of the first weeks: an owner, a small piece of real work early, and clear expectations for what thirty and ninety days look like. Say how you check whether it is working rather than assuming it is.

Avoid: Handing over documentation and a laptop, or a first task so trivial it teaches nothing.

“You inherit a team with low morale. What do you do in your first 90 days?”

What they are trying to understand: Do you diagnose before acting, and can you find the difference between symptom and cause?
How to approach your answer: Spend the early weeks listening across the team and its partners, and look at delivery history rather than only opinions. Fix one visible thing early to build credibility, then work the structural cause, and be clear about what you found versus what you assumed.

Avoid: Arriving with a reorganization, or spending ninety days observing with nothing to show for it.

“How do you think about team structure and team size?”

What they are trying to understand: Can you connect team shape to ownership and delivery speed?
How to approach your answer: Tie structure to what the team owns end to end and how many dependencies it has to cross to ship. Explain the size range you find workable and what you would do with a team that has grown past it.

Avoid: Quoting a team size rule with no reasoning, or ignoring ownership boundaries entirely.

Cross-functional and stakeholder work

Questions about working across product, peers, and leadership

An engineering manager spends much of the week outside their own team. These questions test whether you can hold a position with product and leadership without either blocking the business or leaving your team exposed.

“How do you work with your product manager?”

What they are trying to understand: Do you own the how while genuinely engaging with the what?
How to approach your answer: Describe the split you operate with and where you deliberately overlap, such as feasibility early and sequencing during delivery. Give an example where you changed the plan because of a technical constraint and how you made that case.

Avoid: Framing product as the source of requirements you receive, or claiming there is never any friction.

“A stakeholder is going directly to your engineers with requests. What do you do?”

What they are trying to understand: Can you protect focus without making yourself a gatekeeper the business resents?
How to approach your answer: Assume the stakeholder has a real need and a broken path first, then agree a route that works for them. Set the expectation with your engineers about what they can absorb and what they should redirect, and follow up on whether the volume actually drops.

Avoid: Making it a territory issue, or telling your engineers to say no with no alternative offered.

“How do you say no to a request from leadership?”

What they are trying to understand: Can you push back with evidence and options rather than resistance?
How to approach your answer: Show the trade-off in terms of what would have to move, and offer a smaller version or a later date rather than a flat refusal. Be clear that once the decision is made you commit to it and represent it to your team honestly.

Avoid: Accepting everything and letting the team absorb it, or refusing without offering an alternative.

“How do you explain a technical trade-off to a non-technical audience?”

What they are trying to understand: Can you translate without either oversimplifying or hiding behind detail?
How to approach your answer: Lead with the decision and its business consequence, then give only the technical detail that supports the choice. Offer the options with cost and risk attached so the audience can weigh them rather than take your word for it.

Avoid: Explaining the implementation first, or reducing it to a claim that it is simply too complex.

“A peer manager's team keeps blocking yours. How do you handle it?”

What they are trying to understand: Do you solve it at your level before escalating?
How to approach your answer: Go direct first, agree what each side is actually committed to and by when, and look for a way to reduce the dependency rather than only chase it. Escalate with a specific ask and a proposed fix if it stays unresolved, and say what you would concede.

Avoid: Escalating first, or absorbing the delay silently and letting your own commitments slip.

Behavioral and leadership

Questions about your track record and how you lead

The behavioral round is where interviewers check that the judgment you have described is backed by things that actually happened. Pick examples where you were the decision maker and where something was genuinely at stake.

“Tell me about a decision you made that your team disagreed with.”

What they are trying to understand: Will you make an unpopular call, and do you bring people with you afterwards?
How to approach your answer: Explain what the disagreement was really about and how you tested whether the team was right. State the call, how you communicated the reasoning, and what you did to keep the team committed once it was made.

Avoid: A decision with no real cost, or a story where you decided and never revisited the outcome.

“Tell me about the hardest people situation you have handled.”

What they are trying to understand: Do you go near genuine difficulty, and did you act rather than wait it out?
How to approach your answer: Pick something real, such as a dismissal, a conflict between two strong engineers, or a trusted person behaving badly. Show the sequence of what you tried, what you decided, and be honest about the part you handled poorly.

Avoid: A mild disagreement dressed up as a crisis, or a story where the problem resolved itself.

“Tell me about a project that failed and what you did about it.”

What they are trying to understand: Can you own a failure without deflecting it onto circumstances or other teams?
How to approach your answer: State what the goal was and what actually happened without softening it. Identify the decision you would make differently, and describe what you changed afterwards so the same failure was less likely.

Avoid: A failure caused entirely by others, or a lesson so general it applies to any project.

“What kind of manager are you, and how would your team describe you?”

What they are trying to understand: Is your self-description specific and consistent with the rest of your answers?
How to approach your answer: Give two or three concrete traits that show up in your other examples, and name a real trade-off in your style along with how you compensate for it. Point to feedback you have actually received rather than how you hope you come across.

Avoid: A description with no downside, or claiming to adapt your style perfectly to every individual.

“Why do you want to be a manager, and why this role now?”

What they are trying to understand: Is your motivation durable, and does it match what this specific role offers?
How to approach your answer: Be honest about what you get from the work now that you are not the one shipping the code. Connect it to what you want to own next, and name one specific thing about this team, product, or stage that offers it.

Avoid: Management as the natural next step after being a strong engineer, or generic interest in helping people grow.

Put the questions to work

Walk in with evidence behind every management decision

Build answers from the teams you have actually run, rehearse the people scenarios that decide the outcome, and keep every claim grounded in something you can defend under follow-up questions.

Start your interview prep See how interview prep works