Interview Q&A · 36 questions · 16 answered publicly
Engineering Manager Interview Questions
Ordered by how often they're asked. Sign in free to see every answer, rate your confidence and run timed mock interviews.
-
Most asked What does an engineering manager (development manager) do?
Summary
An engineering manager is accountable for the people and the organisation that deliver software: hiring, growth and performance, team health, delivery and the systems that make it predictable, and alignment with product and the business. 'Development manager' is the same role in many regions.
Longer Answer
Typical responsibilities: weekly 1:1s and career growth, hiring and onboarding, performance reviews and calibration, team structure and capacity planning, delivery and quality through metrics and process, partnership with product on roadmaps and OKRs, and reporting up. Technical depth still matters for credibility and judgement, but the manager usually doesn't own technical decisions day to day — the tech lead does.
Key Points
- People, organisation and delivery
- Partnership with tech lead and product
- Same role as development manager in many regions
Deep dive: The Manager's Operating System
-
Most asked You take over a team that has had three managers in two years. What do you do in your first 90 days?
Summary
Listen before changing: 1:1s with everyone using the same questions, meet stakeholders, review data; act immediately only on safety or burnout; share back what I heard by around day 45; fix one or two problems the team wants fixed; agree six-month outcomes with my manager; start regular cadences and career conversations by day 90.
Longer Answer
A team that has seen several managers judges the new one on listening and consistency. I'd keep existing commitments moving, avoid reorganising in month one, and be explicit about my plan and timeline with both the team and my director so the waiting is visible and purposeful.
Key Points
- Structured listening with data
- Share back; early fixes the team wants
- Agree six-month outcomes; start cadences
Deep dive: The First 90 Days With a New Team
-
Most asked How do you measure your team's performance?
Summary
With team-level delivery metrics — DORA's throughput measures (change lead time, deployment frequency, failed deployment recovery time) and instability measures (change fail rate, deployment rework rate) — combined with developer experience from a regular survey, following SPACE's advice to use several dimensions including perception.
Longer Answer
I compute the metrics from deploy and incident data, review trends with the team and use them to ask where work waits or what fails. I never rank individuals or set metrics as targets — individual activity measures get gamed and discourage reviewing and helping others. To leadership I report trends, context and the improvements underway.
Key Points
- DORA throughput and instability
- SPACE: multiple dimensions incl. perception
- For improvement, never ranking
Deep dive: Measuring Delivery Without Gaming It
-
Most asked How do you approach hiring for a new role?
Summary
Start with a scorecard — mission, first-year outcomes, competencies and what's not required — agreed with the panel; derive the job description from it; design a structured loop that assesses each competency once; plan the funnel backwards from the target; and close fast and personally.
Longer Answer
The scorecard keeps interviewers evaluating the same thing. Structured interviews with rubrics are more predictive and reduce differences between demographic groups. Funnel maths tells me how many candidates and interviewer hours I need, and interviewer load is planned as team capacity. A written 30-60-90 plan before day one makes the hire succeed.
Key Points
- Scorecard first
- Structured loop with rubrics
- Funnel and capacity planning; fast close
Deep dive: Defining the Role: Scorecards
-
Most asked What makes an interview process fair and predictive?
Summary
Structure: the same planned questions for each candidate, behavioral and hypothetical, scored against rubrics with example answers; trained interviewers; independent scoring before the debrief; and decisions based on evidence against the scorecard.
Longer Answer
Google's re:Work guide notes structured interviews increase predictive validity and reduce differences between demographic groups, and that rubrics are more predictive than unstructured interviews. I'd add diverse panels, shadowing for new interviewers, refreshed questions and regular calibration across teams.
Key Points
- Planned questions and rubrics
- Independent scoring; evidence-based debriefs
- Training and calibration
Deep dive: Structured Interviews and Reducing Bias
-
Most asked How do you help engineers grow their careers?
Summary
With a shared career ladder that makes expectations per level explicit, regular growth conversations using it, opportunities that exercise the next level's skills, and evidence collected throughout the year.
Longer Answer
I place each person on the ladder's dimensions with examples, describe the next level, and find a project that tests the gap. Quarterly career conversations cover longer-term goals, including paths into management or staff engineering. Calibration with other managers keeps levels consistent.
Key Points
- Shared ladder with observable behaviours
- Regular growth conversations
- Stretch opportunities and evidence
Deep dive: Career Ladders and Clear Expectations
-
Most asked How do you write and deliver performance reviews?
Summary
From evidence collected all year and mapped to the ladder; with no surprises — anything significant has been discussed already; structured around impact with examples and one or two growth areas; calibrated with peers; and delivered in conversation.
Longer Answer
Notes per report make reviews faster and fairer and avoid recency bias. Peer input with specific questions adds perspective. Calibration aligns ratings across managers and helps spot bias patterns. In the conversation I spend most time on impact and growth, then agree goals for the next period.
Key Points
- Year-round evidence
- No surprises
- Calibrated, conversational delivery
Deep dive: Performance Reviews and Calibration
-
Most asked How do you handle an engineer who has been underperforming for months?
Summary
Involve HR early and follow policy and local law; give clear, specific feedback that resets expectations; diagnose the cause; run a supported informal plan with written expectations and weekly check-ins; and move to a formal plan only if needed — designed so the person can genuinely succeed.
Longer Answer
Avoiding the issue is unfair to the person and the team; jumping to a formal process without clarity and support is unfair too. Typical support: pairing, a mentor, reduced scope. Documentation protects everyone. Most cases improve; the rest end with a fair, respectful outcome. This is general practice — requirements differ by country.
Key Points
- HR and policy first
- Clear expectations and support
- Documented, fair process
-
Most asked An engineer asks for a promotion you don't think they're ready for. What do you say?
Summary
I'm honest and specific: which ladder dimension is missing, with examples; I acknowledge their strengths; and we agree an opportunity that would produce the evidence, with regular progress reviews — while I build the case with them as we go.
Longer Answer
Vague 'not yet' answers feel evasive and push people to look elsewhere. I never promise timelines I don't control (committees, budgets), only actions I do control. If they disagree with my assessment, I invite them to bring evidence and consider a second opinion from a peer manager.
Key Points
- Specific gap with examples
- Opportunity and progress reviews
- Promise actions, not outcomes
Deep dive: Promotion and Compensation Conversations
-
Most asked How do you retain strong engineers?
Summary
By knowing each person's motivations and risk factors through regular 1:1s and stay conversations, and acting before resignations: growth opportunities, recognition, fair pay backed by data, manageable workload and a healthy team.
Longer Answer
A regretted departure can cost close to a year's salary once vacancy, ramp-up, team drag and recruiting are counted — so retention is worth deliberate effort. Gallup reports managers account for up to 70% of the variance in engagement. I track regretted attrition and its causes as a team health metric.
Key Points
- Stay conversations, not just exit interviews
- Act on growth, recognition, pay, workload
- Track regretted attrition
Deep dive: Retention and Regretted Attrition
-
Most asked How would you design teams for a growing product organisation?
Summary
Around the flow of work: mostly stream-aligned teams that own a customer journey end to end, with a platform team for shared capabilities and enabling or complicated-subsystem teams only where needed — sized at six to eight, with cognitive load as a constraint.
Longer Answer
Conway's law means team structure shapes system structure; layer teams create layered hand-offs. Team Topologies' four team types (stream-aligned, enabling, complicated-subsystem, platform) and three interaction modes (collaboration, X-as-a-Service, facilitating) give a shared language. I'd change in steps, measure lead time and hand-offs per feature, and revisit interaction modes as things stabilise.
Key Points
- Stream-aligned by default
- Team Topologies types and interaction modes
- Cognitive load and team size
Deep dive: Team Design and Cognitive Load
-
Most asked Your organisation must double headcount in a year. What do you watch out for?
Summary
That effective capacity lags headcount because of ramp-up, onboarding and interviewing; that new teams need experienced engineers and managers; and that roadmaps follow a capacity model, not the hiring plan.
Longer Answer
Hire managers and leads early, grow teams by budding (grow to eight to ten, then split into two teams of four or five), plan interviewer and onboarding capacity explicitly, and re-forecast quarterly from measured ramp-up. Brooks's law reminds us that adding people to a late project usually makes it later.
Key Points
- Capacity lags headcount
- Managers first; grow by budding
- Roadmap from a capacity model
Deep dive: Headcount and Capacity Planning
-
Most asked Tell me about a time you turned around a struggling team.
Summary
Describe the starting state with data, how you diagnosed causes (not symptoms), what you changed in what order — people and delivery — and the measured results after six to twelve months.
Longer Answer
Strong answers connect problems into a system (e.g. infrequent large releases causing incidents, incidents eating capacity, overload driving attrition) and show a sequence: listening, immediate relief for burnout, then process and delivery changes, with goals like lead time, change fail rate, planned vs done and engagement scores. Credit the team.
Key Points
- Baseline data
- Systemic diagnosis
- Sequenced changes and measured outcomes
Deep dive: Capstone: Take Over a Struggling Team
-
Most asked Tell me about a time you disagreed with your own manager or leadership.
Summary
Describe the decision, your reasoning and evidence, how you raised it (privately, with options), what happened, and how you supported the final decision with your team.
Longer Answer
Strong answers show respectful challenge with data, an alternative proposal, and "disagree and commit" once a decision is made — representing it to the team honestly without undermining it ("this wasn't my recommendation, but here's why it was decided and how we'll make it work").
Key Points
- Evidence and options, raised privately
- Outcome
- Committed publicly afterwards
Deep dive: Reporting Up and Representing Your Teams
-
Most asked How do you work with product on roadmaps and goals?
Summary
We plan jointly — engineering manager, product manager and tech lead — with outcome-based OKRs where features are bets, explicit visible capacity for technical investment with its own outcomes, and mid-quarter reviews where we change or stop bets that aren't moving the results.
Longer Answer
OKRs written as tasks ("launch saved cards") don't tell us whether work mattered; outcome KRs (conversion, success rate, latency) do. Reserving 20–30% for platform and reliability, visibly, stops it competing invisibly with features. A now/next/later roadmap avoids false precision beyond the current quarter.
Key Points
- Joint planning
- Outcome KRs; features as bets
- Visible technical investment
Deep dive: Roadmaps and OKRs With Product
-
Most asked How technical should an engineering manager be?
Summary
Technical enough to understand trade-offs, ask good questions, judge risk and earn credibility — but not the person making day-to-day technical decisions or writing critical-path code. Those belong to the tech lead and the team.
Longer Answer
Managers who code on the critical path become bottlenecks and neglect people work; managers with no technical depth can't evaluate designs, risks or hiring signals. Ways to stay current: reading design docs and incident reviews, joining design reviews as a listener, small non-critical contributions, and pairing occasionally.
Key Points
- Enough to judge risk and trade-offs
- Not the critical path
- Stay current deliberately
Deep dive: The Manager's Operating System
- How do you structure your week as an engineering manager?
- Leadership asks for individual developer productivity metrics. How do you respond?
- How do you report your teams' status to leadership?
- How do you run a hiring debrief?
- You need to hire four engineers this quarter. How do you plan it?
- How do you onboard new engineers so they succeed?
- An engineer says they're underpaid compared with a colleague. How do you handle it?
- A project is late. Your director suggests adding three engineers. What do you say?
- How do you communicate a reorganisation to your teams?
- Tell me about a hire you got wrong. What did you learn?
- Tell me about a time you had to let someone go or manage someone out.
- Tell me about a time you grew someone into a leadership role.
- Tell me about a difficult organisational change you led.
- Two of your teams blame each other for a failed launch. What do you do?
- Your best engineer wants to become a manager, but you think they'd be happier as an IC. What do you do?
- Your team's engagement survey results dropped sharply. What do you do?
- How do you balance technical debt and feature work at the organisation level?
- What is your management philosophy?
- How do you keep in touch with what's really happening in your organisation as it grows?
- How do you support managers who report to you?