Interview Drills — Stakeholder & Risk

Open-ended questions on the part of the job interviewers probe hardest: keeping the right people aligned, seeing trouble coming, and delivering bad news without losing trust. 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 "tell me about a time" stories — they test whether you have a mechanism for stakeholders, RAID, escalation, conflict, and slipping timelines, not just instincts. The app can role-play these as mock interviews (see mock-interview.md).

The universal structure here: Get the facts straight → map who's affected and what they care about → decide and act (mitigate / escalate / mediate) → communicate early, honestly, and tailored to the audience, with options not just problems. The two non-negotiables an interviewer is hunting for: no surprises (raise problems before the date passes) and bring options, not just bad news. You lead without authority, so a shared, agreed view of reality is your main lever.

D1

difficulty: easy
concept: stakeholder-mapping Walk me through how you'd identify and manage the stakeholders on a new project. There are a lot of them and they don't all want the same thing.
Framework: List everyone affected or interested (sponsor, team, dependent teams, customers, other departments) → map each on influence × interest → set an engagement level per quadrant (high influence + high interest = manage closely; high influence + low interest = keep satisfied; low influence + high interest = keep informed; low/low = monitor) → for each, capture what they actually care about and the cadence/channel that fits → revisit as the project evolves, since power and interest shift.
Model answer: "I'd start by brainstorming every stakeholder, not just the obvious ones — sponsor, my team, the two teams we depend on, support, legal. Then I'd put them on an influence-versus-interest grid so I'm not treating them all the same. The sponsor is high influence, high interest, so I manage them closely with a weekly one-pager and a heads-up on anything material. A senior exec who's high influence but low interest I just keep satisfied — a brief monthly note, no detail dump. The team is high interest, so they get the full picture daily. For each, I'd note what they specifically care about — the sponsor wants date and budget, support wants the launch-readiness checklist — and match the cadence to that. And I'd redo the map at milestones, because interest spikes near launch."
Rubric: Strong answers use a real prioritization tool (influence × interest) rather than treating all stakeholders equally, tailor what and how often to each group, and capture each stakeholder's actual concern. Weak answers list stakeholders with no segmentation, propose the same "send everyone the status report" treatment for all, or forget that the map changes over time.

D2

difficulty: medium
concept: raid-log Your project doesn't have a RAID log. How would you set one up, and what's the difference between the items in it?
Framework: Define RAID — Risks (might happen), Assumptions (things we're treating as true), Issues (already happening), Dependencies (we need something from someone else) → explain why each is tracked differently → for risks: log likelihood × impact, an owner, and a response (avoid / reduce / contingency); for issues: owner + resolution + due date; for assumptions: validate or they become risks; for dependencies: the exact thing needed and the need-by date → keep it living, reviewed on a cadence, not a one-time document.
Model answer: "RAID is one register with four kinds of entries. A risk is a potential future problem — I'd log it with a likelihood and impact, an owner, and a planned response: avoid it, reduce it, or have a contingency. An assumption is something we're betting is true — 'the vendor API is stable' — and each one is a risk in disguise until validated, so I track them so they don't silently break. An issue has already happened, so it needs an owner and a resolution date now, not a probability. A dependency is something we need from another team — I log the exact deliverable and the real need-by date, because that's where projects quietly stall. The point isn't a pretty document; it's a living list I review every week so nothing rots. The most dangerous risk is the one nobody wrote down."
Rubric: Strong answers correctly distinguish all four (especially risk vs. issue, and that assumptions decay into risks), attach an owner and a response/date to each, and treat the log as a living, reviewed artifact. Weak answers blur risk and issue, list items with no owner or response, or describe RAID as a checkbox document created once and never revisited.

D3

difficulty: medium
concept: escalation Something on your project is stuck and you can't resolve it at your level. When and how do you escalate — without looking like you can't do your job?
Framework: Reframe escalation as a tool, not a failure → escalate when it's outside your authority, blocking the critical path, or you've exhausted what you can do → first exhaust the level below (talk to the owner directly) → escalate early, before it's a crisis → go to the right person (the one who can actually decide), with a crisp package: the situation, the impact, what you've already tried, the options, and the specific decision you need → confirm the outcome in writing and close the loop with everyone affected.
Model answer: "Escalation isn't admitting defeat — it's routing a decision to whoever owns it. I escalate when something's blocking the critical path, it's above my authority, and I've already tried to fix it peer-to-peer. The key is timing and framing: early, and with options. I wouldn't message an exec 'Team B won't help us' — that's a complaint. I'd bring 'Here's the blocker, here's the milestone it threatens, here's what I've already tried, here are two options, and here's the one decision I need from you by Thursday.' I go to the person who can actually unblock it, not just the nearest senior name. Then I confirm the decision in writing and tell everyone downstream. Done this way, escalating early with a clean ask makes me look more in control, not less."
Rubric: Strong answers treat escalation as legitimate and time-sensitive, show they tried the lower level first, target the right decision-maker, and arrive with impact + options + a specific ask (not a complaint) — then close the loop. Weak answers escalate too late (after it's already a crisis), dump the problem with no options, escalate to the wrong/highest person for cover, or treat escalation as something to avoid at all costs.

D4

difficulty: medium
concept: communicating-bad-news You have to tell your executive sponsor that the budget is going to overrun by 20%. Walk me through exactly how you deliver that conversation.
Framework: Tell them early — before it's irreversible, never let them find out elsewhere → lead with the headline, not a slow build ("I need to flag a budget risk") → be specific on the size and the cause (the why, on the critical path) → bring options with trade-offs (cut scope to hold budget / accept the overrun for a clear reason / phase the spend) → give your recommendation → state the decision and the date you need it → no blame, no burying it in a deck → confirm in writing and adjust the baseline.
Model answer: "First, timing: the moment I'm confident it's real, not after the money's spent. I'd open with the headline so they're not waiting for it — 'I need to flag a 20% budget overrun and walk you through options.' Then the cause, specifically: the integration took two sprints longer than estimated, that's what's driving it. Crucially I don't stop at bad news. Option A: we cut the two lowest-value features and hold the original budget. Option B: we accept the overrun because the scope it buys is worth it — here's the case. Option C: we phase it, deferring part of the spend to next quarter. My recommendation is A, because it protects the budget and the date. Then: 'The decision I need from you is which path, ideally by Friday.' I keep it tight, no jargon, and I send a one-paragraph written confirmation after. Delivering hard news cleanly is exactly what earns the trust to run bigger budgets."
Rubric: Strong answers communicate early and proactively, lead with the headline, are specific about size and root cause, and bring options + a recommendation + a clear ask — calm and blame-free, confirmed in writing. Weak answers delay until it's too late, bury the number, present only the problem with no path forward, get defensive or blame the team, or overwhelm the exec with technical detail instead of the impact and the decision.

D5

difficulty: hard
concept: conflict-mediation Two senior engineers on your team are in open conflict over a technical direction. It's stalling the work and the team is taking sides. You're not their manager and you can't decide the technical question yourself. What do you do?
Framework: Address it early — don't let it fester → separate the people from the problem; understand each position and the underlying interest behind it (what each is really protecting) → get the disagreement onto shared facts/criteria, not personalities → find common ground (they share the same goal) → drive to a decision: agree decision criteria, or bring in the right technical decision-maker (a tech lead/architect) since it's not yours to call → make the call explicit, get buy-in, and move forward → protect the team from the fallout and reset the norm.
Model answer: "I'd move on it fast — conflict left alone spreads, and the team's already choosing sides. First I'd talk to each one separately to understand not just their position but why — often it's not really 'my design vs. yours,' it's one's worried about timeline and the other about long-term maintainability. Naming the real interests shrinks the fight. Then I'd get them in a room focused on shared criteria, not on each other: what does the project actually need to optimize — speed, scale, reversibility? That turns an ego clash into an evaluable trade-off. I can't make the technical call and shouldn't pretend to, so if criteria don't settle it, I'd frame the options cleanly and bring in the tech lead or architect to decide, then make that decision explicit so it's settled, not simmering. Afterward I'd make sure both feel heard and the team knows we disagree on ideas, not people. My job is to unblock the work and keep the team healthy, not to win the argument."
Rubric: Strong answers move early, dig past positions to underlying interests, shift the conflict onto shared criteria/facts, and route the actual technical decision to the right owner (not the PM) while still driving closure and protecting team cohesion. Weak answers avoid the conflict, pick a side or try to decide a technical question outside their competence, "escalate to the boss" reflexively without mediating first, or resolve the immediate spat but ignore the team dynamics it created.

D6

difficulty: hard
concept: stakeholder-alignment Two senior stakeholders want contradictory things from your project — one wants to ship fast and narrow, the other wants it broad and polished — and each keeps lobbying you separately. You have no authority to overrule either. How do you get to a single direction?
Framework: Don't relay messages between them or quietly pick one → surface the conflict into the open instead of absorbing it → anchor on the shared higher-level objective and what success actually means → make the trade-off explicit and undeniable (fast+narrow vs. broad+polished costs X in time/scope) → get them in the same room (or the steering group) to decide together against that objective, since the decision is theirs, not yours → document the agreed direction and the trade-off accepted → hold the line on it when lobbying resumes, pointing back to the joint decision.
Model answer: "The trap is becoming the messenger or silently siding with the louder one — then I own a decision that isn't mine and the loser feels blindsided later. So I'd stop the side-channel lobbying by bringing it into the open. First I'd anchor both on the same question: what is this project actually for, and how will we judge success? Then I'd make the trade-off concrete — 'fast and narrow ships in six weeks and covers these users; broad and polished is twelve weeks and covers everyone' — so it's a real choice, not a vibe. Because I can't overrule either, I'd get them in one room, or take it to the steering group, and have them decide against the shared objective. I facilitate; they own the call. Then I document the chosen direction and the trade-off they accepted, and when one of them relitigates it next week, I point back to the joint decision. My value here is a single agreed version of reality, not picking the winner."
Rubric: Strong answers refuse to absorb or secretly arbitrate the decision, surface the conflict openly, anchor on a shared objective + a concrete trade-off, and drive a joint decision (room or steering group) that they then document and hold to. Weak answers shuttle messages back and forth, quietly favor the more senior or louder stakeholder, try to please both (guaranteeing scope creep and a miss), or pretend the decision is theirs to make when they have no authority.