DevOps and SRE interviews are less about naming tools and more about judgement under constraints: what you roll back first, what you alert on, and what you deliberately leave broken until morning. Below are the questions asked most often, each with a model answer. Senior: architecture, trade-offs, mentoring, and decision-making.
By making every deploy independently reversible, which mostly constrains the database: expand before contract, never drop in the same release that stops writing. The second requirement is that rollback is exercised — a path used once a quarter in an incident is a path that does not work. Feature flags decouple release from deploy and turn most rollbacks into a config change.
Restore service first and diagnose second: mitigations like rolling back, shifting traffic or scaling do not require a root cause. Someone owns coordination and is not also debugging, and the timeline is written as you go, because memory reconstructs it wrongly afterwards. The postmortem asks what made the failure possible and what made it slow to detect, not who typed the command.
On symptoms the user feels — error rate, latency, unavailability — not on causes, because causes are numerous and mostly harmless. Every alert must have an action; one that is routinely acknowledged and ignored is training people to ignore alerts. The measure of a good alerting setup is how many pages were unnecessary, and that number should be reviewed.
At requests versus actual usage first, because overcommitted requests reserve capacity nobody uses and are the single largest source of waste. Then at node sizing and bin packing, then at what is running that nobody owns — old environments, forgotten load balancers, snapshots. Storage and egress are the lines that grow quietly and are never in the first estimate.
By importing rather than recreating, one bounded piece at a time, starting with something low risk so the workflow gets exercised before it matters. The hard part is not the tooling but the rule that manual changes stop, because a codebase that drifts from reality is worse than no codebase — it is trusted and wrong. Drift detection has to run on a schedule.
By treating alert volume as a defect count with an owner, not as the weather. A rotation that pages nightly burns people out and the attrition costs more than the engineering time to fix the causes. The concrete practices are a follow-up task from every page, a cap on how much toil is acceptable, and time in the next sprint reserved for what the last rotation surfaced.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior DevOps / SRE interview →