Engineering manager peer round: technical quality, ownership and long-term team health

In a peer-level interview for an engineering manager role, the conversation centers on engineering judgment and the culture you build: the engineering principles you hold your team to, how your team collaborates with others, including on new ideas, and how you think about technical quality, ownership and the long-term health of a team. ### Constraints and Clarifications - This is a conversation between peers rather than a scripted question list; expect the interviewer to push on any principle with "show me a time". - Real, recent examples carry more weight than descriptions of an ideal process. ### Clarifying Questions - Should I describe the team I lead today, or can I draw on earlier teams as well? - Are you more interested in how I set standards inside my team, or in how I work with peer teams and their managers? - Would you like me to cover technical debt specifically, or quality in general? ### Part 1 — Your engineering principles and a judgment call What engineering principles do you hold your team to? Pick one and describe a time it was tested: a situation where technical quality competed with speed or scope, what you decided, and how it played out. ```hint Principles need behavior For each principle, name the practice on your team that would make it visible to a new engineer in their first month. ``` #### What This Part Should Cover - A short set of principles, each tied to an observable team practice - A real quality-versus-speed decision made with explicit criteria - How any shortcut taken was tracked and paid back, or why the shortcut was refused ### Part 2 — Ownership, collaboration and long-term team health How do you build a team in which engineers own their work end to end and collaborate well with peer teams, including when developing new ideas together? How do you know whether the team is healthy for the long run, and what do you do when it is not? ```hint Pick leading indicators Choose signals that warn you months before attrition or an outage, rather than ones that only confirm the damage afterward. ``` #### What This Part Should Cover - Mechanisms that create ownership rather than merely assign it - Collaboration and joint innovation with peer teams, including how disagreements are resolved - Concrete team health signals and the actions taken on them ### What a Strong Answer Covers - Principles that are few, specific and visible in day-to-day practice - Judgment that weighs reversibility, blast radius and cost of delay instead of treating quality as absolute - Ownership that extends to production, with the manager setting the bar rather than making every call - Collaboration with peers framed around shared goals, not territory - A long-term view of team health that goes beyond delivery speed ### Follow-up Questions - A peer team keeps shipping changes that break your service. How do you handle it with their manager? - Your strongest engineer wants to rewrite a stable system. How do you decide? - How do you keep standards consistent across several teams without slowing them down? - What does technical debt look like on your team today, and how does it get prioritized?