Interview Drills — Scenario / Execution

Open-ended "what do you do" situations that test real program-management judgment under pressure. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). These aren't trivia — they probe whether you can stay calm, surface trade-offs honestly, and keep stakeholders aligned when a project gets messy. The app can role-play these as mock interviews (see mock-interview.md).

The universal execution structure: Clarify the real goal and constraints → name the trade-off using the triple constraint (scope / time / cost, with quality in the middle) → decide and recommend an option → communicate it early, honestly, and to the right people. Almost every "what would you do?" answer follows clarify → trade-off → communicate. Never silently agree to the impossible.

D1

difficulty: easy
concept: scope-time-cost A senior stakeholder demands an extra feature in the launch, but the deadline can't move and you have no extra budget. What do you do?
Framework: Don't say yes or no on the spot → clarify what the stakeholder actually needs and why (the underlying goal, not the literal request) → frame it as a triple-constraint trade-off (scope, time, cost — pick the one that can flex) → present 2–3 concrete options with consequences → let the decision-maker choose, then confirm in writing.
Model answer: "I wouldn't just agree — that's how you miss quietly. I'd ask what problem this feature solves and how urgent it really is. Then I'd lay out the trade-off: time and cost are fixed, so scope has to flex. Option A: we cut a lower-priority item from this release to make room. Option B: this feature ships in a fast-follow two weeks later. Option C: we add contractors to hold scope, but that costs $X. My recommendation is B — it protects the date and quality. I'd get their call and send a one-line written confirmation so we're aligned."
Rubric: Strong answers refuse to silently absorb the work, restate the request as a triple-constraint trade-off, offer concrete options with consequences, and push the decision to the right owner while confirming in writing. Weak answers either cave ("I'd find a way to fit it in") or flatly refuse, with no options, no trade-off, and no clarifying question.

D2

difficulty: medium
concept: risk-and-issues Two weeks before a milestone, you realize Team A is blocked waiting on an API that Team B won't finish for another month. How do you handle this dependency?
Framework: Treat it as an issue (it's already real), not just a risk → clarify the exact dependency and the true "need-by" date → assess impact on the critical path and the milestone → generate options to unblock (mock/stub the API, re-sequence work, partial delivery, renegotiate B's priorities, add help to B) → recommend one → escalate and communicate to both teams and stakeholders early.
Model answer: "First I'd get precise: what exactly does Team A need from that API, and what's the real date it blocks them? Often you don't need the whole thing. I'd propose Team B ships a stubbed or partial endpoint matching the agreed contract so A can keep building against it, with the full version later. In parallel I'd check whether A has off-critical-path work to pull forward so they're not idle. If B genuinely can't, that's a re-prioritization call I'd escalate with options and impact — I wouldn't let two teams quietly wait. Either way I'd flag the milestone risk to stakeholders now, not in two weeks."
Rubric: Strong answers nail down the exact dependency and need-by date (not the whole API), look for ways to decouple the teams (stub/contract/re-sequence), think about the critical path, and escalate with options early. Weak answers just "ask Team B to hurry up," let Team A sit idle, or hide the milestone risk until it's too late.

D3

difficulty: medium
concept: risk-and-stakeholder-management Your lead engineer — the only person who understands a critical system — resigns mid-project. What's your plan?
Framework: Switch from risk to issue mode → contain immediately (knowledge capture before they leave) → assess true impact on scope and critical-path timeline → mitigate (knowledge transfer, pair a successor, reduce bus-factor, re-plan) → communicate honestly to stakeholders with a revised plan, not panic → fold the lesson back into the risk register.
Model answer: "My first priority is the knowledge in their head before their last day: documented handover, recorded walkthroughs, and pairing them with whoever inherits the system so it's not a cold handoff. Then I'd reassess — which deliverables sit on this person, and what's now at risk on the critical path? I'd re-plan realistically: maybe a non-critical feature slips so the team can absorb the system. I'd give stakeholders an early, honest heads-up with a revised timeline and the mitigation, rather than promising nothing changed. And I'd treat single-person dependencies as a standing risk so this hurts less next time."
Rubric: Strong answers move fast on knowledge capture before the person leaves, reassess impact on the critical path, re-plan realistically, and give an early honest update — plus address the underlying "bus factor" risk. Weak answers either downplay it ("we'll manage") or catastrophize, with no knowledge-transfer plan and no stakeholder communication.

D4

difficulty: medium
concept: scope-time-cost Halfway through the project, you notice scope has quietly crept — small "while you're at it" requests keep getting absorbed, and the team is falling behind. What do you do?
Framework: Name it as scope creep and quantify it → trace where the additions came from (no formal decision = the real problem) → re-anchor on the original goal and baseline → install a lightweight change-control habit (every addition is a trade-off, decided by an owner) → communicate the impact and re-baseline with stakeholders.
Model answer: "I'd first make the invisible visible: list every item that's been added since the baseline and show, in days, how much it's added to the plan — that turns 'we're vaguely behind' into 'these eight extras cost three weeks.' The root cause is that changes slipped in without a decision. So I'd introduce a simple rule: any new request is fine, but it's a trade-off — it either replaces something, moves the date, or adds cost, and a named owner decides. Then I'd take the impact to stakeholders and either cut back to the original scope or formally re-baseline. The fix isn't saying no to everything; it's making each change a conscious choice instead of a quiet default."
Rubric: Strong answers quantify the creep against a baseline, diagnose the root cause (changes with no decision/owner), and install a lightweight change-control process where every addition is an explicit trade-off — then re-baseline transparently. Weak answers blame the team, propose just "working harder," or want a heavyweight bureaucratic process that the team will route around.

D5

difficulty: hard
concept: risk-and-stakeholder-management A key milestone is going to slip — you're now confident you'll miss it by about two weeks. The executive sponsor still thinks it's on track. Walk me through what you do.
Framework: Confirm the facts and the size of the slip before you raise alarms → communicate early and honestly — never let the date pass first → bring options, not just bad news (recover scope, add resource, or move the date) → tailor the message to the audience (sponsor wants impact + the ask, team wants the plan) → update status (e.g., RAG to amber/red) and reset expectations downstream.
Model answer: "The cardinal rule is no surprises, so I'd tell the sponsor now, not after the date passes — surprises destroy trust. But I'd never walk in with only bad news. I'd verify the two-week slip, find what's driving it (usually a critical-path task), and bring options: Option A, cut a lower-priority feature to hold the date; Option B, add a person to a bottleneck if that genuinely helps; Option C, move the milestone two weeks and protect quality. For the sponsor I'd keep it tight — 'here's the situation, the impact, my recommendation, and the decision I need.' I'd flip the status to amber, then make sure anyone depending on that date downstream knows early too. Delivering this well is what builds the trust to run bigger things."
Rubric: Strong answers communicate before the deadline passes, lead with options and a recommendation rather than just the problem, tailor the message to the executive (impact + ask, not detail dumps), and reset downstream expectations. Weak answers hide the slip hoping to recover, dump the problem with no options, or only tell the team and forget the sponsor and downstream stakeholders.

D6

difficulty: hard
concept: project-vs-program You're a program manager. One project in your program is sliding and threatens the launch of two dependent projects, but each project lead insists their piece is fine in isolation. How do you act at the program level?
Framework: Zoom out to the program objective, not any single project → map the cross-project dependencies and find the true critical path across projects → make the program-level impact undeniable (the slip in project X breaks Y and Z) → drive a trade-off across the portfolio, not within one project (re-sequence, re-prioritize, shift resources between projects) → align all leads and the steering group on one shared picture, since you have no direct authority.
Model answer: "At the program level my job is the overall objective, so I wouldn't argue project-by-project. I'd draw the cross-project dependency map and show that even if each lead is locally fine, project X's slip pushes the launch of Y and Z — that's the program critical path. With that shared picture, I'd drive a portfolio trade-off: maybe we shift people from a project with slack onto X, re-sequence so Y and Z do independent work first, or de-scope X's launch to just what Y and Z need. Because I have no authority over the leads, the lever is a single agreed view of reality plus a steering-group decision. I'd surface this early with options rather than let three projects each declare 'we're fine' into a collective miss."
Rubric: Strong answers operate at the program altitude — optimizing the overall objective and the cross-project critical path rather than any one project — make dependencies visible, drive trade-offs across projects, and align leads via a shared picture given the lack of authority. Weak answers stay stuck inside one project, accept "we're each fine" at face value, or try to command leads they don't control instead of aligning them.