5 SRE Interview Questions I Got Wrong and What I’d Say Now

If you’re an SRE, or planning to become one, do yourself a favor and read this article.

Created by Author — Suplimented NanoBanana

I lost an SRE onsite on a sentence that was completely, verifiably correct: “I understand circuit breakers.”

Three weeks of prep, and that’s the line I’d point to now. Here’s what a candidate who’d actually operated one says instead: “I dropped our payment circuit breaker from 10 failures to 5 at 2AM, because the retries were amplifying a database stall.”

💥 Master Any Skills in 3 Months

• 📚 Up to 50% OFF Premium Courses ⏰ Limited-Time Offer [👉 **Enroll Now & Start Learning](https://trk.udemy.com/zz4NBO)***

Same knowledge. Completely different signal. My feedback came back as three words over the phone: lacked operational depth. I’d answered correctly and told them nothing about whether I could do the job.

An SRE interviewer assumes you know the concepts. What they’re buying is evidence you’ve operated them at 2AM, with a customer on the line and half a dashboard. The gap is never knowledge it’s whether your answer has a timestamp in it.

I’ve since written that rejection for someone else, which is a strange thing to do when you recognise your own words coming back at you.

Below are the 5 questions I got wrong: what I said, and what I’d say today. Plus the scorecard I fill out from the other side of the table, and the rehearsal template I use before every loop. If you’ve read the first article in this series, some of what I call “wrong” here is the scaffolding I recommended there. I stand by it this is about what happens when scaffolding is all you bring.

TL;DR — The Five Rewrites

If you’re just going through, this table is the article.

Created by Author

Why a Correct Answer Can Still Fail

An SRE interview scorecard usually carries a row that a software engineering scorecard doesn’t: evidence of production ownership. Both versions of the circuit breaker answer above are correct. Only one of them puts anything in that row.

My wrong answers sounded like documentation. Accurate documentation. But the person across the table had been paged for the exact scenario I was reciting from a book, and they could hear the difference instantly.

One more thing I misjudged. I thought I was being careful; I was being unreadable. What tanks candidates isn’t naming a tradeoff. It’s naming tradeoffs and then never landing anywhere. “Well, it depends, there are pros and cons either way,” full stop, tells the interviewer nothing about how you’d actually behave on a Tuesday.

The shape that scores is both halves: name the condition, then commit anyway. “It depends on whether anyone downstream owns that alert. Here’s what I’d do in each case, and here’s the one I’d bet on.” That’s what senior engineers sound like, and it beats a confident wrong answer every time.

The row I actually score you on

Here’s the rubric anchor I use for production ownership. It’s the row that sank me, and it’s the one I now spend the most time on when I’m the one writing.

Created by Author

Most rejections I’ve written land on 1 or 2. The gap between a 2 and a 3 is rarely more experience; it’s usually that the candidate had the incident and didn’t think the details were worth mentioning.

If you take one thing from this article: the details you’re rounding off are the score.

Question 1: “Walk me through your incident response process.”

What I said

“We follow a structured incident management process. First we declare the incident and assign severity. Then we assemble the response team, establish a communications channel, work toward mitigation, and document the postmortem.”

Every word accurate. Zero signal.

Why it scored badly

I described a process diagram. They wanted a story.

Every candidate who’s read the SRE book gives that answer, which means it can’t differentiate anyone. Worse, it tells the interviewer nothing about what I do in the first 3 minutes, the window where incidents are actually won or lost.

What I’d say now

“My first three minutes are always the same, in this order.

I open the burn rate dashboard before I read the alert text. I want to know whether I’m looking at a fast spike or a slow bleed, because that decides whether I have 5 minutes to think or 30.

Then I check the last two hours of deploys and config flips in Argo CD. If there’s a correlation, I’m costing out a rollback before I’ve opened a single log line.

Third, I bound the blast radius. One endpoint or all of them? One region? One tenant, or everybody? Global?

That last one is the thing that took me longest to learn. I used to start diagnosing immediately, and I’d waste ten minutes chasing a root cause on what turned out to be a single noisy-neighbour tenant. Now nobody on my incident calls proposes a fix until we’ve answered ‘how much of the system is this?’ because the answer changes what a reasonable fix even looks like.”

The second version has me inside an incident rather than describing one from above. It also admits a mistake, which reads as real rather than rehearsed.

The ordering is the same triage I described in the system design piece. What I left out there is the part that earns the point: the wrong turn. An answer where every step worked is a script. An answer with a dead end in it happened.

And name the tool. “The burn rate dashboard in Grafana,” “deploy history in Argo CD,” “the incident channel in Slack.” Vague answers sound borrowed. Named tools sound lived-in, and they invite the follow-up you want, which is about your system rather than your vocabulary.

Question 2: “How do you design SLOs?”

What I said

“You start by identifying the key user journeys, then define SLIs that measure those journeys, set targets based on business requirements, and create error budgets from the inverse of the target.”

I could have lifted that straight from a conference slide, and in fairness I probably had.

Why it scored badly

I’d recited the method and skipped the hard part. Every SRE candidate can produce that paragraph. None of it tells the interviewer whether I’ve ever sat in a room while a product manager and a VP of Engineering argued about what 99.9% actually costs.

Getting an organisation to agree to a number, and to what happens when it’s breached, is the half that takes political capital.

What I’d say now

“The math is the easy part. The hard part is the negotiation.

I’ve had a product manager ask for five nines on a feature that 200 users touch per day. Five nines is 26 seconds of downtime a month, which already sounds bad.

The number that actually ended the conversation was a different one. At 200 users a day you serve roughly 6,000 requests a month, and five nines allows 0.06 failed requests. You’d need about 100,000 requests before a single failure even fits inside the budget. One failed request puts you at 99.98%, and no amount of engineering gets you back.

So the target wasn’t expensive, it was unmeasurable at our volume. That moves the conversation from “can we afford this?” to “can we even observe this?”, which is a much harder objection to wave away.

I’ve also watched a team pick 99.5% because it felt conservative. That’s 3.6 hours of allowed downtime a month: looser than what they were already delivering, and a promise to customers that they could be down for an afternoon.

So my process starts with the user journey, not the metric. ‘Checkout completes and the customer sees a confirmation within 2 seconds’ is a journey. ‘HTTP 200 rate’ is a metric. You can sit at 100% on the metric while the journey is broken.

We had a cart service fail open on a deserialization error: empty cart, HTTP 200, sub-100ms. Every technical SLI stayed green for 35 minutes. What caught it was orders-per-minute falling off a cliff, the one graph none of my alerts pointed at. That’s why I now want at least one business-metric SLI per critical journey.

Then I bring historical data to the target conversation, because a target set above your current performance is a budget you’ve already spent.”

The table I bring to that meeting has two columns. Minutes are what executives feel; allowed failed requests tell you whether the target is measurable at all. (These are 30-day months. On a rolling 28-day window the 99.9% budget is 40.3 minutes, not 43.2, so say which one you mean.)

Created by Author

“If we’ve actually been running at 99.7% for the last 90 days, then a 99.9% SLO cuts our monthly allowance from 130 minutes to 43. We’d be consuming three times the budget we just agreed to, on day one, having changed nothing. That’s not a target, it’s a breach with a start date. Start where you are and set a direction.

And the error budget only means something if you’ve written down in advance what happens when it’s gone. Freeze feature launches? Move two engineers to reliability work for a sprint? If that policy doesn’t exist before the first breach, the error budget is a number on a dashboard nobody opens.”

That last paragraph is the one that gets follow-up questions, because most teams have the dashboard and not the policy.

Question 3: “Tell me about a time you reduced toil.”

What I said

“I automated our weekly deployment report with a Python script. It used to take 45 minutes manually and now it runs on a schedule. I also wrote Ansible playbooks to standardise our server provisioning.”

The interviewer wrote one word down and moved on. I think it was “scripts.”

Why it scored badly

I’d picked two small, safe, uncontroversial wins. That demonstrates I can write scripts, which nobody doubted.

What the question actually probes is judgment: can you tell which toil is worth eliminating, build the case for it, and get it funded in an organisation that has other priorities? A weekly report saving 45 minutes doesn’t test any of that.

What I’d say now

“The most useful toil I killed wasn’t the one that took the most hours.

We had a manual TLS certificate rotation: 12 steps, 4 hours, two engineers, every 90 days. None of it was technically hard. It stayed manual precisely because it was rare, so it never made a sprint, because on any given Monday something else was on fire.

So I logged my on-call toil for four weeks and scored it.”

Created by Author

“Four weeks of my own log, plus the last four rotation records from the runbook history. A quarterly task never shows up in a four-week sample, which is exactly why it kept escaping notice.

Certificate rotation was dead last by hours. Thirty engineer-hours a year against 118 for log triage. It was still first by risk, because a fumbled step takes down TLS termination for everything behind the gateway, and in March 2025 someone fumbled a step.

Our synthetics went red before any of our metrics did, because a failed TLS handshake never reaches the application and every app-side dashboard stayed green. That’s the part I got wrong, and the detail I’d want an interviewer to hear. We restored the previous secret and bounced the ingress pods; depending on which graph you believe it was 20 to 30 minutes of customer-facing failure.

That incident is what changed the priority. I’d been asking for three days of engineering time for two quarters and getting nowhere. After a customer-facing outage with a postmortem attached, I got it in the next sprint.

The automation took three days: cert-manager issuing from Let’s Encrypt, with an expiry alert at 21 days as the backstop against silent renewal failure. No manual rotation since, and no repeat of that outage.”

The structure that makes this land: specific toil, why it stayed manual, what changed the priority, the fix, the outcome. Four of those five are about organisational reality rather than code.

The strongest version of this answer includes something you chose not to automate. Saying “log triage was 118 hours a year and I still deprioritised it, because getting it wrong costs nothing” proves you’re ranking by risk instead of by hours. That’s a hard signal to fake.

Question 4: “How would you handle an alert that fires every day but is never actionable?”

What I said

“I’d tune the threshold to reduce false positives and update the runbook to reflect the correct response.”

That answer will get you through a phone screen and no further.

Why it scored badly

This question gets asked because that alert exists at their company right now, and somebody in the room is annoyed about it. They want to know whether you’ll fix it or quietly tolerate it for two years like everyone before you.

“Tune the threshold” commits to nothing. It’s also usually wrong. A threshold tweak on an alert nobody acts on produces a slightly quieter alert nobody acts on.

What I’d say now

“Delete it.

An alert that fires daily and never requires action isn’t a monitoring signal any more, it’s a training exercise. You’re teaching the rotation that alerts can be ignored, and that habit doesn’t stay contained. At 3AM the instinct to glance at a page and go back to sleep applies to whichever alert just fired.

I’d do two checks before deleting, and they take about ten minutes each.

First, find out why it was created. Check the commit that added it and the ticket it references. A lot of these were legitimate 18 months ago until the underlying condition changed and the alert outlived the problem. That history tells you whether you’re deleting a mistake or a fossil.

Second, decide whether the condition it watches matters at all. If it genuinely matters, the problem is the alert design, not the threshold. It probably needs to become a burn rate alert on a user-facing symptom, or a ticket instead of a page. If it doesn’t matter, delete it and don’t look back.

Then make it a habit rather than a one-off. On a ten-person team I ran a fortnightly alert review, and the move that worked was grouping by rule instead of by page. Forty pages a fortnight looked like a catastrophe until we grouped them: 11 distinct rules, 3 of which accounted for 26 of the pages. One was a flapping node-exporter on a box nobody owned. Killing three rules took us to about a dozen. That’s usually the shape of it 3 problems arriving 40 times, and dedup finds them faster than tuning does.

One honest footnote: we deleted a disk-usage alert in that sweep and four months later filled a volume nobody was watching. It came back as a ticket rather than a page. I’d rather say that out loud than pretend the sweep was free.”

Be precise about what you’re deleting, because this is where the answer gets interrogated: delete the page, keep the check. Route the condition to a ticket queue and confirm a symptom-based alert covers what actually matters. Non-actionable to me is not the same as non-actionable, so the first question is always who owns it. In practice I’d mute with a 30-day expiry and a named owner rather than delete outright, which is reversible and produces evidence.

I’d still open with “delete it.” The position starts the conversation; the nuance belongs in the follow-up, not in the opening sentence.

Question 5: “What’s your approach to capacity planning?”

What I said

“I look at current utilisation trends, project forward using growth rates, add a safety buffer, and plan around provisioning lead times.”

Four steps, all of them right, none of them mine.

Why it scored badly

It’s the right framework with no evidence I’d ever applied it under real constraints. In practice it’s a negotiation against growth projections that are usually wrong, and none of that shows up in a four-step recital.

It also aggregates, which is where the real mistake hides.

What I’d say now

“Most capacity planning conversations answer ‘when do we run out?’ and stop there. The more useful question is ‘what breaks first, and what does it look like when it does?’

So I build two models. A projection model for the timeline, and a saturation model that ranks components by how soon each one hits its own ceiling, because the aggregate number hides the component that’s about to fall over.”

import math
# Utilisation is demand / capacity, so compound the demand and hold capacity
# fixed. Each ceiling is where THAT dimension degrades, not 100%.
components = {
    "api_servers":   {"dimension": "CPU",              "demand": 620,
                      "capacity": 1000, "growth": 0.08, "ceiling": 0.80},
    "database":      {"dimension": "CPU (autovacuum)", "demand": 710,
                      "capacity": 1000, "growth": 0.06, "ceiling": 0.75},
    "cache_cluster": {"dimension": "resident memory",  "demand": 450,
                      "capacity": 1000, "growth": 0.12, "ceiling": 0.85},
}
# Days to provision more of each. The number that decides if you're late.
LEAD_TIME_DAYS = {"api_servers": 1, "database": 42, "cache_cluster": 3}
def months_to_ceiling(demand, capacity, growth, ceiling, **_) -> float:
    """Solve (demand * (1 + growth)**n) / capacity = ceiling for n."""
    if demand / capacity >= ceiling:
        return 0.0
    return math.log(ceiling * capacity / demand) / math.log(1 + growth)
for name, c in sorted(components.items(), key=lambda kv: months_to_ceiling(**kv[1])):
    days = months_to_ceiling(**c) * 30
    lead = LEAD_TIME_DAYS[name]
    print(f"{name:<14} {c['dimension']:<18} {days:5.0f} days  "
          f"lead {lead:2d}d  {'LATE' if days < lead else 'ok'}")
# database       CPU (autovacuum)      28 days  lead 42d  LATE
# api_servers    CPU                   99 days  lead  1d  ok
# cache_cluster  resident memory      168 days  lead  3d  ok

“The database is 28 days out. Not three months, which is when the API tier gets uncomfortable and where an aggregate utilisation view would have pointed me.

The ranking matters less than the lead time. We can add API capacity in an afternoon, so 99 days is comfortable. The database is a reserved-instance resize with a six-week procurement window. Twenty-eight days against a 42-day lead time means we aren’t approaching a capacity problem, we’re already 14 days late. That’s the sentence that changes what the meeting decides.

And I’d name the dimension every time. ‘The database is at 71%’ means nothing on its own. 71% of CPU, of IOPS, of max_connections, of disk? The ceiling is 75% CPU because autovacuum needs the headroom, and if I hadn't known that I'd have planned to 90% and wondered why write latency fell apart at 78%.

Two habits worth stealing. Growth projections from product are optimistic by default, so I model base case and 2x and I always say which one I’m quoting.

And I set the trigger off lead time, not off a round number. A threshold alert at 73% CPU sounds prudent until you run it: at 6% monthly growth that fires 14 days before the ceiling, on a component that takes 42 days to resize. The trigger has to fire with more runway than the lead time, which for this database means the alert belongs at 66%. And if we’re already past that, the honest answer to the interviewer is that the trigger’s job now is telling us how late we are.”

The number that matters here is 28-against-42: a countdown measured against how long you need to react. Put lead time in a capacity answer and it stops being arithmetic and starts being a decision.

Nobody Fails the Answer. They Fail the Third Follow-Up.

Everything above is written as a monologue, which is the one way an interview never goes. You give a good answer and the interviewer picks the softest number in it and pushes. That’s not hostility. It’s the only way to tell whether the answer was lived or assembled.

Every strong answer hands over a thread to pull. Here’s the thread each of mine hands over, and what a bad reply looks like.

Created by Author

Prepare the follow-up, not the answer. Interviewers who’ve carried a pager can tell within one exchange whether you’re recalling something or constructing it, and that judgment is basically unrecoverable once it’s made.

Every interviewer who asked me these questions had been paged at 2AM for the scenario in the question. They weren’t quizzing me on the book. They were working out whether I’d be useful at 2:14AM on a Tuesday.

The Rehearsal Template That Fixed This For Me

Reading this won’t change your answers. Under pressure you fall back on whatever you’ve said out loud before, which for most people is the textbook version. So pick three real incidents and write them into this shape.

## Incident: [one line — what the customer experienced]
Blast radius:   [one endpoint / one region / one tenant / global]
Detection:      [what told you - alert name, dashboard, or a human]
First 3 min:    [the exact three things you did, in order]
The wrong turn: [what you chased that didn't pan out]
Mitigation:     [what stopped the bleeding, and the time it took]
Fix vs. patch:  [what you shipped after, and what you knowingly left]
Numbers:        [duration, % of traffic, $ or SLO impact]

Ninety seconds each. Then map every question in this article onto one of the three.

“Tell me about toil” and “tell me about capacity planning” can both come out of the same incident if you know it well enough. That’s the point of doing three properly rather than ten badly depth on a few beats coverage of many, because the follow-up always goes deeper than your prep did.

Fill in “the wrong turn” honestly. A candidate who names a dead end they chased is more believable than one whose incidents all resolved cleanly, and it pre-empts the follow-up rather than waiting to be caught by it.

Then record yourself once. You’ll hear filler and hedging you had no idea you were producing, and it’s the fastest improvement available before a real loop.

Key Takeaways

• “Operational depth” means details with timestamps. A 2 on the scorecard is a real incident told in general terms. A 3 has the timeline, the tool names, and a number attached.
• Name the condition, then commit anyway. Unresolved tradeoffs are what read as inexperience, not the tradeoff itself.
• Prepare the follow-up, not the answer. Nobody fails the answer. They fail the third question about it.
• Price SLO targets in minutes and in requests. 99.5% is 3.6 hours a month. At 200 users a day, five nines allows 0.06 failed requests, so you can’t measure it at all.
• Rank toil by blast radius, not hours. My cert rotation was last by hours and first by risk. Naming what you chose not to automate proves you’re ranking at all.
• Capacity answers need lead time in them. 28 days to saturation against a 42-day procurement window means you’re already two weeks late.
• Rehearse three incidents out loud, wrong turns included. Under pressure you use what you’ve said before, not what you’ve read.

This is the third piece in the SRE interview series. The first covered the questions I get asked in every SRE interview and how I answer them, start there if you’re early in your prep, because it gives you the structures this article assumes you already have. The second broke down the system design round, which runs on a completely different rubric: where most candidates lose points.

If this changed how you’d answer any of the five, a clap helps CodeToDeploy to put it infront of more engineers prepping right now. Next in the series: the questions I ask the interviewer, and what their answers tell me about the on-call rotation I’d be joining.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: **Linkedin| [Medium](https://medium.com/codetodeploy)**

👉 CodeToDeploy Tech Community is live on Discord — **Join now!**

Disclosure: This post includes affiliate and partnership links.