Tell me about a time another team was blocking you and you had no authority over them.

The question is about a relationship, not a blocker

Interviewers reach for this one because most delivery risk in any organisation of more than about forty engineers lives between teams rather than inside them, and almost none of it can be resolved by authority. What they are grading is whether you can move something you do not control while leaving the other team willing to help you again next quarter. Those two halves are in tension, and that tension is the whole question. Getting a dependency unblocked by burning the relationship is a loss disguised as a win, and interviewers who have run platform teams recognise it instantly.

The commonest answer treats the other team as an obstacle with no interior life: they were slow, we were blocked, I escalated, we got what we needed. Every clause of that may be true and it still scores poorly, because nothing in it shows you understood what you were asking someone to give up.

Start by finding out what they are optimising for

Before deciding a team is being unreasonable, find out what they are being measured on this quarter, who else is queueing, and whether your request is even visible to the person who sets their priorities. A surprising share of blocks turn out to be one of these:

• They never received the request as a request. It was mentioned in a channel, or filed as a ticket in a backlog nobody grooms, and no human ever decided to decline it.
• They are working to a commitment made above them and cannot reprioritise without their own manager reopening it.
• They are three people supporting eleven teams and are triaging by whoever shouted last, which means shouting is the interface whether anyone intended that or not.
• What you asked for is much larger than you think, because of a constraint invisible from outside.

Each needs a different move, and you cannot pick the move without asking. Saying in an interview that you went and understood their roadmap before forming a view is one of the cheapest strong signals available here, because most candidates go straight to persuasion.

Make the cost legible, in their units

Your job is then to give whoever prioritises their work something they can act on. Frustration is not actionable; a dated consequence is. The difference is mostly framing, and the second column below is not longer, only more useful.

Weak framing	What to say instead
"We are blocked on you and it is urgent."	"If the consent API is not available by the 14th, the clinician pilot moves from March to May, and the two research sites already have dates."
"This has been open for six weeks."	"This is the fourth week it has been in the backlog; I want to check whether it has been declined rather than delayed, because we would plan differently."
"Can you prioritise this?"	"Can I take it off you? I will write it against your interface and you review it, or we take a temporary shim on our side and remove it in Q3."

The third row does most of the work in practice. Offering to do the work yourself, or to carry the ugly temporary version on your own side, converts the conversation from a demand for their capacity into a negotiation about review time, which is far cheaper for them to say yes to. It also tells the interviewer something they cannot get any other way: that you would rather solve the problem than win the argument about whose problem it is.

Escalation, done in a way you can survive

Escalation is legitimate and candidates are too frightened of it. What matters is not whether you escalated but how. Go to their manager rather than around to yours, go with the other engineer knowing it is happening and preferably in the room, bring the decision you want rather than a complaint, and frame it as prioritisation between two things the organisation wants rather than as a failure by a person. An escalation that surprises the team you depend on costs you every future favour.

The other half is having a plan that does not require them: stubbing the interface behind a facade, taking the three weeks of unblocked work first, agreeing a contract you could code against before their implementation existed. That is what separates someone who manages dependencies from someone who reports them.

A pattern to adapt, not to recite

The facts here are illustrative. Yours will be different, and the shape is the transferable part.

"We were building a research data platform and needed the identity team's consent service to expose which studies a patient had agreed to. Without it we could not release a single dataset, and two research sites had dates in March.

It had sat in their backlog for about a month, so before pushing I asked their tech lead for half an hour to understand their quarter. It turned out two things: our request had never actually been declined or accepted, it had just never been looked at, and they were mid-way through a migration their director had committed to, with four other teams queueing behind it. So they were not being obstructive, they had no mechanism for a request like ours to be seen.

I did three things. I rewrote the ask as a one-page note with the date, what slipped if we missed it, and the two research sites by name, which their lead could take to their own prioritisation meeting rather than having to advocate for me from memory. I offered to write the endpoint against their interface with their review, which they preferred to specifying it for us. And I reordered our own work so the three weeks of ingestion that did not need consent data went first, and put a hardcoded consent stub behind an interface so nothing downstream was waiting.

They took the offer, we got a review slot inside two weeks, and it shipped about ten days before we needed it. I did escalate once, in week two, but I did it by asking their lead whether we should put it to both our managers together, and we sent one joint note. The part I would do differently is that I should have written the one-pager in the first week rather than the fourth. I spent three weeks assuming the ticket was doing work that tickets do not do.

The relationship held up. We ended up sharing an on-call rota for the consent integration the following year, which would not have happened if I had gone round them."

Read what that answer keeps in. The other team's reasoning is stated fairly and turns out to be legitimate. The escalation is joint and dated. There is a concrete self-help move. And there is a mistake volunteered, which is what makes the rest of it credible.

Where these answers quietly fail

The failure is not aggression, it is the answer that ends at the unblocking. Interviewers are trying to predict what working with you across a boundary is like on an ongoing basis, so an account that finishes the moment you got your endpoint has answered a smaller question than the one asked. Say what the relationship was like afterwards, and if it was damaged, say that and say what you learned from it. The candidate who admits they won the dependency and lost the team is more hireable than the one who never mentions the aftermath at all.