Behavioral Scenario #05
Three Critical Projects, One Engineer
“Your VP wants you on three VP-visible initiatives. All critical. All this week. You have 40 hours.”
The Situation
You're a Principal Android engineer. In a single week, you've been pulled into: (1) leading the technical design for an externally-facing SDK the company plans to launch in Q2, (2) unblocking a junior team stuck on a performance regression affecting a key retention metric, and (3) contributing to an architectural review for a platform migration with a major partner deadline.
Context
- The SDK design requires 3–4 days of focused, uninterrupted deep work — context-switching degrades quality significantly
- The junior team's unblocking is estimated at 2–3 days of pairing — without it, they're blocked for the sprint
- The architectural review requires 4 hours of reading plus a 90-minute meeting
- All three items have VP-level visibility — failure to deliver on any could be noticed at the executive level
- There is no one else at your level who can lead the SDK design
The Question
“Tell me about a time you had to manage competing high-priority projects with limited time. How did you decide what to do?”
Response Options
One of these is the strongest response. The others reflect common approaches with real trade-offs.
I worked extra hours to make progress on all three simultaneously, prioritizing based on which felt most urgent each day.
I told the VP I could only commit to the SDK design this week and asked them to reassign the architectural review and junior team unblocking to others.
I wrote a one-page scope and timeline document for all three items, called out the trade-offs and risks of parallel execution explicitly, and brought it to the VP with a recommendation: I own the SDK design and architectural review this week, and I identify and brief a senior engineer to pair with the junior team on the performance issue.
I quietly delegated the junior team unblocking to a senior engineer without looping in the VP, then focused on the SDK design and architectural review.
The Debrief
Why the Best Response Works
Answer C works because it demonstrates the full Principal-level loop: clarity (scope doc), judgment (recommendation, not just a problem statement), and organizational leverage (delegation with briefing responsibility). Bringing the VP a document with explicit trade-offs shows you're operating at the executive layer — you've done the thinking they'd have to do themselves.
What to Avoid
Working extra hours without a prioritization framework is the most common mistake. At Principal level, 60-hour weeks signal execution problems, not dedication. The right signal is: 'I can do all three at 80% quality, or I can recommend the right two at 100% quality — which do you need?'
What the Interviewer Is Probing
The interviewer is testing strategic prioritization and executive communication. Can you operate at the level of information that your VP needs? Do you own the coordination problem or hand it back? Principal engineers are expected to be force multipliers — the answer should show how you achieved more than you could alone.
SOAR Structure
**Situation:** Three VP-visible items in one week — SDK design (3-4 days), junior team unblocking (2-3 days), architectural review (5 hours). **Obstacle:** 40-hour week, only one of me, all three have executive visibility. **Action:** Wrote a one-page scope document with explicit trade-off analysis; recommended: SDK + review for me, senior engineer (whom I'd brief) for the junior team. Brought it to the VP for alignment before committing. **Result:** VP approved plan; SDK delivered on schedule; junior team unblocked within the week; architectural review completed.
The Learning Arc
"This taught me that the most expensive thing at Principal level is not choosing. Trying to do everything at 60% quality costs more trust than delivering two things at 100% and being transparent about the third. I now do a weekly one-pager for every multi-commitment sprint — it's the fastest way to surface conflicts before they become surprises."
IC Level Calibration
Raise the conflict explicitly to your manager, get alignment on priority, and execute on the top-priority item fully rather than spreading thin.
Create a written scope document for all three, propose a specific prioritization recommendation, and secure explicit buy-in from the relevant stakeholders before committing to any delivery.
Identify the scoping conflict early, write the one-pager, bring a recommendation to the VP, and own the delegation plan for the deprioritized items. Communicate the trade-offs and risk explicitly so leadership can make an informed choice, then commit fully to the agreed plan.
Company Calibration
Amazon
LP: Deliver Results + Bias for Action
Googleyness: Logical thinking + influence at scale
Nvidia
Speed and agility + intellectual honesty about capacity
Meta
IC6 signal: operates strategically across multiple teams
Want to pick your response and see the full analysis?
Practice This Scenario Interactively