What makes a good engineering manager interview question?
A good question asks about something that already happened. "Tell me about the last time someone on your team was underperforming" produces evidence. "How would you handle an underperformer?" produces a speech, and every experienced candidate has the speech ready. Google's re:Work guide on structured interviewing draws the same line between behavioral questions, which ask about prior achievements, and hypothetical ones, and it recommends writing down what poor, borderline, solid and outstanding answers cover before you interview anyone.
The follow-ups matter more than the opening question. When a candidate says "we", ask what they did. When the story is clean, ask what went wrong. When they describe a decision, ask what they would do differently now. Most of the signal in a leadership interview comes from the second and third follow-up, after the rehearsed part runs out.
Use the same questions for every candidate for the same role, and score each answer before the debrief. Without that discipline, the loop measures how much the panel liked the person, which correlates with confidence and similarity far more than with management ability.
How is this different from a CTO or CAIO interview?
These questions are calibrated for line engineering managers and senior managers: people who run one to three teams and still sit close to the code. Executive interviews test different things. The CTO interview guide covers board presentations, strategy and executive negotiation, and the Chief AI Officer interview questions cover AI strategy and governance at the C-level. If you are hiring a director of engineering, use this page for the people and delivery sections and borrow the org-design questions from the CTO guide.
People leadership interview questions
This is the job. An engineering manager who cannot run a hard conversation, grow a senior engineer, or notice a problem on the team before it becomes a resignation is a project coordinator with direct reports.
-
Tell me about the last time someone on your team was underperforming. What did you do, week by week?
Strong answer: A timeline measured in weeks. The first conversation happened early, expectations were written down, the manager changed something on their side too (scope, pairing, clarity), and there was an outcome: the person recovered or left. They can say what they would do faster next time.
Weak answer: "I gave them feedback and they improved." No dates, no written expectations, or a story where the problem ran for two quarters before anyone said anything. Watch for handing the whole thing to HR.
-
How do you run 1:1s? What did your last three with one specific person cover?
Strong answer: The report owns the agenda. The topics vary: a blocker one week, career the next, feedback in both directions. They adjust the format per person and can name something they changed because of what came up.
Weak answer: The 1:1 is a status update. If the candidate's answer could be replaced by a standup, the 1:1 is not doing its job.
-
Who is the strongest engineer you have helped grow, and what did you specifically do?
Strong answer: Named actions: a stretch project, a decision they handed over and did not take back, sponsorship in a promotion discussion, feedback that stung and worked. Credit goes to the engineer, but the manager's moves are concrete.
Weak answer: "I hired great people and got out of the way." Sometimes true, never sufficient. Or the manager takes credit for talent the engineer already had.
-
Tell me about a conflict between two engineers that you had to step into.
Strong answer: They gave the engineers a chance to resolve it first, separated the technical question from the personal friction, set decision criteria, and followed up afterwards to check the relationship had recovered.
Weak answer: Sided with the more senior person by default, or waited until one of them escalated to a skip-level.
-
What does your team say about you when you are not in the room? How do you know?
Strong answer: A real source: skip-level notes, an engagement survey, a direct piece of critical feedback. Then what they changed because of it.
Weak answer: "They'd say I'm approachable." Self-assessment with no evidence and no criticism in it.
Delivery and execution interview questions
Every manager has a project that slipped. What separates candidates is the gap between when they knew and when they said so, and whether they cut scope or burned the team to hold a date.
-
Tell me about a project that slipped. When did you know, and when did you tell your stakeholders?
Strong answer: The gap between knowing and telling is days, not weeks. They brought options with the bad news: cut scope, move the date, add a specific person. They name their own part in the slip.
Weak answer: The stakeholders found out at the deadline. The cause is always another team, a vendor, or "changing requirements".
-
How do you decide what your team will not do this quarter?
Strong answer: An explicit trade-off, ideally one where they said no to someone senior and wrote down why. They treat descoping as a normal tool, not a failure.
Weak answer: "We prioritize together with product" and nothing ever gets dropped. A plan where everything fits is a plan nobody believes.
-
What do you look at every week to know if delivery is healthy, and which of those numbers has misled you?
Strong answer: A short list (PR age, cycle time, incident count, a gut check from standups) used to start conversations. They can describe a time a metric looked fine while the team was in trouble, or when a team gamed one.
Weak answer: Velocity or story points as a target. Or no numbers at all, which usually means the manager finds out about problems from their boss.
-
Walk me through your last postmortem that actually changed something.
Strong answer: Blameless in practice, not just in the template. One action item that shipped and the incident class that stopped recurring.
Weak answer: A postmortem document that nobody read, or a story that ends with "and we reminded people to be more careful".
-
Half your roadmap changed mid-quarter. How do you replan without losing the team?
Strong answer: They separate what is committed from what was hoped for, re-plan with the team rather than at them, and say out loud what work is being thrown away and why.
Weak answer: Absorbs every change silently. The team learns that plans mean nothing.
Technical judgment interview questions
Managers do not need to be the best engineer on the team. They need to be technical enough to smell a bad estimate, ask the question the tech lead skipped, and weigh debt against features without deferring every call.
-
Tell me about a technical decision your team made that you disagreed with. What did you do?
Strong answer: They said so, with reasons, and then either committed to the team's call or escalated with clear criteria. They can say how it turned out and whether they were right.
Weak answer: Overrode the team because they are the manager, or never disagrees with anything technical.
-
Draw the system your team owns. Where is its biggest liability?
Strong answer: They can sketch it in five minutes and name the part that keeps them up at night, with the cost it imposes (incidents, slow changes, a single person who understands it).
Weak answer: "My tech lead knows the details." Fine for a director of 60, a warning for a manager of eight.
-
How do you decide when to pay down technical debt versus ship features?
Strong answer: Debt is tied to a measured cost: lead time on a module, incident rate, onboarding time. The budget is negotiated with product using that cost, not asserted as a fixed percentage.
Weak answer: "We always reserve 20%" with no reason, or "we never have time for it".
-
When did you last read or review code, and why that one?
Strong answer: A deliberate reason: staying calibrated on estimates, onboarding into a new area, checking a risky change. They are not the bottleneck on merges.
Weak answer: Either "years ago" or "I review every PR". Both are problems.
AI-era leadership interview questions
This category did not exist in most loops three years ago. Every engineering team now uses AI coding tools in some form, and the manager decides whether that shows up as faster delivery or as larger pull requests nobody fully reviewed.
-
How has AI tooling changed how your team works, and how did you measure it?
Strong answer: Specific workflow changes (who uses which tool for what) and a measurement beyond adoption: review time, change failure rate, PR size. They name a downside they saw and what they did about it.
Weak answer: "Everyone uses Copilot and we're 30% faster." A number with no method behind it.
-
An AI-generated change causes a production incident. Who is accountable?
Strong answer: The engineer who merged it and the reviewer who approved it, with a named owner for the follow-up. Then the process change: risk tiers, extra human review on high-risk paths, smaller changes.
Weak answer: "The tool made a mistake." Or a vague answer about shared responsibility where nobody owns anything.
-
How do you review AI-assisted pull requests differently, if at all?
Strong answer: Size limits, the intent of the change written in the PR description, tests as a requirement, and a human on anything touching money, auth or data. If they use AI reviewers, they rank findings by severity so engineers are not buried in low-value comments.
Weak answer: No difference at all, or "the AI reviewer checks the AI's code" with nobody accountable at the end.
-
How are you growing junior engineers when agents now write the code they used to learn on?
Strong answer: Deliberate practice: juniors explain every diff they submit, pair on debugging, own small systems end to end. They see the risk of engineers who can prompt but cannot reason about failure.
Weak answer: "We only hire seniors now." That works until the seniors leave and nobody is ready to replace them.
Hiring and firing interview questions
The manager's hiring and firing decisions outlast almost everything else they do. A candidate who has never made a bad hire has not hired much, and one who cannot describe a dismissal with care will handle yours badly.
-
Tell me about a hire you got wrong. What signal did you miss?
Strong answer: They name the signal (a reference they skimmed, a weak answer they explained away) and the change they made to their loop afterwards.
Weak answer: "I've never made a bad hire." Or the hire was wrong because the person changed after joining.
-
Walk me through the last time you let someone go.
Strong answer: A documented process, a conversation handled with dignity, and attention to the team afterwards: what they told the others and how they handled the workload gap.
Weak answer: Cold and procedural, or an experienced manager who has never done it and avoided the decision when it was needed.
-
How would you design an interview loop for a senior engineer today?
Strong answer: Structured questions, a written rubric, and a technical exercise that holds up when candidates have AI assistants, such as defending code they wrote live or walking through a past system in depth.
Weak answer: LeetCode plus "culture fit". No rubric, so the decision comes down to whoever argued loudest in the debrief.
-
Your best engineer tells you they have a competing offer. What do you do?
Strong answer: They usually knew it was coming because career conversations happened earlier. They will advocate for a counter where it is deserved and will not match blindly.
Weak answer: Surprised, then immediately offers to match whatever number was quoted.
Stakeholder management interview questions
Engineering managers spend a large share of their week outside the team: with product, design, other managers, and their own boss. Candidates who only talk about their team in this section are telling you something.
-
Tell me about a time product and engineering disagreed on scope. How did it resolve?
Strong answer: Options with costs attached, an agreed outcome both sides cared about, escalation only after those steps. The relationship survived.
Weak answer: "Engineering won." Or product always wins and the team pays for it in weekends.
-
How do you explain a two-week delay to a non-technical executive?
Strong answer: Business impact first, a new date with an honest confidence level, and what they need from the executive, if anything. Two minutes.
Weak answer: A tour of the technical problem. The executive leaves knowing about the database and nothing about the launch.
-
Your VP asks for a delivery date on something nobody has scoped. What do you say?
Strong answer: A range, what would narrow it, and a date by which they will have a real date. They do not invent a number to make the meeting end.
Weak answer: Gives a confident single date on the spot, or refuses to estimate at all.
-
Which peer or partner have you had the hardest working relationship with, and what did you do about it?
Strong answer: They own part of the problem and describe a specific repair: a recurring meeting, a shared doc, a direct conversation.
Weak answer: The other person was difficult and that is the whole story.
How should you score engineering manager interview answers?
Score every answer from 1 to 4 against written anchors, independently, before anyone speaks in the debrief. A four-point scale has no middle option, so interviewers have to commit to a direction. The general anchors:
| Score | What the answer contains |
|---|---|
| 4: Strong hire | A specific past situation, the candidate's own actions in "I" language, the trade-offs they weighed, the outcome, and what they changed afterwards. Holds up under two or three follow-ups. |
| 3: Hire | A specific situation and clear personal ownership, with less depth on alternatives or lessons. Follow-ups add detail rather than exposing gaps. |
| 2: Lean no | Generic or hypothetical. Mostly "we". Needed heavy prompting to reach anything concrete, or the outcome is unclear. |
| 1: No hire | No real example, blame placed entirely on others, or an approach that conflicts with how you want people managed. |
Then apply competency-specific anchors so "strong" means the same thing to every interviewer:
| Competency | A 4 looks like | A 1 looks like |
|---|---|---|
| People leadership | Acts early on performance issues, grows people through concrete moves, has evidence of how the team sees them | Avoids hard conversations or delegates them to HR; 1:1s are status meetings |
| Delivery | Short gap between knowing and telling; descopes deliberately; metrics start conversations | Surprises stakeholders; blames dependencies; uses velocity as a target |
| Technical judgment | Can draw the system and name its liability; ties debt to measured cost; disagrees with reasons | Defers every technical question, or overrides the team by rank |
| AI-era leadership | Measured AI's effect beyond adoption; names who owns AI-generated code; has a plan for juniors | Unmeasured productivity claims; treats the tool as accountable |
| Hiring and firing | Learns from bad hires; runs exits with process and care; designs structured loops | Claims no bad hires; has avoided a needed exit; hires on gut feel |
| Stakeholders | Brings options with costs; explains delays in business terms; gives honest ranges | Wins arguments at the relationship's expense; invents dates to end meetings |
A practical hiring bar: no 1s anywhere, at least a 3 on people leadership, and an average of 3 or better across the loop. Adjust the weighting to the role. A manager inheriting a team in trouble needs a higher people score; a manager joining a team about to rebuild its platform needs more technical depth.
How do you split these questions across an interview loop?
Give each interviewer two competencies so nobody re-asks the same question and every competency gets real depth. One split that works for a four-interview loop:
| Interviewer | Competencies | Why them |
|---|---|---|
| Hiring manager (director or VP) | People leadership, hiring and firing | They will manage this person and own the decision |
| Peer engineering manager | Delivery, stakeholder management | They know what the job looks like day to day and will work alongside the hire |
| Staff or principal engineer | Technical judgment, AI-era leadership | The team will judge the manager's technical credibility through people like them |
| Product or design partner | Stakeholder management (second pass) | The hardest stakeholder relationship for most EMs, tested by someone on the other side of it |
If the role involves hiring a team quickly, add an exercise where the candidate reviews a real (anonymized) interview packet and makes a hire or no-hire call. It shows how they weigh evidence better than any question about hiring philosophy. For the technical rounds you run for the engineers this manager will later hire, see AI-resistant interview design.
What should candidates prepare?
If you are on the other side of the table, prepare eight to ten stories rather than answers: an underperformer, a slip, a conflict, a bad hire, an exit, a technical disagreement, an AI change you led, a hard stakeholder. For each, know the dates, what you did, what it cost, and what you would change. Most of the questions above can be answered from that set. Check the engineering manager salary benchmarks before the offer stage, and if you are moving up, the CTO interview guide covers the next level.
Related Guides
CTO Interview Guide
Questions, board presentation prep and negotiation for technology executive roles.
Chief AI Officer Interview Questions
What to ask, and what to listen for, when hiring an AI executive.
Feedback Examples for Software Engineers
A phrase bank for reviews and 1:1s, plus how to deliver feedback without defensiveness.
Signs Your Engineering Team Is Failing
The quiet signals and a diagnostic table of causes and first moves.
Workforce AI Readiness (aistrategy.guide)
How to assess whether teams are ready to work with AI, beyond tool adoption.
Sources
- Google re:Work, A guide to structured interviewing for better hiring practices: behavioral vs hypothetical questions; rubrics with poor, borderline, solid and outstanding answers.
- Will Larson, Irrational Exuberance: writing on engineering management and organization design.
- Camille Fournier, The Manager's Path (O'Reilly, 2017): the engineering management career ladder from tech lead to CTO.