You were promoted from senior IC to manage the same seven-person team, and two former peers still bring you implementation questions every day. What do you change in your first two weeks?

I would make the role change explicit and redirect implementation ownership without withdrawing technical support. - In week one, I would hold a team meeting that names my new responsibilities and confirms who owns each active technical area. - I would give each former peer a 30-minute transition conversation and record any changed expectations in our shared team charter. - For two weeks, I would answer implementation questions with an owner and next step, then check that direct requests to me are declining.

Your first manager calendar contains 18 hours of recurring meetings, leaving no preparation time for seven 1:1s. How would you rebuild the week?

I would protect the people work first, then require every recurring meeting to justify its place. - I would block seven 30-minute 1:1s, two 45-minute preparation blocks, and one 90-minute focus block before accepting other meetings. - I would audit every recurring invite for a decision or artifact, declining or delegating meetings where my role is only to listen. - After four weeks, I would compare planned versus actual calendar time and keep recurring meetings below roughly half of the week.

You still compile the weekly engineering update yourself from six engineers' messages, and it takes three hours every Friday. What would you delegate?

I would delegate collection and first-draft ownership while remaining accountable for the final message. - I would create a one-page template with progress, next step, decision needed, and owner, due from each engineer by Thursday noon. - I would rotate a weekly update owner for four weeks and give the first owner a 20-minute walkthrough plus one completed example. - I would review the draft in 20 minutes on Friday and consider delegation successful when it needs only factual corrections.

Three engineers spend 40 minutes debating an API naming choice because nobody knows who decides. What decision rule would you introduce?

I would name one decision owner and time-box input so a reversible choice does not consume the team. - I would ask the engineer implementing the API to own the decision after a 15-minute review with the two affected consumers. - I would record the chosen naming rule and rationale in a short ADR linked from the ticket. - I would add a decision-rights table to the team charter and check after two sprints that similar choices close within one working day.

You have not coded in the team's main service for six months, but you must join a design review for a new queue consumer next Tuesday. How do you prepare without taking over?

I would refresh enough context to ask useful risk questions while leaving the design decision with the engineers. - Before Tuesday, I would read the current architecture diagram, the last two related ADRs, and one representative pull request. - I would ask the author for a 30-minute walkthrough focused on throughput assumptions, failure handling, and operational ownership. - In the review, I would write questions and decisions into the design document, then confirm that the named technical owner approves the final version.

During your first month as manager, you personally fix every small CI failure, and engineers now tag you on five routine failures a week. What do you do?

I would stop being the default fixer and build a simple ownership path for routine CI failures. - I would publish a one-page triage guide covering the three common failures, the first diagnostic command, and the owning engineer. - For the next two failures, I would pair for 15 minutes but require the assigned engineer to make the fix and update the guide. - I would track tags for four weeks and call the handoff complete when routine failures reach the documented owner without my intervention.

The team expects you to present every sprint demo because the previous manager did. How would you delegate the next three demos?

I would rotate demo ownership to the engineers who built the work and give them a predictable preparation format. - I would assign the next three demos during sprint planning, with one primary presenter and one backup named on each ticket. - I would provide a five-minute demo outline covering user problem, change, evidence, and next step, then offer one 15-minute rehearsal. - After each demo, I would collect one presenter note and consider the rotation established when all three run without me taking the screen.

Your seven-person team can book over every open calendar slot, and you have rescheduled planning preparation twice in one month. What boundary do you set?

I would create visible office hours and protect preparation blocks so access to me stays reliable without making the calendar fully open. - I would publish two 45-minute office-hour slots each week for non-urgent questions and keep 1:1s directly bookable. - I would mark two weekly 90-minute planning and review blocks as unavailable except for a named urgent business decision. - After one month, I would review declined requests and move an office hour if more than two people repeatedly cannot attend.

In a design review, four engineers choose a library you would not have selected as an IC, but their comparison covers the agreed requirements. What do you do next?

I would support the team's choice because the owner followed the agreed decision process and the choice is reversible. - I would ask the owner to add the comparison criteria, selected option, and reconsideration trigger to the ADR before approval. - I would state in the meeting that my preference differs but does not override the evidence or the technical owner's decision right. - I would schedule a 30-day check against the ADR's adoption and performance signals rather than reopening the choice informally.

A team of eight asks you to approve ticket scope, reviewer choice, and minor design details, creating 12 approval messages in two days. How would you clarify decision rights?

I would publish a lightweight decision map that reserves my approval for people, priority, and high-impact risk decisions. - I would list six recurring decision types with a single owner, required consultees, and whether the choice needs a written record. - I would let ticket owners decide scope details and reviewers decide code changes, escalating only choices that cross the stated risk threshold. - After two weeks, I would sample the decision log and target fewer than three approval requests that the map already delegates.

You inherit six engineers who have had irregular 1:1s, sometimes six weeks apart. What setup do you put in place during your first ten working days?

I would establish a dependable 1:1 every other week and agree on the purpose with each engineer. - By day five, I would send six recurring 30-minute invites for every other week with a private shared agenda owned by the engineer. - In the first meeting, I would agree on preferred topics and explain the approved note practice and its confidentiality limits, recording those choices at the top of the agenda. - By day ten, I would have a completed first meeting or a confirmed alternative slot for every direct report.

A new direct report answers every 1:1 question with fine and the first 20 minutes produce no useful detail. How do you change the conversation?

I would replace broad prompts with one recent, observable situation and allow silence before filling it. - I would ask about a specific artifact, such as the pull request they opened Tuesday, and what made that work easier or harder. - I would wait at least five seconds after the answer, then reflect back one phrase and ask whether I understood it correctly. - I would end with one topic they choose for next time and place it in the shared agenda before the meeting closes.

After three 1:1s, you notice you speak for about 25 of the 30 minutes and mostly give status updates. What do you change for the next meeting?

I would redesign the 1:1 around the engineer's agenda and limit my own update to information they need. - I would ask the engineer to add one topic 24 hours before the meeting and add only one manager topic myself. - I would reserve the first 20 minutes for their topic and use a timer to keep my status update under five minutes. - After the meeting, I would record the speaking-time estimate and target the engineer speaking for at least half of the next three 1:1s.

One remote engineer is eight hours ahead, and your current 1:1 lands at 7 p.m. for them every other week. How do you repair the setup?

I would move the recurring meeting into their normal working hours and make asynchronous preparation the default. - I would compare both calendars and offer two 30-minute slots that fall inside the engineer's stated workday. - I would use a shared agenda updated 24 hours ahead so context questions do not consume the live conversation. - I would review the time after four meetings and treat zero after-hours sessions as the completion signal.

In a 1:1, an engineer describes six unrelated frustrations in ten minutes, and you are unsure which one matters most. What do you say and capture?

I would summarize what I heard, ask them to choose the most important issue, and agree on one next step. - I would reflect the six points in two or three themes and ask the engineer to correct my summary. - I would ask which single theme they want changed within the next two weeks and why that one comes first. - I would write one owner and date in the private notes, then open the next 1:1 by checking that action.

Two pull request comments from an engineer read as dismissive, and a teammate stops asking them review questions. How would you give feedback this week?

I would give private, behavior-specific feedback promptly and ask for a visible replacement behavior. - Within two working days, I would quote the two comments and describe the observed result without labeling the engineer's intent. - I would ask them to rewrite future objections with the risk, a suggested alternative, and an invitation to discuss for ten minutes. - I would review their next three pull request conversations and acknowledge the change when the new format appears consistently.

An engineer quietly improves the build from 14 minutes to 8 minutes, but only you noticed the dashboard change. How do you recognize the work?

I would recognize the specific impact in a channel the engineer is comfortable with and connect it to team outcomes. - I would first ask whether they prefer recognition in the team meeting, written channel, or private 1:1. - I would cite the 14-to-8-minute result and estimate the weekly time saved rather than saying only great job. - I would add the result to the sprint demo notes and the engineer's growth evidence with their consent.

A junior engineer writes get better at backend as their quarterly growth goal. How would you turn it into a usable plan?

I would narrow the goal to one observable capability, one practice opportunity, and one review date. - Together we would choose a target such as independently designing one small API endpoint against the team's checklist by week eight. - I would assign one scoped endpoint, a senior reviewer, and two 30-minute design check-ins before implementation starts. - We would review the design artifact at weeks four and eight and mark the goal complete when the checklist passes without manager prompts.

An engineer asks what separates level two from level three, but the career ladder has 18 broad statements and no examples. What do you do before the next 1:1?

I would translate the ladder into role-relevant evidence without promising a promotion decision myself. - I would select three competencies that differ between the two levels and attach one team-specific example to each. - I would ask my manager or the calibration owner to verify the examples against the latest promotion rubric before sharing them. - In the next 1:1, we would map two recent artifacts to the rubric and choose one evidence gap for the next eight weeks.

A remote engineer delivered three customer-requested improvements this month but is rarely mentioned in office conversations. How do you make recognition fair?

I would make contribution evidence part of the team's regular review rather than relying on who is most visible. - Before the monthly team review, I would gather completed tickets, customer feedback, and peer acknowledgments for all seven engineers. - I would name the three improvements and their user result in the written update, after checking the engineer's recognition preference. - I would audit the next two monthly updates so every major contribution has an owner and no credit depends on office presence.

Engineering Manager interview questions

100 real questions with model answers and explanations for Engineering Manager candidates.

See a Engineering Manager resume example →

Practice with flashcards

Spaced repetition · Hunter Pass

Questions

I would make the role change explicit and redirect implementation ownership without withdrawing technical support.

In week one, I would hold a team meeting that names my new responsibilities and confirms who owns each active technical area.
I would give each former peer a 30-minute transition conversation and record any changed expectations in our shared team charter.
For two weeks, I would answer implementation questions with an owner and next step, then check that direct requests to me are declining.

Why interviewers ask this: The interviewer is evaluating whether a first-time manager can reset peer relationships and transfer ownership through visible actions.

one-on-one

I would protect the people work first, then require every recurring meeting to justify its place.

I would block seven 30-minute 1:1s, two 45-minute preparation blocks, and one 90-minute focus block before accepting other meetings.
I would audit every recurring invite for a decision or artifact, declining or delegating meetings where my role is only to listen.
After four weeks, I would compare planned versus actual calendar time and keep recurring meetings below roughly half of the week.

Why interviewers ask this: A strong answer turns calendar management into explicit priorities, review criteria, and a measurable follow-up.

delegation

I would delegate collection and first-draft ownership while remaining accountable for the final message.

I would create a one-page template with progress, next step, decision needed, and owner, due from each engineer by Thursday noon.
I would rotate a weekly update owner for four weeks and give the first owner a 20-minute walkthrough plus one completed example.
I would review the draft in 20 minutes on Friday and consider delegation successful when it needs only factual corrections.

Why interviewers ask this: The interviewer is checking whether delegation includes a clear artifact, support, and a definition of done.

api

I would name one decision owner and time-box input so a reversible choice does not consume the team.

I would ask the engineer implementing the API to own the decision after a 15-minute review with the two affected consumers.
I would record the chosen naming rule and rationale in a short ADR linked from the ticket.
I would add a decision-rights table to the team charter and check after two sprints that similar choices close within one working day.

Why interviewers ask this: The answer should distinguish consultation from ownership and leave a reusable decision artifact.

joinsdesigndata-structures

I would refresh enough context to ask useful risk questions while leaving the design decision with the engineers.

Before Tuesday, I would read the current architecture diagram, the last two related ADRs, and one representative pull request.
I would ask the author for a 30-minute walkthrough focused on throughput assumptions, failure handling, and operational ownership.
In the review, I would write questions and decisions into the design document, then confirm that the named technical owner approves the final version.

Why interviewers ask this: The interviewer is evaluating technical credibility based on preparation and questions rather than coding control.

discovery

I would stop being the default fixer and build a simple ownership path for routine CI failures.

I would publish a one-page triage guide covering the three common failures, the first diagnostic command, and the owning engineer.
For the next two failures, I would pair for 15 minutes but require the assigned engineer to make the fix and update the guide.
I would track tags for four weeks and call the handoff complete when routine failures reach the documented owner without my intervention.

Why interviewers ask this: A strong answer replaces personal heroics with documented ownership and a measurable transfer of capability.

agiledelegation

I would rotate demo ownership to the engineers who built the work and give them a predictable preparation format.

I would assign the next three demos during sprint planning, with one primary presenter and one backup named on each ticket.
I would provide a five-minute demo outline covering user problem, change, evidence, and next step, then offer one 15-minute rehearsal.
After each demo, I would collect one presenter note and consider the rotation established when all three run without me taking the screen.

Why interviewers ask this: The interviewer wants evidence that delegation develops team visibility instead of merely moving a task.

I would create visible office hours and protect preparation blocks so access to me stays reliable without making the calendar fully open.

I would publish two 45-minute office-hour slots each week for non-urgent questions and keep 1:1s directly bookable.
I would mark two weekly 90-minute planning and review blocks as unavailable except for a named urgent business decision.
After one month, I would review declined requests and move an office hour if more than two people repeatedly cannot attend.

Why interviewers ask this: The answer should balance manager availability with protected preparation through a testable calendar design.

design

I would support the team's choice because the owner followed the agreed decision process and the choice is reversible.

I would ask the owner to add the comparison criteria, selected option, and reconsideration trigger to the ADR before approval.
I would state in the meeting that my preference differs but does not override the evidence or the technical owner's decision right.
I would schedule a 30-day check against the ADR's adoption and performance signals rather than reopening the choice informally.

Why interviewers ask this: The interviewer is checking whether technical credibility can coexist with clear delegation and restraint.

governancescope-managementdesign

I would publish a lightweight decision map that reserves my approval for people, priority, and high-impact risk decisions.

I would list six recurring decision types with a single owner, required consultees, and whether the choice needs a written record.
I would let ticket owners decide scope details and reviewers decide code changes, escalating only choices that cross the stated risk threshold.
After two weeks, I would sample the decision log and target fewer than three approval requests that the map already delegates.

Why interviewers ask this: A strong answer reduces approval dependency with specific categories, thresholds, and an adoption measure.

ownershipone-on-one

I would establish a dependable 1:1 every other week and agree on the purpose with each engineer.

By day five, I would send six recurring 30-minute invites for every other week with a private shared agenda owned by the engineer.
In the first meeting, I would agree on preferred topics and explain the approved note practice and its confidentiality limits, recording those choices at the top of the agenda.
By day ten, I would have a completed first meeting or a confirmed alternative slot for every direct report.

Why interviewers ask this: The interviewer is evaluating whether the manager creates consistency, consent, and full coverage quickly.

one-on-one

I would replace broad prompts with one recent, observable situation and allow silence before filling it.

I would ask about a specific artifact, such as the pull request they opened Tuesday, and what made that work easier or harder.
I would wait at least five seconds after the answer, then reflect back one phrase and ask whether I understood it correctly.
I would end with one topic they choose for next time and place it in the shared agenda before the meeting closes.

Why interviewers ask this: A strong answer demonstrates practical listening behaviors rather than adding more generic questions.

reportingone-on-one

I would redesign the 1:1 around the engineer's agenda and limit my own update to information they need.

I would ask the engineer to add one topic 24 hours before the meeting and add only one manager topic myself.
I would reserve the first 20 minutes for their topic and use a timer to keep my status update under five minutes.
After the meeting, I would record the speaking-time estimate and target the engineer speaking for at least half of the next three 1:1s.

Why interviewers ask this: The interviewer is checking whether the manager can observe and correct a conversation pattern with a concrete experiment.

one-on-one

I would move the recurring meeting into their normal working hours and make asynchronous preparation the default.

I would compare both calendars and offer two 30-minute slots that fall inside the engineer's stated workday.
I would use a shared agenda updated 24 hours ahead so context questions do not consume the live conversation.
I would review the time after four meetings and treat zero after-hours sessions as the completion signal.

Why interviewers ask this: A strong answer makes remote inclusion visible in scheduling, preparation, and a clear success condition.

one-on-one

I would summarize what I heard, ask them to choose the most important issue, and agree on one next step.

I would reflect the six points in two or three themes and ask the engineer to correct my summary.
I would ask which single theme they want changed within the next two weeks and why that one comes first.
I would write one owner and date in the private notes, then open the next 1:1 by checking that action.

Why interviewers ask this: The interviewer is evaluating active listening that turns a broad conversation into an agreed and traceable action.

feedbackcode-review

I would give private, behavior-specific feedback promptly and ask for a visible replacement behavior.

Within two working days, I would quote the two comments and describe the observed result without labeling the engineer's intent.
I would ask them to rewrite future objections with the risk, a suggested alternative, and an invitation to discuss for ten minutes.
I would review their next three pull request conversations and acknowledge the change when the new format appears consistently.

Why interviewers ask this: A strong answer uses observable evidence, a concrete behavior request, and timely follow-up without escalating the situation.

I would recognize the specific impact in a channel the engineer is comfortable with and connect it to team outcomes.

I would first ask whether they prefer recognition in the team meeting, written channel, or private 1:1.
I would cite the 14-to-8-minute result and estimate the weekly time saved rather than saying only great job.
I would add the result to the sprint demo notes and the engineer's growth evidence with their consent.

Why interviewers ask this: The interviewer is checking whether recognition is specific, proportionate, and adapted to the recipient.

I would narrow the goal to one observable capability, one practice opportunity, and one review date.

Together we would choose a target such as independently designing one small API endpoint against the team's checklist by week eight.
I would assign one scoped endpoint, a senior reviewer, and two 30-minute design check-ins before implementation starts.
We would review the design artifact at weeks four and eight and mark the goal complete when the checklist passes without manager prompts.

Why interviewers ask this: A strong answer converts vague development intent into evidence, support, and a completion signal.

one-on-onecareer-ladder

I would translate the ladder into role-relevant evidence without promising a promotion decision myself.

I would select three competencies that differ between the two levels and attach one team-specific example to each.
I would ask my manager or the calibration owner to verify the examples against the latest promotion rubric before sharing them.
In the next 1:1, we would map two recent artifacts to the rubric and choose one evidence gap for the next eight weeks.

Why interviewers ask this: The interviewer is evaluating whether career guidance is concrete, calibrated, and honest about decision authority.

recognition

I would make contribution evidence part of the team's regular review rather than relying on who is most visible.

Before the monthly team review, I would gather completed tickets, customer feedback, and peer acknowledgments for all seven engineers.
I would name the three improvements and their user result in the written update, after checking the engineer's recognition preference.
I would audit the next two monthly updates so every major contribution has an owner and no credit depends on office presence.

Why interviewers ask this: A strong answer counters proximity bias with recurring evidence and respects how the employee wants to be recognized.

Locked questions

21
In the last four design reviews, the same two senior engineers spoke while three others asked no questions. What would you try in the next review?
design
22
You keep detailed 1:1 notes, and a direct report asks exactly who can read them and how long they remain. What do you change?
one-on-one
23
A product-planning meeting repeatedly collides with a 1:1 that occurs every other week, and you have moved the engineer's slot three times in six weeks. What do you do now?
one-on-one
24
You asked an engineer to include test evidence in pull requests, but the next two pull requests still have empty verification sections. How do you follow up?
code-review
25
An engineer wants to practice technical leadership this quarter, and a small authentication cleanup needs coordination across four contributors. What assignment do you design?
authdesign
26
A seven-person team enters two-week sprint planning with 43 points proposed, but its last three sprints averaged 28 completed points. How do you run the session?
agilesessions
27
The last three retrospectives produced the same improve communication note, but no owner or action followed. How do you run the next one?
agileretrospective
28
Daily standup for eight people now takes 25 minutes and sounds like individual status reporting to you. What change do you test next week?
reporting
29
Product marks 12 backlog items as high priority, but the team can complete about six this sprint. How do you get to an ordered list?
agilebacklog
30
Three engineers estimate the same ticket as 3, 5, and 13 points because they made different assumptions about data migration. What do you do in refinement?
estimationmigrations
31
Four customer requests arrive during a sprint, and engineers start each one from direct messages without updating the board. What basic intake rule do you add?
agile
32
The repository has 14 pull requests waiting more than two working days for review. How do you restore a basic review flow?
code-review
33
A pull request receives comments from five reviewers, including contradictory requests about error handling. Who should resolve the review?
code-reviewerror-handling
34
Two engineers make different caching choices because the last architecture decision exists only in a six-month-old chat thread. What documentation practice do you introduce?
documentationarchitecturecaching
35
A new engineer follows the setup guide and finds seven commands that no longer work. How do you repair the documentation without owning every future update?
documentation
36
Your team has nine recurring meetings totaling 11 hours per engineer every two weeks. How do you simplify the cadence?
37
Five of the next sprint's top eight tickets have acceptance criteria such as make search better. What happens before planning?
agilespecs
38
A sprint demo shows six completed backend changes, but stakeholders cannot tell what user outcome changed. How do you reshape the next demo?
stakeholder-managementagilecommunication
39
A new engineer starts Monday, but on Friday afternoon their laptop, repository access, and first-week schedule are still unconfirmed. What do you do?
40
You are drafting the first 30 days for a backend engineer joining a team of six. What outcomes go into the plan?
41
The new engineer has completed their first 30 days and can handle small tickets with a buddy. What should the 60-day checkpoint require?
42
A new hire reaches day 60 with the expected artifacts complete. What would make their day-90 plan complete?
artifacts
43
Your company has a 12-week probation period, but the team currently waits until week 11 to discuss progress. What checkpoint schedule do you create?
44
Four interviewers will assess a software engineer next week, but the scorecard currently contains only strong technical skills and good communicator. How do you make it usable?
45
Two interviewers score the same candidate answer as 1 and 4 on a four-point scale. What do you inspect before the next interview?
46
An engineer will shadow their first technical interview tomorrow and has never used the scorecard. What instructions do you give them?
47
A candidate debrief starts with I liked them from one interviewer and not senior enough from another. How do you redirect the 20-minute meeting?
48
A team of seven has no written norms, and people use chat, tickets, and meetings interchangeably for decisions. What do you establish in one workshop?
49
You assign an onboarding buddy, but during the first week the buddy receives 17 ad hoc messages and cannot finish planned work. How do you redesign the buddy role?
onboarding
50
A remote new hire joins a team spread across three time zones and has only two overlapping hours with everyone. What first-week norms do you set?
joinsspread
51
An engineer joining next week's on-call rotation asks for production write access today, but their mandatory security training is not complete. What do you do?
on-call
52
A previously reliable engineer has missed three agreed pull request dates in six weeks and has stopped raising blockers; what do you do first?
communicationcode-review
53
During two customer bug reviews this month, an engineer called support requests pointless and interrupted the support lead five times; how do you respond?
54
Two teammates report that an engineer has been dismissive in code review, but the written comments are ambiguous; how do you investigate fairly this week?
code-review
55
Over two months, three of an engineer's changes caused customer-visible defects: two low-severity validation misses and one high-severity defect that required a rollback. Design a 30-day coaching plan without jumping straight to formal discipline.
severity-prioritydefectsdesign
56
You need to document six weeks of missed commitments for possible formal performance action; what belongs in the record and what does not?
performance
57
You promised an engineer written feedback by Friday, missed that commitment twice, and they say your promises no longer feel reliable. How do you restore trust?
feedbackpromises
58
An engineer rates themselves as exceeding expectations, but your six-month evidence shows two missed goals and one met goal; how do you handle the review?
soft-skills
59
The last two visible cross-team stretch assignments went to the same engineer because they volunteered first, and three teammates say they never knew the work was available. How do you allocate the next assignment and sponsorship?
sponsorcross-team
60
An engineer says a performance plan is retaliation for raising a production risk two weeks earlier; how do you handle the allegation?
soft-skillsperformance-planperformance
61
A senior engineer says they will bypass the required canary and second approval to ship a Friday hotfix, and no incident is active. How do you respond?
incident-managementincidentsdeployment-strategies
62
One engineer interrupted three colleagues nine times in a 40-minute design review; what do you do during and after the meeting?
design
63
Frontend and backend engineers each claim the other owns validation for a checkout change due in eight days; how do you settle the boundary?
validation
64
A terse Slack exchange between two remote engineers has produced 26 messages and no decision by noon; how do you intervene?
65
Three important decisions were made at 6 p.m. London time, repeatedly excluding two engineers in UTC+8; what do you change?
66
An engineer has declined five review requests from one teammate while accepting six from others in the same month; how do you address it?
67
During a demo, an engineer says another engineer's implementation is amateur work in front of 18 stakeholders; what do you do?
stakeholder-managementcommunication
68
Two engineers assigned to pair for a six-day migration have spent the first two days arguing over coding style; how do you recover the work?
migrations
69
A junior engineer says a senior engineer presented their prototype as their own in two stakeholder meetings; how do you investigate and repair credit?
stakeholder-managementprototypescommunication
70
You disclosed one engineer's private conflict complaint to the other engineer by name, and trust dropped afterward; how do you recover?
conflict-management
71
Your team of eight learns on Monday that a release due Friday is two weeks behind; what do you do in the first 24 hours?
releases
72
A launch in 10 days has 14 remaining stories but capacity for only eight; how do you cut scope with the PM?
scope-managementlaunchescapacity-planning
73
A PM wants to ship in seven days, but the tech lead identifies an untested payment retry path that could double-charge 0.5% of orders; how do you handle the disagreement?
soft-skillsconflictresilience
74
A stakeholder asks why a promised API is six days late after hearing nothing for a week; what update do you send today?
stakeholder-managementapipromises
75
Leadership replaces the team's top priority halfway through a two-week sprint, after four engineers have spent 18 engineer-days on it; what do you do?
agile
76
Three days before launch, your team discovers that another team's API will not be ready for 12 days; how do you respond?
launchesapi
77
Sales wants a limited pilot with 10 customers on Friday; functional testing passed, but Support has no runbook, escalation route, or named feature owner. What must happen before go-live?
escalationtestingrunbooks
78
An engineer's estimate grows from four days to 11 after two days of discovery; how do you manage the change without punishing early honesty?
estimation
79
Thirty-eight customers contacted Support this month after failing the same CSV import step; Product calls it a training gap, while Support calls it a product defect. How do you settle the dispute?
defects
80
Your team delivered a feature on time, but activation reached only 8% against a 25% target after 14 days; what do you do next?
activation
81
An engineer meets their roadmap dates, but calendar and review logs show 12 hours a week mentoring two juniors and reviewing 40% of pull requests; the planning board shows neither, and they say focus time has disappeared. What do you do?
mentoringcode-reviewroadmap
82
An engineer closes fewer tickets than teammates because they own complex maintenance work, but two agreed service-improvement outcomes are late. How do you assess their performance?
performance
83
A strong engineer has declined two roadmap discussions, stopped volunteering for ownership they sought last quarter, and tells you they are unsure the role still offers growth. How do you respond?
roadmapownershiproadmapping
84
Your only engineer familiar with billing will take four weeks of planned leave starting in 18 days; how do you prepare coverage?
coverage
85
On a seven-person team, one engineer handled 11 of 16 after-hours pages last month because others rarely acknowledged alerts; what do you change?
alerting
86
You inherit a team of eight with no team-health data; which measures do you establish for the next quarter?
ownership
87
Your anonymous workload pulse drops from 4.1 to 2.9 over two months while delivery remains on target; what do you do?
88
An engineer with three years in the role says recent hires may be paid almost the same and asks what two named colleagues earn. How do you discuss possible pay compression?
89
An engineer requests a temporary four-day week for eight weeks to handle caregiving, while they own a launch due in six weeks; what do you do?
launches
90
After a difficult quarter, only two of seven engineers speak in retrospectives and sick days doubled from six to 12; how do you assess team health?
retrospectiveteam-healthagile
91
At 02:10, checkout errors reach 38% and revenue is affected; as the manager of the owning team, how do you assign P1 roles in the first 10 minutes?
p1-incident
92
A P2 API slowdown has lasted 35 minutes, p95 latency is 2.4 seconds against a 700 ms SLO, and the on-call engineer is unsure whether to escalate; what do you do?
escalationon-callapi
93
During a two-hour P1, executives ask for updates every five minutes while engineers are still diagnosing; how do you set the status cadence?
p1-incident
94
Forty minutes into a P1, a VP demands an exact recovery time, but the team has only narrowed the cause to two services; what do you say?
p1-incident
95
A P1 was triggered when an engineer followed an approved deployment runbook that omitted a schema check; how do you run the postmortem?
postmortemp1-incidentdeployment
96
Three postmortem actions from the last P2 are still open after 45 days, and the same alert fired again; what do you do?
postmortemalertingincidents
97
During a P1, the incident commander and database owner disagree for 12 minutes about rollback versus failover; how do you intervene?
incident-managementincident-commandp1-incident
98
A P2 investigation finds that logs may contain customer email addresses from the last 24 hours; what do you do next?
99
In your first month as manager, you took the keyboard during a P1, overrode the on-call engineer, and introduced a second failed change; how do you recover?
on-callp1-incident
100
You treated a growing incident as P2 for 50 minutes even after payment failures crossed the P1 threshold, delaying customer updates; how do you repair the process?
incident-managementp1-incidentincidents

Questions

1You were promoted from senior IC to manage the same seven-person team, and two former peers still bring you implementation questions every day. What do you change in your first two weeks?

2Your first manager calendar contains 18 hours of recurring meetings, leaving no preparation time for seven 1:1s. How would you rebuild the week?

3You still compile the weekly engineering update yourself from six engineers' messages, and it takes three hours every Friday. What would you delegate?

4Three engineers spend 40 minutes debating an API naming choice because nobody knows who decides. What decision rule would you introduce?

5You have not coded in the team's main service for six months, but you must join a design review for a new queue consumer next Tuesday. How do you prepare without taking over?

6During your first month as manager, you personally fix every small CI failure, and engineers now tag you on five routine failures a week. What do you do?

7The team expects you to present every sprint demo because the previous manager did. How would you delegate the next three demos?

8Your seven-person team can book over every open calendar slot, and you have rescheduled planning preparation twice in one month. What boundary do you set?

9In a design review, four engineers choose a library you would not have selected as an IC, but their comparison covers the agreed requirements. What do you do next?

10A team of eight asks you to approve ticket scope, reviewer choice, and minor design details, creating 12 approval messages in two days. How would you clarify decision rights?

11You inherit six engineers who have had irregular 1:1s, sometimes six weeks apart. What setup do you put in place during your first ten working days?

12A new direct report answers every 1:1 question with fine and the first 20 minutes produce no useful detail. How do you change the conversation?

13After three 1:1s, you notice you speak for about 25 of the 30 minutes and mostly give status updates. What do you change for the next meeting?

14One remote engineer is eight hours ahead, and your current 1:1 lands at 7 p.m. for them every other week. How do you repair the setup?

15In a 1:1, an engineer describes six unrelated frustrations in ten minutes, and you are unsure which one matters most. What do you say and capture?

16Two pull request comments from an engineer read as dismissive, and a teammate stops asking them review questions. How would you give feedback this week?

17An engineer quietly improves the build from 14 minutes to 8 minutes, but only you noticed the dashboard change. How do you recognize the work?

18A junior engineer writes get better at backend as their quarterly growth goal. How would you turn it into a usable plan?

19An engineer asks what separates level two from level three, but the career ladder has 18 broad statements and no examples. What do you do before the next 1:1?

20A remote engineer delivered three customer-requested improvements this month but is rarely mentioned in office conversations. How do you make recognition fair?

Locked questions