Behavioral Scenario #13
The Platform Team Blocker
“Your Q2 feature requires an API from the platform team. It was due in week 8. It's now week 6, and platform just told you it slipped to week 12. Focus: engineering escalation when a dependency team is the blocker.”
The Situation
You're a Staff Android engineer whose team is building a new in-app payments feature. The entire feature depends on a new tokenization API from the internal platform team. Platform committed to deliver this API in week 8 of the quarter. It's currently week 6. Platform's lead just told you informally that due to a reorg and two team departures, the API will slip to week 12. Your quarter ends at week 13. The payments PM has already communicated the feature to a major merchant partner.
Context
- The merchant partner commitment is not contractual but breaking it would damage a key relationship
- Week 12 delivery from platform would leave 1 week for your team to integrate, test, and release
- You could implement a stub/mock tokenization layer that works for internal testing but cannot process real payments
- Another team shipped a similar feature last quarter using a third-party payment SDK — your platform team deprecated it but it still works
- Your manager is currently traveling and out of communication for 48 hours
The Question
“Tell me about a time an external dependency outside your control threatened your team's delivery. How did you respond?”
Response Options
One of these is the strongest response. The others reflect common approaches with real trade-offs.
I waited for my manager to return, then escalated the slip to them to handle with the platform team's leadership.
I met with the platform team lead to understand the specific blocker, identified which parts of the API were truly blocked vs. deliverable earlier, proposed a phased delivery where we received a read-only version of the API by week 9 and the full write path by week 12 — then scoped a reduced feature set that met the merchant partner's core need using the week-9 deliverable.
I proposed reactivating the deprecated third-party payment SDK to meet the deadline, with a commitment to migrate to the platform API in Q3.
I told the PM that the feature would need to slip to Q3 due to the platform dependency and asked them to communicate the change to the merchant partner.
The Debrief
Why the Best Response Works
Answer B works because it breaks the binary assumption ('API ships on time' vs. 'feature slips') into a negotiable space. Most dependency slips are partial — some parts of the API are readier than others. Finding the early-deliverable slice and scoping your feature to it is the Staff engineer move. The merchant relationship is preserved because you delivered the core value, not the full spec.
What to Avoid
Waiting for your manager is the most common response when the news is bad. But 48 hours of inaction on a week-6 discovery with a week-12 deadline is not prudence — it's the loss of the only runway you had to find alternatives. On the other hand, unilaterally adopting the deprecated SDK without platform alignment is a shortcut that creates a different kind of technical debt and org tension.
What the Interviewer Is Probing
The interviewer is evaluating cross-team dependency management: can you find options under constraint? Can you negotiate across team boundaries without authority? Can you scope a feature to the achievable without abandoning the user value? These are Staff-level capabilities that Senior engineers often lack.
SOAR Structure
**Situation:** Payments feature requires platform tokenization API by week 8; platform slips to week 12; merchant partner communicated Q2 delivery. **Obstacle:** Manager unavailable; 1-week integration window if week-12 holds; merchant relationship at risk. **Action:** Met with platform lead; identified read-only API available week 9; proposed phased delivery; scoped feature to read path + manual write as interim; communicated reduced scope to PM with clear upgrade path in Q3. **Result:** Feature shipped week 10 with read-path payments; merchant partner satisfied with core feature; full write path in Q3.
The Learning Arc
"This taught me that dependency slips are almost never all-or-nothing. Platform teams rarely have nothing to give — they have a partial deliverable that's closer than the full spec. Since this incident, I schedule a dependency health check with every cross-team dependency at the quarter midpoint — not to check on them, but to find out what I can unblock by adjusting my requirements."
IC Level Calibration
Identify the blocker, scope a stub implementation for integration testing, and escalate to your manager with 2–3 concrete options (stub + scope reduction, deprecated SDK, week-12 slip with accelerated integration).
Negotiate with the platform team to find what's deliverable early, propose a phased delivery contract, scope the feature to what meets the merchant's core need with the week-9 partial API, and document the risk formally for leadership.
Same as staff, plus: identify the organizational pattern (platform dependencies slipping without early warning) and drive a dependency management process improvement — an early warning SLO or cross-team dependency review — to prevent recurrence across the org.
Company Calibration
Amazon
LP: Deliver Results — find a path when the default path is blocked
Cross-functional influence: remove blockers without authority
Lyft
Say it straight: surface blockers early with proposed solutions, not just problems
Stripe
Operate with urgency while maintaining quality
Want to pick your response and see the full analysis?
Practice This Scenario Interactively