Tell me about a time you were blocked by a teammate in a different time zone.
answer
- the block, and what it cost per day
- what you tried before escalating
- the written ask: context, options, decide-by date
- the parallel path you kept building
- result, then the habit you kept
basics
~20 sTests ownership under a dependency you cannot chase in real time. Tell one episode where you converted a blocking question into a reviewable proposal with a default and a deadline, kept building meanwhile, and can name what the delay cost.
how to answer
6 beats- the block, and what it was costingSet the scene in two or three sentences: the dependency, the offset, and a cost per day in money, users or blocked people. Keep situation and task to roughly a fifth of your airtime.
- what you had already triedShow one honest failed attempt before the good one, usually a message that was too thin to answer. This makes the improvement legible instead of making you sound faultless.
- the written ask you sentThis is the bulk of the answer, around sixty percent. Walk through the elements: the options you laid out, the evidence you attached, the default you said you would take, the date, and who you addressed by name.
- how you kept the work moving meanwhileName the parallel path — a stub, a switch you controlled, the next task in the queue — so the listener hears that the block never became idleness.
- the result, in a numberGive the reply time and the outcome the fix produced. A concrete before-and-after here is what stops the story reading as process theatre.
- the habit you keptClose with the one rule you carried forward. Keep result and reflection together to about a quarter of your airtime and stop there rather than restating the story.
your answer
5 story prompts- Pick a block YOU owned in the last 18 months where the decision-maker was several hours away.
- Name what the delay cost per day: money, affected users, or teammates who could not proceed.
- Write down the exact default you proposed and the date you attached to it.
- Note the one thing you built or stubbed while the question was still open.
- This can be your missed-deadline story re-angled, if the delay was a cross-team dependency.
draft and rehearse your own answer in a learn session
go deeper
This probes ownership and judgement when you cannot chase a dependency in real time. The interviewer is checking whether you treat a blocking question as an excuse or as something you can reshape into a reviewable proposal. A strong answer proves you asked well, kept the work moving in parallel, and can state what the delay actually cost.
We were double-billing a slice of orders — around eleven a day — whenever a card authorization was declined and then retried. The fix depended on how the fraud service treats a retried authorization, and the team that owns it is nine hours ahead of me. I had asked in their channel and heard nothing for three days, and every day of silence was eleven more customers to refund. So I stopped asking and started proposing. I wrote a short doc with the three interpretations I could see, attached a failing test and the log lines showing which one their service actually behaved like, and put a line at the top: I will implement the second interpretation on Thursday your morning unless someone tells me otherwise. I tagged the two people who own that service by name, each with a one-line ask, in their channel rather than a direct message. The answer came back the next morning. My read was nearly right and wrong in one edge case, which they explained in two sentences. Meanwhile I had built the fix behind a switch we controlled, so the code was ready and only the branch condition was open. Duplicates went to zero within a week of turning it on. Since then every cross-zone question I send carries a proposed default and a date.
The turn from asking to proposing is the signal, backed by attached evidence and a named owner rather than a channel broadcast. The parallel path keeps it from being a waiting story. Losing the cost-per-day line would flatten the stakes and weaken the whole episode.
I led the move of our charge pipeline onto a new processor: four months, twelve engineers across three regions, and the platform team that owned the connection layer sat in none of our overlap. For the first three weeks we lost days at a time to blocked threads. My read was that the problem was not the other team — it was that we were asking questions in a shape that required them to be awake with us. So I changed how we asked. Every cross-team request had to carry three things before it went out: the context, the answer we would take by default, and a decide-by date. No decide-by date, no send. We kept a decision log in the migration doc, one dated line per resolved question, so someone starting their day could catch up in five minutes instead of scrolling a channel. I also resequenced the plan so no blocked thread sat on the critical path. We stubbed the contract and kept building against it. The cost was mine to pay: I gave up two deep-work mornings a week to hold the one overlap window and answer for the whole migration. At cutover we saw seven duplicate charges across the entire switchover, against ninety-four in the comparable run for the pipeline before it. Median time to clear a cross-region question landed at nineteen hours, down from about three days.
This works because the fix is to the operating model rather than to one message, and the diagnosis names the team's own asking habit instead of blaming the dependency. Naming the personal cost aloud is what makes the ownership credible; without it the answer reads as process for its own sake.
One task, one dependency is plenty. Show that you asked well, proposed a default, and found something useful to do rather than reporting yourself blocked and stopping.
Show you moved the decision, not just the message: options written out, evidence attached, a stated default with a date, and a parallel path so the code was ready when the answer landed.
Show you fixed the pattern, not the instance — the request shape your team now uses, the decision record, and how you sequenced work so a blocked thread never sat on the critical path.
Show a dependency model across orgs: which decisions are pre-delegated, what a default-and-deadline convention looks like at scale, and the cost you accepted to keep it running.
saying these in an interview costs you the question
- The resolution is that you waited and eventually they replied
- Framing the other team as unresponsive rather than asked badly
- No cost attached to the delay, so the block sounds harmless
- Escalating to a manager as the first move rather than the last
- A result with no number and no statement of what changed afterwards
- What would you do differently if you hit that situation again?Pick one real improvement and be concrete. Good candidates: attaching evidence sooner, naming an owner instead of addressing a channel, setting a shorter decide-by window, or flagging the dependency at planning time. Avoid 'I would escalate faster' as the whole answer — it implies your first move was passive.
- How did the other team react to the deadline you set?Show you set a deadline that reads as helpful rather than aggressive. Explain the framing you used — a default you would take, not an ultimatum — and be honest if someone pushed back. Saying how you would adjust the tone for a team that reacted badly is stronger than claiming everyone loved it.
- When would you escalate to a manager instead of handling it yourself?Give a threshold, not a temperament. Something like: when the cost of the delay exceeds what you can absorb, when two teams disagree on priority rather than on facts, or when the same block has recurred. Make clear you escalate with a written summary and a recommendation, not a complaint.