A dependency team shipped something that broke you.

What is actually happening (the mental model).

Your first job is to protect your users — mitigate or roll forward regardless of whose change it was. Then you engage the other team collaboratively, not with a blame email — "we got broken by a change, let's figure out how together" — because the relationship outlasts this one incident and blame makes the next one worse. The real fix is systemic: they were able to break you because there was no contract test, no API versioning, or no change notification. So you drive a contract-testing agreement or a versioning/deprecation policy so neither team can silently break the other again. You turn the friction into a shared guardrail — far more valuable than winning the fault argument.

How to work through it.

1. Protect your users first — mitigate/roll forward.
2. Engage collaboratively — no blame; the relationship outlasts the incident.
3. Fix the contract gap — contract tests, API versioning, deprecation policy, change notifications.
4. Turn friction into a shared guardrail.

The trap that less-experienced engineers fall into.

Sending a blame email (poisons the relationship for the next incident), and fixing only the immediate breakage without closing the contract gap that let it happen — so it recurs.

🎯 Interviewer follow-up questions you should expect.

• "Another team broke your service — what do you do?" You mitigate for your users first, engage without blame, and then fix the systemic contract gap (versioning/contract tests) so it can't recur.
• "How do you prevent it recurring?" Contract tests, API versioning, and a deprecation/change-notification policy.

Another team is a bottleneck — a security review, an access request, a platform change you're waiting on.

What is actually happening (the mental model).

You start by understanding their world — the security team isn't being difficult, their incentive is managing risk, and if you show up with a threat model already done and a minimal, well-scoped request, you've made it easy for them to say yes. You invest in the relationship before you're blocked, so you're a known collaborator, not a random ticket. Where they're a recurring bottleneck, you propose a self-service guardrail — "give us a paved path with these controls baked in and you don't have to review every change" — which solves their scaling problem and your speed problem at once. If you must escalate, you frame it around shared goals, never "this team is slow."

How to work through it.

1. Understand their incentives (risk, not obstruction) and do their work for them (threat model, minimal-diff request).
2. Build the relationship before you need it.
3. Propose a self-service guardrail so they don't have to gatekeep every change.
4. Escalate via shared goals, not complaints.

The trap that less-experienced engineers fall into.

Treating the other team as an obstacle (adversarial), dumping an under-scoped request on them, and escalating as "this team is slow" (burns the relationship) instead of proposing a guardrail that helps both.

🎯 Interviewer follow-up questions you should expect.

• "A security team is blocking you — how do you handle it?" You understand their incentives, do their work for them (threat model, minimal request), and propose a self-service guardrail so they don't gatekeep every change.
• "They're a recurring bottleneck — structural fix?" A paved path with controls baked in — solves their scaling and your speed at once.

You want teams to adopt a common practice — a logging standard, a CI template, a tagging convention.

What is actually happening (the mental model).

You can't mandate your way to cross-team adoption without authority — mandates breed malicious compliance. So you make the standard the path of least resistance: a golden-path template, sane defaults, tooling that makes doing it right easier than doing it wrong. You pilot with one enthusiastic team to prove value and generate a reference story, then let others pull it in because it visibly helps. You bring affected teams into the design early so it becomes their standard, not something imposed. Data helps ("teams using this template cut onboarding time in half").

How to work through it.

1. Make the right thing the easy thing — golden path, defaults, tooling.
2. Pilot with a willing team; prove value with a reference story + data.
3. Pull, not push — let adoption spread because it helps.
4. Co-design early so it's their standard.

The trap that less-experienced engineers fall into.

Mandating the standard by decree (malicious compliance, workarounds), and imposing a design teams weren't consulted on (no ownership, resistance).

🎯 Interviewer follow-up questions you should expect.

• "How do you get teams to adopt a standard without authority?" You make it the easy path (golden path/defaults), pilot to prove value, let adoption be pulled, and co-design early.
• "Why not just mandate it?" Mandates without buy-in breed malicious compliance and workarounds.

A gray area — neither team owns it, or both claim it.

What is actually happening (the mental model).

Ownership gray areas are where things silently rot — the unowned monitoring alert nobody acts on. So you don't let it fester: you surface it explicitly and drive to a clear owner, often by proposing a RACI so it's concrete rather than a vague "someone should." You keep it about the outcome and the system, not turf — assume good intent, separate people from the problem. If both teams claim it or neither wants it and you can't agree, you escalate the decision to whoever owns both teams — but a clean decision request, not a "they're being difficult" complaint. The senior instinct is to volunteer to create clarity rather than protect a boundary.

How to work through it.

1. Surface the gap explicitly — unowned things fail silently.
2. Propose clear ownership — a RACI makes it concrete.
3. Keep it about the outcome, not turf; assume good intent.
4. Escalate the decision (cleanly), not the conflict, if unresolved.

The trap that less-experienced engineers fall into.

Letting the gray area fester (the unowned thing rots), fighting over turf, or escalating the conflict ("they're difficult") instead of a clean decision request.

🎯 Interviewer follow-up questions you should expect.

• "Neither team owns something / both claim it — what do you do?" You surface it, propose ownership (RACI), keep it about the outcome, and escalate the decision cleanly if needed.
• "Why is an unowned gray area dangerous?" Things silently rot — the alert nobody acts on, the gap nobody fills.

Devs build, ops runs, and they blame each other when things break.

What is actually happening (the mental model).

The wall exists because incentives are misaligned — devs are rewarded for shipping, ops for stability, so they optimise against each other. The fix is shared ownership and shared metrics: "you build it, you run it" means the team feeling the 2am page is the team that can fix the root cause, which aligns everyone on reliability. You build self-service platforms so ops isn't a manual gate devs resent but a paved road devs want to use, and you push a blameless culture so incidents produce learning, not finger-pointing. This is DevOps — not a tool, but tearing down the hand-off by aligning incentives.

How to work through it.

1. Align incentives — "you build it, you run it"; shared reliability metrics/SLOs.
2. Self-service platforms — a paved road devs want, not a gate they resent.
3. Blameless culture — incidents produce learning, not blame.
4. Model it as a senior — care about operability at build time.

The trap that less-experienced engineers fall into.

Treating the divide as a personality/process problem rather than an incentive problem, and reinforcing the wall (ops as a gate) instead of aligning incentives with shared ownership.

🎯 Interviewer follow-up questions you should expect.

• "How do you break the dev/ops wall?" By aligning incentives with a you-build-it-you-run-it model, shared metrics, self-service platforms, and a blameless culture — that's the DevOps philosophy in practice.
• "Why does the wall exist?" Misaligned incentives — devs rewarded for shipping, ops for stability.

You need buy-in from product/leadership for infra work — a migration, tech debt, a platform investment.

What is actually happening (the mental model).

Non-technical stakeholders don't care about the technology, they care about outcomes, so you translate. Instead of "we need to migrate to Kubernetes," it's "this reduces our outage rate, cuts deploy time from a day to an hour, and saves this much per month" — with numbers. You lead with the "so what" and the business risk, offer a couple of options with honest trade-offs so they're deciding not just approving, and cut jargon ruthlessly. The mistake juniors make is presenting the how and expecting leadership to connect it to value — that's your job. If you can't explain why an infra project matters in business terms, you don't understand it well enough yet.

How to work through it.

1. Translate to business impact — cost, risk, velocity, customer experience.
2. Lead with the "so what", quantify.
3. Offer options with trade-offs — they decide.
4. Cut jargon; align to their goals.

The trap that less-experienced engineers fall into.

Presenting the implementation detail (the how) and expecting leadership to connect it to value — so the ask lands flat and the investment isn't approved.

🎯 Interviewer follow-up questions you should expect.

• "How do you get leadership buy-in for infra work?" Translate to business impact (cost/risk/velocity), lead with the so-what, quantify, and offer options.
• "What's the common mistake?" Presenting the how, not the value; leadership can't connect jargon to outcomes.

Teams need to adopt your platform/tooling.

What is actually happening (the mental model).

You treat internal teams as customers, because a technically brilliant platform that teams route around is a failed platform. That means real onboarding docs, golden paths that make the common case trivial, self-service so they're not waiting on you, and being genuinely responsive to friction — early adopters' pain, handled well, becomes advocacy. You measure adoption and satisfaction, not just uptime, because those tell you if the platform is actually serving people. The mindset shift is that platform work is a product with users who have to want to use it.

How to work through it.

1. Internal teams are customers — onboarding docs, golden paths, self-service.
2. Be responsive to friction — turn early-adopter pain into advocacy.
3. Measure adoption & satisfaction, not just uptime.
4. Gather feedback; iterate like a product.

The trap that less-experienced engineers fall into.

Building a technically impressive platform and throwing it over the wall (no onboarding, poor UX), then wondering why teams route around it — measuring uptime instead of adoption.

🎯 Interviewer follow-up questions you should expect.

• "How do you drive platform adoption?" You treat internal teams as customers, offering golden paths, self-service, and responsive support, and you measure adoption and satisfaction, not just uptime.
• "What's the success metric for a platform?" Adoption and user satisfaction, not just uptime; a platform nobody adopts is a failure.

An outage spans multiple teams' services.

What is actually happening (the mental model).

Cross-team incidents fail on coordination, not technical skill — five smart people debugging in five channels is chaos. So the first thing you establish is a single incident commander to coordinate across teams, one comms channel, and clear roles, so nobody's stepping on each other or duplicating work. During the fire, the focus is mitigation over root-cause. Then a joint blameless postmortem with all the teams — because the interesting failures in a cross-team outage are usually in the seams between services, and those only get fixed if everyone's in the room. Clear command structure turns a multi-team scramble into a coordinated response.

How to work through it.

1. Single incident commander across teams; one comms channel; clear roles.
2. Mitigation over root-cause during the fire.
3. Joint blameless postmortem — the failures live in the seams.

The trap that less-experienced engineers fall into.

No single coordinator (everyone debugs in parallel, duplicating work in separate channels — chaos), and separate per-team postmortems that miss the failures in the seams between services.

🎯 Interviewer follow-up questions you should expect.

• "An outage spans several teams — how do you coordinate?" You appoint a single incident commander, keep everyone in one channel, and keep roles clear; you mitigate first; and afterward you run a joint, blameless postmortem.
• "Where do cross-team failures usually live?" In the seams between services — only found if all teams retro together.

Two teams must agree on an interface.

What is actually happening (the mental model).

A good interface is the thing that lets two teams stop coordinating on everything — so it's worth designing carefully and explicitly: the schema, versioning strategy, error semantics, and the SLA each side can rely on. You make it collaborative so both sides own it, then enforce it with contract tests so a breaking change is caught in CI, not production. Backward-compatible versioning means the provider can evolve without a synchronized deploy. You think of the interface as the product of the collaboration — get it right and both teams move fast independently; get it vague and every change becomes a negotiation. Well-designed contracts are how organizations scale.

How to work through it.

1. Design the contract explicitly — schema, versioning, error semantics, SLA.
2. Collaborative — both sides own it.
3. Enforce with contract tests — breaking changes caught in CI.
4. Backward-compatible versioning — evolve without lockstep deploys.

The trap that less-experienced engineers fall into.

Leaving the interface vague/undocumented (every change becomes a cross-team negotiation), and breaking compatibility without versioning/contract tests (breaks the consumer in prod).

🎯 Interviewer follow-up questions you should expect.

• "How do you design an interface between teams?" An explicit, collaboratively designed contract covering schema, versioning, errors, and SLA, enforced by contract tests and backward-compatible versioning.
• "Why is a good contract high-leverage?" It lets the teams stop coordinating and move independently — how orgs scale.

One team solved a problem others also have.

What is actually happening (the mental model).

At senior level your impact isn't measured by what you personally build, but by what you help the whole org get better at — so when one team solves something valuable, you make sure it doesn't stay siloed. That might be an internal tech talk, a shared library or template, or a community of practice/guild where teams cross-pollinate. You're a big believer in sharing postmortems widely, because an outage one team suffered is a free lesson every other team can learn from before they hit it themselves. Creating channels for knowledge to flow across teams is high-leverage — it's how a senior multiplies impact through others instead of being a single well-utilized IC.

How to work through it.

1. Spread solutions — tech talks, shared libraries/templates, guilds/communities of practice.
2. Share postmortems widely — one team's outage is every team's free lesson.
3. Create channels for cross-pollination.
4. Multiply impact through others, not just your own output.

The trap that less-experienced engineers fall into.

Solving a problem and keeping it siloed (every team reinvents the wheel / repeats the same outage), and measuring impact only by personal output rather than what they enable across the org.

🎯 Interviewer follow-up questions you should expect.

• "How do you spread knowledge across teams?" Tech talks, shared libraries/templates, guilds, and sharing postmortems widely — multiply impact through others.
• "Why share postmortems broadly?" One team's outage is a free lesson every other team can learn before hitting it.

Another team owns something you need, but it's not on their roadmap — your priority isn't their priority.

What is actually happening (the mental model).

Roadmap misalignment is normal — every team has its own priorities, and "your urgent" isn't automatically "their urgent." So you make the business case in their and the org's terms (impact, revenue, risk), find a shared goal you both ladder up to, and where you can, reduce your dependence on them (self-serve, a contribution/inner-source PR to their codebase, or a temporary workaround) so you're not blocked on their backlog. If it genuinely matters and can't be reconciled, you escalate to shared leadership to align priorities — with data, framed as a business trade-off, not "they won't help us." Contributing to their work (inner source) is often the fastest unblock.

How to work through it.

1. Make the case in their/org terms — impact, revenue, risk; find the shared goal.
2. Reduce dependence — self-serve, inner-source a PR to their code, or a temporary workaround.
3. Escalate to shared leadership with data if it truly matters and can't reconcile.
4. Frame as a business trade-off, not a complaint.

The trap that less-experienced engineers fall into.

Assuming their roadmap should bend to your priority, getting stuck waiting on their backlog, and escalating as "they won't help" instead of a data-backed priority trade-off — or not considering contributing the change yourself.

🎯 Interviewer follow-up questions you should expect.

• "A team you depend on deprioritised your need — what do you do?" You make the case in their/org terms, reduce dependence (inner-source/self-serve/workaround), and escalate to shared leadership with data if it truly matters.
• "Fastest way to unblock?" Often the fastest path is contributing the change to their codebase yourself, an inner-source approach, if they're willing to accept it.

You depend on a vendor or third-party service — for a tool, a managed service, or an integration — and need to manage that relationship and its risk.

What is actually happening (the mental model).

A vendor is a dependency you don't control, so you manage it deliberately: hold them to SLAs with real consequences, design for their failure (a vendor outage shouldn't take you down — timeouts, fallbacks, circuit breakers), avoid deep lock-in where the switching cost would be crippling, and keep a relationship + escalation path for when things go wrong. You do due diligence on their reliability and security posture (they're part of your attack surface and your uptime). The senior stance: a vendor's SLA is a contract, not a guarantee your service stays up — you still own your users' experience.

How to work through it.

1. SLAs with consequences + an escalation path/relationship.
2. Design for vendor failure — timeouts, fallbacks, circuit breakers; a vendor outage shouldn't take you down.
3. Avoid crippling lock-in — weigh switching cost; abstract where sensible.
4. Due diligence on reliability + security (they're your attack surface and uptime).

The trap that less-experienced engineers fall into.

Trusting a vendor's SLA as a guarantee (no fallback, so a vendor outage becomes your outage), and getting deeply locked in without weighing the switching cost.

🎯 Interviewer follow-up questions you should expect.

• "How do you manage a critical vendor dependency?" You negotiate SLAs with clear escalation paths, design for their failure with timeouts, fallbacks, and circuit breakers, avoid crippling lock-in, and do proper due diligence upfront.
• "A vendor has a 99.9% SLA — does that mean you're covered?" No — you still own your users' experience; design so a vendor outage doesn't take you down.