Engineering manager interview questions

As asked

Tell me about a time you had to performance-manage a struggling senior engineer. Walk through what you did and what came of it.

Sample answer outline

Pick a real story. Cover: how you spotted the gap (and how long it took, sometimes too long), how you raised it in 1:1s with concrete evidence (not feelings), the formal performance improvement plan if it got there, the support you offered (mentorship, scope changes, coaching), and the outcome (the engineer turned it around, or they left, or you had to let them go). The strong answer takes ownership: were the expectations clear, did you give feedback early enough, did the team set them up to fail. Avoid blaming the engineer.

Expect these follow-ups

• What is the soonest you would consider a PIP?
• How do you keep this from infecting team morale?
• What did you learn about your own hiring or onboarding from this?

As asked

Design the interview loop for a senior backend engineer at your company. What stages, what each one tests, and what your bar is.

Sample answer outline

Stages: recruiter screen (basic fit, comp expectations), hiring manager call (motivation, scope handled, communication), technical screen (one focused coding or design discussion, signal not breadth), onsite loop (system design, coding, behavioural, cross-functional). Each stage should test something the next stages cannot. Calibrate the bar: write down what 'meets the bar' means for each interview and have a panel calibration session. Train interviewers. Run a debrief that surfaces disagreement, not consensus. Track conversion rates and time-to-hire by source to catch funnel problems.

Expect these follow-ups

• How do you reduce false negatives in a hiring loop?
• What is your strategy for unconscious bias in debriefs?
• How would you change this loop for a remote-only company?

As asked

Your team has just been reorged. Half are new to you, half lost their previous manager. Morale is shaky. What do you do in the first 60 days?

Sample answer outline

Week 1: 1:1s with everyone, listening mode only. No big decisions, no promises. Ask each person what they want to keep, what they want to change, and what they are worried about. Week 2 to 4: synthesise themes, share back what you heard with the team (without naming sources), and pick one or two visible quick wins that address shared concerns. Be honest about what is in your control and what is not. By week 8, you should have a clearer team charter, a sense of where individuals want to grow, and trust in your judgement on a few decisions. Skip the rah-rah, do the work.

Expect these follow-ups

• What if two of your most senior people are flight risks?
• How do you tell when the team has actually stabilised vs just gone quiet?
• What if you disagree with the reorg itself?

As asked

Tell me about a time you let someone go. Walk me through how you got there and how you handled the conversation.

Sample answer outline

Pick a real example. Cover the lead-up: clear feedback, a documented PIP with achievable goals, ongoing 1:1 support, the check-in cadence. Show that the outcome was not a surprise to the engineer at any point. Walk through the conversation: held with HR present, short, clear, dignified, no rehashing of failures. Talk about what you did for the rest of the team after: honest communication without disparaging the person, support for anyone shaken by it. The strong answer reflects on what you could have done differently earlier in the cycle.

Expect these follow-ups

• What part of the process do you think failed?
• How did you tell the team?
• What did you put in place to make the next case earlier?

As asked

Your team has a heavy product roadmap and an unsustainable on-call load. The VP wants both delivered. How do you handle it?

Sample answer outline

Make the tradeoff visible with numbers, not feelings. Cost the on-call load: pages per week, hours spent, engineer satisfaction, attrition risk. Cost the roadmap: what features for what business outcomes. Propose an explicit reallocation: a fixed percentage of capacity dedicated to reliability work this quarter, with the roadmap items prioritised inside the remaining capacity. Get the VP to sign off on which features slip, not just on the math in the abstract. Track both reliability KPIs and roadmap progress in the same forum so the trade does not get reversed silently.

Expect these follow-ups

• What if the VP insists on 100 percent roadmap and ignores the reliability data?
• How do you measure when the on-call load is fixed?
• How do you handle a star engineer who wants to do only feature work?

As asked

Walk me through how you would prepare a strong mid-level engineer for a promotion to senior. What does the case look like and how do you build it?

Sample answer outline

Start from the senior rubric at your company. Identify the specific gaps between where they are and the rubric, in writing, in a 1:1. Scope projects deliberately to give them the experience they lack: leading a cross-team effort, mentoring a junior, owning a system end to end, making a technical call that gets reviewed by peers. Document outcomes as they go. At the promotion review, the case writes itself: specific projects, specific impacts, specific peer testimony. Never promote on tenure; promote on demonstrated scope at the next level.

Expect these follow-ups

• What is the difference between a strong senior and a mid acting up?
• How do you handle the case where they want the promotion but are not ready?
• How do you measure mentorship of juniors as part of the case?