Engineering manager interview questions and how to answer them
Engineering manager interviews test how you build and run a team, not how you code: how you hire, how you handle someone who is struggling, how you trade technical debt against features and how you grow senior engineers. Answer each with one real person or decision, say what you did week by week, and end with the outcome for the team.
What these interviews are really checking
Most engineering manager loops have a people round, an execution round, a system or architecture conversation and a round with a product or design partner. The people and execution rounds decide most offers. The interviewers are asking one thing underneath every question: would engineers want to work for you, and would the team ship?
Answers that stay at the level of philosophy ("I believe in psychological safety") don't land. Answers about a specific engineer, a specific sprint and a specific trade-off do.
Hiring
You'll be asked how you hire, and often about a hire that went wrong. For the process, walk through it in order and say what each step tests:
- Write the role from the team's gap, not a generic template. "We needed someone who could own on-call for the payments service."
- Screen for the gap. A short call about a past system they owned.
- Structured interviews with the same questions and a scoring guide for each candidate.
- Debrief with evidence, not "I liked them".
- Close personally. You call the candidate and say why this team, specifically.
For the hire that didn't work, own your part: what signal you missed in the loop and what you changed in it.
A low performer
This is the question most candidates rush. Slow down and give the timeline.
Example answer (made-up details):
"A mid-level engineer on my team had missed three sprint commitments in a row and his code reviews had gone quiet. In our one-on-one I named what I'd seen, without guessing why, and asked what was going on. He'd been moved onto a service he didn't understand and was embarrassed to ask. We agreed on a pairing plan with the service's original author for two weeks and smaller tickets with clear done criteria. I checked in twice a week instead of once. By the end of the month he'd shipped two features and was answering questions in the channel. If it hadn't improved, my next step was a written plan with HR, and I'd told him that too."
The panel is listening for: you raised it early, you asked before you judged, the plan was specific, and you had a next step if it failed.
Technical debt versus features
There's no right ratio, so don't offer one as a rule. Show how you decide and how you sell it.
| Signal | What you say to the team or product partner |
|---|---|
| Incidents trace back to the same module | "Two of our last three incidents came from this module. Fixing it is roadmap work." |
| Features take longer each quarter | "This feature took three weeks; the same one took one week a year ago. Here's where the time went." |
| Debt that bothers engineers but doesn't slow delivery | "This can wait. Let's write it down and revisit next quarter." |
Example line to close the answer: "I bring debt to planning with a cost in days or incidents, so it competes with features on the same terms."
Growing senior engineers
Senior engineers grow through scope, not more tickets. Name one person and what you gave them.
Example answer:
"One senior engineer wanted to reach staff level. We agreed the gap was influence beyond our team. I handed her the design review for our team's move to the shared event bus, which needed sign-off from three other teams. I coached her before each review and stayed quiet in the room. She ran it, wrote the decision doc and later presented it at the engineering all-hands. Her promotion case used that project as its main example."
Mistakes to avoid
| Mistake | Why it hurts | Instead |
|---|---|---|
| Only talking about code | Sounds like you still want the IC job | Lead with people and delivery, bring in tech as context |
| "We" for everything | They can't tell what you did | "I" for your decisions, "we" for the team's work |
| A low performer story with no timeline | Sounds like you avoided it or rushed it | Weeks, check-ins, the next step if it failed |
| Calling a past report "lazy" | Panels hear blame | Describe behavior and what you did about it |
Practice the people stories out loud before the loop. Speaking Coach's AI interviewer reads the job post you add and asks follow-ups like "What would you have done if it didn't improve?", which is where most answers fall apart.
Questions people ask
How do I answer if I'm a first-time engineering manager?
Use tech lead or mentoring examples: an intern you onboarded, a design you led, a teammate you helped through a hard project. Say clearly that you haven't managed formally, then show the same skills.
Will there be a coding round?
Some companies include one, often lighter than for engineers; others replace it with a system design conversation. Ask your recruiter which, and prepare for that one.
What is a good answer to "How do you run one-on-ones?"
Say they belong to the engineer: a shared doc they fill first, career topics at least once a month, and your updates last. Add one thing you changed after a report's feedback.
How do I talk about firing someone?
Briefly and respectfully: the expectations, the support you gave, the documented plan and the decision. Never share details that would identify the person.