Tell me about a time you had to push back on or say no to a stakeholder's request — for example, a deadline or feature that you believed compromised security or reliability.

The interviewer is checking whether you can hold a technical or safety line under real business pressure without either caving to keep the peace or being needlessly obstructive — a strong answer shows you understood the stakeholder's actual business need, explained the real risk in terms they could evaluate (not just technical jargon), and worked toward either a genuine alternative or an informed, explicit trade-off decision, rather than a flat, unexplained "no."

DevOps and platform roles regularly sit at the intersection of business pressure (ship faster, cut this corner just this once) and real technical/security/reliability risk, and how someone navigates that tension — without either being a pushover who lets risk through unchecked, or being reflexively obstructive in a way that damages trust and gets worked around — is a genuinely important, assessable skill.

Did you understand the stakeholder's actual need before pushing back? A strong answer shows you engaged with why the deadline or request mattered to them — a genuine business reason, not just "they wanted it" — since understanding the real need is often what lets you find a genuine alternative rather than a flat refusal.

Did you explain the risk in terms the stakeholder could actually evaluate? Saying no effectively to a non-technical or differently-technical stakeholder means translating the risk into terms they can weigh against their own priorities — "this could mean X hours of downtime affecting Y customers" lands very differently than "this violates best practice," and a strong answer shows this kind of translation happened, not just technical language repeated more insistently.

Did you offer a path forward, not just a blocker? The strongest version of this story usually isn't "I said no and that was the end of it" — it's "I said no to the original request, but here's the alternative we found that addressed their real need without the risk," or "we made an informed, deliberate trade-off together, with the risk explicitly acknowledged, rather than it being silently accepted or silently ignored."

How did the actual disagreement get resolved, and was the outcome honest? As with the technical-disagreement question, the most credible answers aren't uniformly "and I was right and they backed down" — sometimes the honest answer is "we found a middle path," or "leadership made the call to accept the risk anyway, with it explicitly documented, and that was a legitimate outcome even though I'd raised the concern."

Did you maintain the relationship, not just win the argument? A subtle but important signal: does the story show you preserved a working relationship with this stakeholder afterward, or does it sound like the interaction damaged trust — the former suggests you handled the disagreement in a way that's sustainable for ongoing collaboration, which matters more than winning any single specific argument.

• The interviewer is assessing whether you can hold a real technical/safety line under business pressure without either caving or being needlessly obstructive.
• Understand the stakeholder's actual underlying need, and translate risk into terms they can genuinely evaluate, rather than repeating technical language more insistently.
• The strongest answers offer a genuine alternative or lead to an informed, explicit trade-off decision — not just a flat "no" with nothing constructive following it.
• Show the relationship was preserved afterward, not just that you won the specific disagreement — sustainable collaboration matters more than any single argument.

• Google SRE Book: Embracing Risk