TL;DR: Turn your pain into their incentive: measure the impact precisely, express it in their goals and units, make the fix cheap with data and a draft change, and use a normal peer-to-lead escalation path for routine prioritization. An active severe incident needs immediate coordination and containment.
How to approach it
Without authority your currencies are evidence, translation and favours. Interviewers are checking whether you play the long game or reach for the manager card immediately. Present the ladder you climb and the exact point at which you would actually escalate.
A strong answer
Make the problem undeniable before making it anyone's fault. Pull traces correlating their batch job with your latency cliff, capture p99 before and during their window, and link the last three incidents to their deploys. One chart with deployment markers laid over your latency graph ends most debates; ten adjectives begin them.
Translate into their units, because your SLO is not their budget. Their unbounded connection pool is also their tail latency, their database bill, and the platform quota enforcement arriving next quarter. The pitch that works sounds like this: "Both our services degrade when the nightly job overlaps peak traffic. Here is the correlation. Capping the pool at N and shifting the job two hours fixes your p95 too. I have drafted the config change."
Make fixing cheap. Offer the reproducible benchmark, the draft pull request, the load-test script. People deprioritise expensive vague requests and accept cheap precise ones.
Build a quiet coalition. Usually several teams bleed from the same neighbour. A shared dashboard naming the pattern converts a complaint into a fact, and the second and third victims saying it removes the "this team exaggerates" defence.
Then climb the ladder in order: peer conversation with data, then both leads in one meeting over the same chart, then managers, framed as requesting arbitration rather than filing complaint. Bring proposed resolutions so escalation reads as project management, not tattling. Bank goodwill afterwards: credit them publicly when it lands, show up useful during their next fire. Influence is a balance that compounds; spend it carefully.
If they still cannot prioritise it, take interim self-protection on your side: timeouts, bulkheads, load shedding, off-peak contracts. Shielding your service while their fix queues is not defeat; it is engineering.
What interviewers probe next
"They agreed but nothing happened for a quarter. Now what?" Re-engage with refreshed data and one specific ask, then escalate with the original agreement attached. Agreements carrying dates convert sympathy into commitments.
"Why not just isolate, your own database and namespace, and stop caring?" Sometimes correct, and worth costing honestly: duplicated infrastructure, sync complexity, lost shared capacity. Isolation is a legitimate outcome of the conversation, not a confession of failure.
"Has this ever gone badly for you?" Have one honest stalemate story ready plus what you would do sooner next time, usually engaging them at design review before the dependency existed.
Common mistakes
Opening with frustration instead of measurement, which converts a technical issue into a personality issue.
Escalating a routine prioritization disagreement without first sharing evidence with the owner, or delaying urgent incident escalation just to complete that ladder.
Retaliating without discussion, throttling their traffic or gaming retries. Retaliatory engineering discovered later is trust poison.
Demanding they prioritise your problem while offering nothing: no data, no draft, no shared burden.