Interview guide for engineering managers: a loop for delivery, technical judgment and running a team on call

An engineering manager does the work of a people manager and then some: they are accountable for shipping software whose estimates are uncertain, for the health of systems their team runs, for when to pay down technical debt, and for hiring engineers in a competitive market. A loop that only asks general leadership questions misses most of that, and a loop that runs the candidate through the individual contributor coding interview tests the wrong job. This guide gives hiring managers a full loop for a first-line engineering manager of five to ten engineers: five stages, who owns which competency, core questions with what to listen for, two engineering-specific work samples, example weights and the debrief decision rule.

The general craft of managing people (one-to-ones, performance conversations, promotion requests) is covered in the interview guide for people managers, including a review-writing task and a one-to-one role-play. This page does not repeat those. It covers what is specific to managing engineers, and points to the people manager loop for the rest.

The loop at a glance

For the stage-design logic, including how to give each interviewer only the competencies they own, see the interview process template.

Stage 1: the screen (30 minutes)

• "How many engineers report to you, at what levels, and what does the team own in production?" Listen for: direct reports versus a team they lead technically, and real operational ownership such as services with on-call.
• "How much of your week is hands-on technical work now, and how much would you like it to be?" Listen for: a fit with your expectation. A candidate who wants to code half the time will be frustrated in a role that needs none.

Stage 2: hiring manager interview (60 minutes)

The director owns the engineering-specific side of people management and hiring.

1. "Tell me about an engineer whose performance you had to address. How did you know it was a performance problem and not a project, tooling or clarity problem?" Listen for: separating the person from the environment, evidence from code reviews, delivery and peers, and a clear expectation with a date. Waiting for a review cycle is a warning sign.
2. "Walk me through how you hired the last engineer on your team, from writing the role to the decision." Listen for: criteria agreed before interviewing, a realistic work sample, calibrated interviewers and a closing plan. The software engineer loop you would expect them to run is in the interview guide for software engineers.
3. "Tell me about a strong senior engineer who wanted to become a manager, or a manager who wanted to go back. What did you do?" Listen for: knowing both career paths, a trial of real management work, and honest conversations either way.

Stage 3: technical depth (60 minutes)

A staff or senior engineer runs a conversation, not a coding test. The aim is to see whether engineers would trust this person's technical judgment, not whether they could pass the team's coding loop today.

• "Draw the main system your team owns. Where does it break, and what did you decide to do about it?" Listen for: accurate detail at the level of services, data flows and failure modes; a decision they influenced; and the trade-off it involved.
• "Tell me about a technical decision your team made that you disagreed with. What did you do?" Listen for: letting the team own decisions inside agreed limits, intervening when risk was high, and saying how they decided which was which.
• "How did you decide how much time to spend on technical debt last quarter?" Listen for: debt tied to a cost the business feels (incidents, slower delivery, on-call load), a negotiated share of capacity, and evidence it paid off. "We take 20% for debt" with no reason scores low.

If the interviewer is more senior technically than the candidate, or the reverse, the guidance in how to interview candidates more senior than you applies.

Stage 4: the work samples (75 minutes)

Send both briefs 24 hours in advance so the candidate can read them; all discussion happens live.

Part 1: quarter planning (40 minutes)

The brief contains an invented team of seven engineers, a product roadmap with five items the product manager calls "committed", rough estimates that add up to about 140% of capacity, an on-call log showing two engineers paged most nights, and a note that one engineer is going on leave for six weeks.

The candidate presents a plan to the hiring manager and a product manager, then the product manager pushes back: "Sales has promised item four to a customer." Listen for: capacity adjusted for leave, on-call and meetings; work to reduce the paging included as a real item; a clear proposal for what moves out, with the product manager rather than against them; and an honest answer about the customer promise instead of overcommitting the team.

Part 2: postmortem review (35 minutes)

The candidate reads a one-page draft postmortem "written by a mid-level engineer on your team" after a 45-minute outage. It has three problems: the summary names a colleague as the cause, the timeline skips the 20 minutes before anyone was paged, and the action items have no owners or dates.

The hiring manager then plays the author. Listen for: feedback that keeps the review blameless and moves from the person to the system; a question about the missing 20 minutes, which is often the most useful finding; action items made specific; and a tone that leaves the engineer willing to write the next one.

Stage 5: team conversation (30 minutes)

Two engineers ask two agreed questions and score them like any other interviewer.

• "How would you handle it if on-call was burning out two people on the team?" Listen for: measuring the load, sharing it more widely, fixing the noisiest alerts, and protecting time to do so.
• "How do you decide what to say in code review as a manager?" Listen for: awareness that a manager's comment carries extra weight, and leaving most technical review to engineers.

Scorecard competencies and weights

Example weights for a first-line engineering manager. Set yours at intake and lock them before the first candidate.

The scorecard builder checks that weights add up to 100 and prints a sheet per interviewer.

The debrief decision rule

1. Scorecards first, including the two engineers', before the debrief.
2. Gate: delivery planning at 3 or above, and performance management at 3 or above for experienced managers (2 for a first-time manager with a strong postmortem review).
3. Floor: no 1 on technical judgment. A manager engineers do not trust technically will struggle to make trade-offs stick.
4. Weighted total: in this example, 2.8 or higher on the 1–4 scale goes to references, including at least one former direct report.
5. The product manager's view on partnership carries weight; they will spend the most time negotiating scope with this person.

Adjusting by level

Common mistakes in engineering manager loops

• Running the individual contributor coding loop. It filters out strong managers who have not practiced puzzles recently and tells you little about management.
• Only generic leadership questions. Ask about on-call, estimates and technical debt; that is where engineering management goes wrong.
• No product manager in the loop. Delivery trade-offs are negotiated with product every week.
• Hiring the best engineer on the panel. Technical strength helps credibility but does not show whether they will develop the team.

After the offer, the 30-60-90 day plan for engineering managers sets out the first three months.