TL;DR: Establish the shared failure with evidence, propose a bounded investigation or fix and agree on ownership and timing. Contain impact on your service while the dependency team works; escalate urgent risk according to its consequence rather than waiting through a routine prioritization ladder.
How to approach it
Separate an active incident from a recurring planning disagreement. State the dependency and the user impact you can demonstrate. Do not assume a correlated deployment proves the other team caused the failure.
A strong answer
Start with a reproducible observation. In a fictional exercise, an API's database wait time rises during a reporting team's nightly batch. Both services use the same database. Deployment markers and traces establish that the events overlap, but the database could also be running maintenance at that time. Present the correlation as a reason to investigate together.
Ask the dependency owner to inspect the same interval and compare the work each service is doing. The exercise reveals the batch opening 150 connections during a period when the API needs up to 100, while the shared database permits 200 application connections. Those maxima suggest potential contention, but connection count alone does not prove which queries hold resources or whether every maximum occurs together. Examine active sessions, waits and query durations before prescribing a pool size.
Recommend a bounded test in a suitable environment or agreed production window. For example, lower the batch's concurrency while holding a comparable dataset and observing API latency, database waits and batch completion time. Agree on the stop condition and recovery action before changing the shared workload. “Cap the pool and everything improves” is a hypothesis until those outcomes are checked.
The other team has a deadline too. Suppose reducing concurrency restores the API but causes the batch to miss its morning reporting cutoff. The experiment has identified a tradeoff rather than completed the fix. Consider a different schedule, more efficient queries, workload isolation or capacity, and show each option's operating cost and dependency. Ask the service owners to choose if both deadlines cannot be met with the available resources.
A useful request is concrete: “We can reproduce the overlap with this dataset. I can supply the trace comparison and run the API checks if your team owns the batch-concurrency change. Can we review both completion deadlines together after the test?” This distributes work according to knowledge and permissions, without making help conditional on a favor being returned.
Record the agreement and next decision date. If routine work slips, refresh the impact evidence and bring both leads the unresolved choice. If users are currently affected, invoke incident coordination and the necessary containment immediately. A severe outage should not wait for a sequence of peer meetings merely to demonstrate patience.
On your side, evaluate protection such as a bounded connection pool, deadlines and admission control. These can limit cascading damage but may reject more requests or leave useful work unfinished. Verify the user outcome and explain the degraded behavior. Do not retaliate by silently changing the other team's permissions or throttling its work outside your authority.
After a change, compare similar workloads and include the reporting deadline in the result. Credit the dependency team's contribution accurately. If the tradeoff remains unresolved, an honest account can explain the interim containment and the decision still awaiting an owner.
What interviewers probe next
“They agreed and nothing happened.” Check whether the blocker is capacity, unclear ownership or a changed priority, then escalate the unresolved decision with evidence and proposed options. Repeated reminders without a decision request may not change the plan.
“Why not isolate the database?” Cost the migration and its ongoing ownership, including data synchronization if needed. Isolation may be justified, but a new database is not a free substitute for understanding the shared workload.
“Your initial diagnosis was wrong.” Correct the record with the evidence that changed it and continue the investigation jointly. Avoid preserving the original accusation in a dashboard or ticket after the facts no longer support it.
Common mistakes
A chart with coincident lines cannot establish causality by itself. Explain the comparison or intervention that discriminated between hypotheses.
A solution that meets your API objective by breaking the batch deadline moves the failure. Report both outcomes and identify who accepted any remaining tradeoff.