Engineering Manager Interview: Your Technical Contribution and an Annoying Teammate

You are interviewing for an engineering manager role. After the recruiter call, the next step is a one-hour conversation with the hiring manager, and the questions are basic on the surface. After you introduce yourself, the hiring manager asks what your technical contribution is and whether members of your team have ever annoyed you. When you describe your projects, the hiring manager shows little interest in the project details themselves; what they want to learn is what your technical contribution is as a manager. Prepare answers to both questions. ### Clarifying Questions - How hands-on is this role expected to be: writing production code, reviewing designs, setting technical direction, or a mix? - Should the introduction emphasize your management scope (team size, domain, responsibilities) or your technical background? - Is the second question about everyday friction, or about a serious performance or conduct problem? ### Part 1 — Introduce yourself and explain your technical contribution Give a short introduction, then choose a project you led and answer: "What was your technical contribution?" Expect the interviewer to cut through the project narrative and push on what, specifically, was yours rather than the team's. ```hint Separate the team's output from your decisions List the technical calls, reviews or interventions that would not have happened without you, and lead with those instead of with what the system does. ``` #### What This Part Should Cover - A concise introduction that frames your technical identity as a manager - Specific technical decisions attributable to you, distinguished from the team's execution - How your judgment changed the outcome: an option chosen or rejected, a risk caught, a result that moved - The right altitude: enough depth to be credible, without a component-by-component tour ### Part 2 — A team member who annoyed you The interviewer asks: "Has anyone on your team ever annoyed you?" Describe the situation, what you did, and what happened. ```hint Name the behavior, not the person Anchor the story on a concrete, observable behavior and its effect on the team, and include what you noticed about your own reaction. ``` #### What This Part Should Cover - A candid yes with a real, appropriately sized example rather than a dodge - Separating the behavior from the person and finding its cause before acting - Concrete managerial action (feedback, expectations, follow-up) and its outcome - Self-awareness: what the episode changed about how you manage ### What a Strong Answer Covers - Both answers structured as situation, task, action and result, with outcomes stated - Deliberate use of "I" for your own decisions and "we" for the team's work - Candor and self-awareness without blaming or disparaging anyone - Answers short enough to leave room for the interviewer's follow-up probing - Consistency between the technical judgment claimed in Part 1 and the way you describe managing people in Part 2 ### Follow-up Questions - What was the most recent technical decision you personally changed or overrode, and how did the team react? - How do you stay technically credible when you write little or no production code? - If the behavior in your Part 2 story had continued after your intervention, what would your next steps have been? - How do you decide when to make a technical call yourself and when to let a senior engineer own it?