AI interview prep for DevOps engineers and SREs
DevOps and SRE interviews run on incidents. An AI screen will ask you to walk through an outage minute by minute, defend a deploy process, explain how you set reliability targets, and say what you automated away. Here are the questions to expect, two worked answers, the mistakes that weaken operations answers, and free practice at your level.
Entrevista con IA para ingenieros de DevOps y SRE: esta guía en español
What AI screens ask DevOps engineers and SREs
An incident from alert to fix
“Walk me through the last serious incident you handled. What did you check first?”
Listening for: A timeline, how you narrowed it down, mitigation before root cause, and what changed afterwards.
Deploys and rollbacks
“How did your team ship changes to production, and how did you make rollbacks safe?”
Listening for: The pipeline in steps, canaries or staged rollouts, and a time a rollback mattered.
Reliability targets
“How did you decide how reliable a service needed to be?”
Listening for: An SLO tied to what users feel, an error budget, and a decision the budget changed.
Infrastructure as code
“Tell me about infrastructure you moved into code. What went wrong?”
Listening for: The tool and why, drift or state problems, and how changes were reviewed.
On-call load
“On-call was paging too often. What did you do?”
Listening for: Pages counted before and after, which alerts you removed or changed, and how the team agreed.
Cost
“Describe a time you cut infrastructure cost without hurting reliability.”
Listening for: Where the money went, the change, and the numbers on both sides.
Access and secrets
“How did you handle secrets and access to production?”
Listening for: A concrete control, why it was chosen, and the friction it caused.
Worked example: a CDN change that broke playback
Each example shows a weak and a strong answer to the same question. The “With Aethel's rules” lines apply Aethel's published scoring rules, one concrete example of how an AI interview can judge an answer.
Question: “Walk me through the last serious incident you handled. What did you check first?”
Weak answer
“We had a big outage once where the site went down. I was on call, so I jumped on it, checked the dashboards and the logs, and found the problem was with the database. We fixed it and wrote a postmortem. I am very calm under pressure and I like incident response.”
Why it is weak: There is no timeline, no symptom, no cause beyond "the database" and no change afterwards. The last sentence describes you, which an interviewer cannot check. Follow-ups such as "what did the dashboards show?" have nothing to build on.
With Aethel's rules: Situation 1, reasoning 0, result 0: 1 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.
Strong answer
“At a video streaming service with about 3 million subscribers, I was incident lead when playback start failures jumped from 0.2 percent to 11 percent on a Friday evening. The first thing I checked was what had changed in the last hour, and the deploy log showed a new CDN configuration rolled out 20 minutes earlier. I rolled it back while a teammate kept digging, because restoring service mattered more than knowing why, and failures were back under 0.5 percent nine minutes later. The cause turned out to be a cache key change that dropped the device type, so some TVs received manifests meant for phones. Afterwards I put CDN configuration through the same staged rollout as our code, starting at 1 percent of traffic with automatic rollback if playback failures rose, and wrote a check that fails the pipeline when a cache key loses a field. In the next six months two more bad CDN changes went out, and both rolled back on their own at the 1 percent stage.”
Why it is strong: It gives the symptom as a number, the first check and why it came first, and a mitigation that put users ahead of curiosity. The root cause is precise, the follow-up changes the process instead of blaming a person, and the result is tested by later incidents.
With Aethel's rules: Situation 2, reasoning 2, result 3: 7 of 8 points, which is 91 on Aethel's fixed scale. A real score can differ.
What comes next: Expect: why was the CDN configuration outside the staged rollout in the first place? Saying how you looked for the same gap in other configuration files strengthens the answer.
Worked example: an on-call rotation that paged too much
Question: “On-call was paging too often. What did you do?”
Weak answer
“Our alerts were too noisy, so I cleaned them up. I removed a lot of alerts that were not useful and tuned the thresholds on others. The team was much happier with on-call after that.”
Why it is weak: It describes a cleanup but not how you decided what was "not useful", which is the hard part and the part an interviewer will ask about. There are no page counts before or after, and "much happier" is not measured.
With Aethel's rules: Situation 1, reasoning 0, result 1: 2 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.
Strong answer
“On a six-person platform team at a logistics company running about 140 services, on-call averaged 47 pages a week, and two engineers had asked to leave the rotation. I exported three months of pages and tagged each one: did a person have to act, and did a customer notice? Only 9 percent needed action. I proposed a rule that every page must point at something users feel, such as failed shipments or API errors above our SLO, and that cause-based alerts like CPU or disk become tickets instead. Deleting those alerts outright was faster, but some of them did catch real problems early, so turning them into tickets kept the signal without waking anyone. The team reviewed each change in a weekly half-hour session. After two months we were at 8 pages a week, our time to detect customer-facing incidents did not get worse in the next quarter's review, and both engineers stayed on the rotation.”
Why it is strong: The answer starts from data about the pages, not opinions about them, and the rule for what may page is stated plainly. A faster alternative is weighed against a real risk, the team is part of the change, and the result checks both sides: fewer pages and no slower detection.
With Aethel's rules: Situation 2, reasoning 2, result 3: 7 of 8 points, which is 91 on Aethel's fixed scale. A real score can differ.
What comes next: Expect: how did you keep new noisy alerts from creeping back? A review rule for new alerts, or a page count you watch every month, answers it.
Common mistakes in DevOps and SRE answers
- Root cause first, users second. In an incident story, say when service was restored before you explain why it broke. Interviewers listen for mitigation first.
- Blaming a person. "Someone pushed a bad config" ends the story. Say what in the process let it through and what you changed.
- Reciting tools. Kubernetes, Terraform and a monitoring vendor are not decisions. Say what problem each solved for you and what it cost.
- SLOs that never changed anything. If an error budget never changed a decision, the SLO was decoration. Give a case where it slowed releases or justified work.
- Automation without a before and after. Say how long the manual task took, how often it ran, and what it costs now.
- Skipping access and secrets. Operations work touches production access. Mention how you limited and audited it, even briefly.
Numbers worth having ready
An interviewer places a case by its numbers. Find these for each of your cases before a DevOps and SRE interview; rounded is fine:
- Pages per week, and time to detect and recover for one incident
- Availability or error rate against the SLO you set
- Deploys per day or week, and how often a deploy caused a problem
- Services, clusters or cloud accounts you managed
- Monthly infrastructure cost before and after a change
- How long a manual task took before you automated it, and how often it ran
Practice DevOps and SRE questions free
Pick a level, type an answer to each question, and read the quick check after each one. Free, no account, nothing saved, and not a score.
Junior. Prepare a script, a pipeline step or your first weeks on call.
Practice junior DevOps and SRE questionsMid-level. Prepare incidents you led and infrastructure you moved into code.
Practice mid-level DevOps and SRE questionsSenior. Prepare reliability strategy, cost and platform decisions across teams.
Practice senior DevOps and SRE questions
Questions from DevOps engineers and SREs
Will an AI interview ask me to troubleshoot a live system?
Some tools give you a broken system or a log to read, so ask beforehand. Aethel's interview asks you to talk through incidents you handled, and may give you a realistic scenario to reason about out loud.
What if I was not the incident lead?
Tell the incident from your seat: what you saw, what you checked, what you said in the incident channel. A clear account of your own part beats a borrowed account of the whole response.
How do I describe infrastructure I am not allowed to share?
By its shape: number of services, regions, rough traffic and team size. Leave out hostnames, account ids and anything a security team would remove from a postmortem.
I am a system administrator moving into DevOps. Which cases should I use?
Cases where you replaced manual work with something repeatable: a script that became a pipeline, a server that became code, a checklist that became an alert. Say what it took before and after.