Tell me about a time your work was blocked by a dependency another team owned.
answer
- name the dependency and what it blocked
- their roadmap, not their malice
- what you tried before escalating
- the trade that actually moved it
- shipped result, plus the standing fix
basics
~20 sTests whether you move a dependency instead of waiting on it. Answer with the deliverable that was blocked, what you learned about their priorities, the trade or patch that got it moving, and a shipped result.
how to answer
5 beats- the dependency, and what it was blockingOne or two sentences: what you were delivering, what you needed from the other team, and what it cost to not have it. Keep this and the next beat to roughly fifteen to twenty percent of your airtime, and put a date or a number on the stakes so the block is real rather than annoying.
- what you found out about their sideSay what they were committed to and why your request was genuinely expensive for them. Stating their constraint fairly is what separates negotiation from complaint, and it makes everything you did next sound informed rather than pushy.
- the moves you made, in the order you made themThis is the bulk of the answer, around sixty percent. Walk the ladder you actually climbed: a direct ask, a reshaped or narrower ask, an offer of your own labour or a patch, a workaround with a cost, and escalation with a written recommendation. Name which you tried first and why, and be explicit about the one that moved it.
- how it landed, with a numberState the outcome plainly and quantify it: what shipped, how late, what the metric did, what the workaround cost you. Result and reflection together should take about twenty to twenty-five percent of your airtime, so do not let this shrink to one hurried clause.
- what you changed so it would not recurClose on the residue — an agreed interface, a review path, a contribution route, a removal date on a temporary fix, or simply the move you would now make on day one. One sentence of honest self-critique here reads as senior; a flawless story reads as rehearsed.
your answer
5 story prompts- Pick a dependency you genuinely needed, not one you merely wanted, and name what it blocked.
- Write down the other team's actual reason in their words before you draft anything.
- Find one number for the cost of waiting: idle weeks, a missed window, or a metric that stalled.
- Decide which single move unblocked it, and make that the centre of your answer.
- This can be the same story as your missed-deadline answer, re-angled onto the dependency.
draft and rehearse your own answer in a learn session
go deeper
Cross-team dependencies are where ownership stops being about your own backlog. Interviewers use this prompt to see whether you treat another team's roadmap as a constraint to negotiate rather than an obstacle to complain about, and whether you escalate with costs and options instead of frustration. A strong answer shows initiative, influence without authority, and something delivered despite the block.
I was on a six-person web team rebuilding the account-signup form on our product site. Form-abandon rate sat at thirty-eight percent, and most of the drop-off happened at the address step, where validation only fired after you hit submit. The inline-validation behaviour we needed lived in the shared component package another team maintains and publishes as an open-source library, and when I asked, their next feature release was seven weeks out. They were partway through an accessibility audit and genuinely could not reorder it. Instead of arguing for a queue jump, I asked their maintainer what would make my request cheap. His answer reshaped it completely: don't ask for a new component, ask for a validation hook on the field component that already exists. So I rewrote the request as a two-file change, followed their contribution guide, added the tests their audit checklist required, and opened a pull request against their repo. He reviewed it in four days and shipped it in a patch release rather than waiting for the big one. We rebuilt the address step on top of it, and form-abandon came down from thirty-eight percent to twenty-four over the next month. The part I'd carry forward is that I spent the first week waiting politely for a slot, and that week bought nothing. The unlock was asking what shape of request he could say yes to.
The signal is in the reshaping beat: the candidate changed the ask rather than repeating it, and did the work inside the other team's process. Feature-level scope, one clear number, and an honest cost admitted at the end. Dropping the wasted first week or the pull request would downlevel this to patience.
I owned the front-end platform work for a redesign that three product squads were staged behind. All of them needed a token change in the shared component library we publish publicly, and the team maintaining it had frozen the theming layer while they finished a major-version migration. Unfreezing for us would have meant rewriting a migration guide they had already published to outside users, so their no was a reasonable one. I put the trade in writing rather than raising it in a meeting. Waiting cost us about nine engineer-weeks of idle squad time. A temporarily vendored copy of the theming layer cost a merge-back later plus drift risk. I took both options, priced, with a recommendation, to their tech lead and my director in the same thread, and asked for a decision there rather than in two separate conversations. We went with the vendored copy, but on two conditions I insisted on: the copy carried a deletion date in its readme, and I staffed one of my engineers as a reviewer on their migration so we would not be the last to hear when it landed. We merged back eleven days after their release and drift came to three files. What I do differently now is write the cost-of-waiting figure on day one — that is the sentence that turns a scheduling complaint into a decision someone is able to make.
Three things put this at senior: an explicit priced choice between waiting and working around it, escalation as a written recommendation to both sides at once, and guardrails that make the workaround temporary rather than permanent. Remove the deletion date and the merge-back number and this becomes an unowned fork.
Your scope is your own task. Show that you named the block early and precisely, asked the owning team directly instead of guessing, kept your lead informed, and found useful work while you waited. Nobody expects you to renegotiate a roadmap.
Your scope is the feature. Show that you found out what the other team was actually committed to, reshaped your ask into something they could say yes to cheaply, and shipped the feature. The signal is influence without authority, not patience.
Your scope is the team's delivery and what runs in production. Make the wait-versus-build-around call explicitly, with the cost of each path named out loud, and escalate in writing with a recommendation rather than a complaint. Say what standing agreement or interface you left behind so the same block does not recur.
Your scope is how dependencies work across the org. The interesting part is the mechanism: how requests between teams get intaken, prioritised and reviewed, who is allowed to contribute into whose repo, and what changed structurally after your case so other teams stopped queueing behind the same bottleneck.
saying these in an interview costs you the question
- Framing the other team as lazy, blocking or incompetent
- Waiting passively and presenting the slip as someone else's fault
- Escalating to a manager as the first move rather than a later one
- Never saying what the other team's actual priorities were
- A story that ends still blocked, with nothing shipped and no alternative
- Telling it entirely as we, with no action you personally took
- At what point did you decide to escalate?Give a trigger, not a mood: a date you would miss, a cost of waiting you could quantify, or a second missed commitment. Say what you had already tried directly, and that you told the other team you were escalating before you did it. Interviewers are checking that escalation was a considered step with a decision attached, not a reaction to frustration.
- What did the other team say when you asked?Repeat their reason in their words, fairly. The strongest version steelmans it — they had a commitment of their own, a freeze, an audit, a customer. Showing you understood the constraint is what makes the rest of your story credible; if you cannot state their side, the interviewer hears a complaint rather than a negotiation.
- What would you have done if they had simply said no?Have the fallback ready and priced: a narrower workaround, a temporary copy with an explicit removal date, a reduced scope you could ship without them, or a documented decision to slip. Name the cost you would have accepted. Avoid answers where the only fallback is escalating harder.
- How is the relationship with that team now?Answer with evidence rather than assertion: a review path you still use, work you have done for them since, a shared channel or interface that survived. If it ended badly, say so plainly and what you would do differently. A cross-team story with a scorched relationship at the end reads as a win you cannot repeat.
## What is actually being scored This prompt is an **influence test** wearing a scheduling costume. Every engineer past their first year hits a blocker owned by someone else; the interviewer already knows the situation is common, so the situation earns you nothing. What is scored is the sequence of moves between discovering the block and delivering anyway — whether you treated the other team's queue as a constraint you could negotiate with, and whether anything actually shipped. ## Common wordings The same family shows up as: - "tell me about a cross-team dependency that slipped" - "describe a time you needed something from a team that had no reason to prioritise you" - "how do you handle being blocked?" - and "tell me about a time you influenced people you had no authority over" Treat them as one story with different emphases: - the **dependency** wording wants the negotiation; - the **influence** wording wants the persuasion mechanics; - and the open **"how do you handle"** wording still wants one concrete episode, not a policy. ## Weak versus strong on the same facts **Weak:** "The platform team owned the component we needed and they kept deprioritising us, so we slipped a month. Eventually my manager talked to their manager and it got done." Everything in that is passive; the candidate is a narrator of their own project. **Strong, same facts:** "They had committed to an audit they could not reorder, so I asked what a cheap version of my request looked like. It turned out to be a hook on a component they already shipped instead of a new component. I wrote it, they merged it in their next patch release, and we shipped ten days later than planned instead of five weeks." Same block, same other team, completely different candidate. ## The evidence that carries weight Four kinds, in rough order of value. 1. **First**, the cost of waiting stated as a number — idle engineer-weeks, a metric that stayed flat, a window you would miss. 2. **Second**, the reshaping move: proof that you changed the ask rather than repeating it louder. 3. **Third**, the artefact — a pull request, a written trade-off, a scoped agreement, a decision recorded in a thread rather than a hallway. 4. **Fourth**, the residue: an interface, a review path, a contact, a deletion date on a temporary workaround. Candidates who bring none of these are usually telling a story where the block resolved on its own. ## Escalation hygiene Escalation is not a failure and interviewers do not penalise it — they penalise its shape. The version that scores well is: - late enough that you tried directly, - early enough to still have options, - announced to the other team first, - framed as two costed options with a recommendation, - and addressed to whoever can actually decide. The version that scores badly arrives first, is addressed upward only, and asks a manager to want it more than the other team does. ## How the bar moves - At the **earlier rungs** it is enough that you communicated clearly and kept working. - From the **middle**, the interviewer wants the negotiation itself — the trade you found. - From the **senior rung**, they want the explicit decision between waiting, working around, and doing the other team's work, with the cost of each said out loud, and then some structural residue that makes the next occurrence cheaper. - At the **top rung** the story stops being about one dependency at all and becomes about how the org takes dependencies on itself. ## Airtime discipline The most common structural failure here is a long, sympathetic setup about how unreasonable the situation was, followed by a rushed result. Keep the setup under a quarter of your time, spend the bulk on the ordered moves you made, and always land on an outcome with a number and a sentence about what you would do sooner.