I've been on both sides of the SRE interview table for years. I've hired engineers who became outstanding contributors and passed on candidates who went on to do impressive things elsewhere. The mistakes I made — hiring engineers whose skills looked right on paper but didn't match what the role needed, passing on candidates who didn't interview well but would have thrived — have taught me what the standard SRE interview process consistently gets wrong.
This is a guide for both interviewers (what to look for beyond the technical checklist) and candidates (what strong SRE practitioners actually demonstrate).
What SRE Actually Is, and Why the Interview Often Tests Something Else
The standard SRE interview has converged on a format that's half software engineering interview (algorithms, data structures, coding) and half systems interview (networking, storage, Linux internals). There's also usually an incident scenario and some discussion of SLOs, error budgets, and reliability practices.
This format is not wrong, but it measures a narrow slice of what makes an SRE effective. The skills that differentiate great SREs from competent ones — the ability to reason about systems they've never seen before, the judgment about what to automate vs. accept, the communication skills that make on-call tolerable for the team, the taste for where reliability investment pays back — are underweighted or absent in most interviews.
The Dimensions That Actually Matter
Systems thinking: Can the candidate reason about a complex system they haven't seen before? Not just "what does DNS do?" but "given this specific failure symptom, what's the causal chain that could produce it?" Systems thinking is the core SRE skill, and it's best evaluated by presenting a real-ish failure scenario and watching how the candidate approaches it.
The marker of strong systems thinking: the candidate asks questions before proposing hypotheses. They're gathering information to narrow the solution space, not jumping to the first plausible explanation.
Judgment about uncertainty: When the candidate doesn't know something, do they acknowledge it directly and describe how they'd find out, or do they paper over gaps with confident-sounding non-answers? SRE involves a lot of decisions under uncertainty. Candidates who can say "I'd need to look at the CloudTrail logs to determine that" are more valuable than candidates who construct plausible-sounding but unverifiable answers.
The automation instinct: Does the candidate naturally think about automation when describing operational work? When discussing a blog post procedure, does it occur to them to ask "why isn't this automated?" Strong SREs have a visceral discomfort with manual repetitive work that shows up naturally in how they talk about their past experience.
Communication under pressure: The on-call scenario reveals this. When you describe a complex incident, does the candidate communicate their thought process clearly? Can they explain their investigation approach in a way that a non-SRE stakeholder could follow? On-call communication quality is often the difference between an incident that erodes trust and one that builds it.
Post-incident orientation: How does the candidate talk about past incidents? The weak signal is defensiveness or blame. The strong signal is curiosity and systems thinking: "we found that the alert threshold was set based on a different traffic pattern than what we actually saw, and we changed it, but then we also realized the monitoring gap that let the problem develop silently for three hours before any alert fired." Candidates who turn incidents into system improvements are valuable.
Interview Questions That Reveal Actual Competence
The causal chain question:
"A payment service is experiencing elevated 5xx error rates starting about 15 minutes ago. The error message in the logs is 'connection pool exhausted.' Walk me through how you'd investigate this."
Strong candidates: ask about recent deployments, ask about traffic levels (is this normal traffic or a spike?), ask about whether the connection pool exhaustion is for the database or a service dependency, ask about whether this has happened before. They're building a picture before hypothesizing.
Weak candidates: immediately say "increase the connection pool size" without understanding why it's exhausted.
The design question with reliability tradeoffs:
"You're designing a notification system that sends emails when significant events happen in an application. What reliability properties should it have, and how would you design for them?"
Strong candidates: discuss at-least-once vs. exactly-once delivery, idempotency (duplicate emails are a problem), rate limiting (don't spam users), dead letter queues for failed sends, retry logic with exponential backoff, and monitoring (how do you know if emails are failing silently?).
Weak candidates: describe a simple queue-based system without engaging with the failure modes.
The SLO question:
"Teams are discussing SLOs for a user authentication service. What metrics would you include, and how would you set targets?"
Strong candidates: discuss availability (% of auth requests that succeed), latency (P99 response time matters for user experience), and might mention error types (auth failures from invalid credentials vs. service errors are different signals). They'd probably ask about current baseline measurements before proposing targets.
Weak candidates: say "99.9% uptime" without discussing what "uptime" means for this service or how it would be measured.
The toil identification question:
"Walk me through a week in your current or most recent on-call rotation. What was the most repetitive, annoying thing you dealt with?"
Strong candidates: identify specific toil clearly ("we'd get paged every Monday morning when the batch job ran because the disk would fill up, and someone would have to SSH in and clear old log files"), explain why it was allowed to persist ("we kept meaning to fix it but always deprioritized it"), and describe what they wish they'd done ("ideally a cron job would rotate those logs automatically, or we'd move them to S3").
Weak candidates: say on-call was fine, everything was properly automated, no complaints — which is rarely true and signals either lack of experience or lack of observation.
Red Flags That Standard Interviews Miss
The heroics orientation: Candidates who describe their best moments as "I stayed up all night to fix it" or "I single-handedly debugged the outage" without any discussion of what process improvements followed are showing you their mental model. The SRE mental model is: this incident revealed a gap in the system, and we fixed the gap. The heroics model is: I was the hero and saved the day. One of these leads to sustainable reliability; the other leads to burnout.
Confidence disproportionate to demonstrated knowledge: Some candidates have excellent interview performance on familiar questions and confident-sounding answers on questions outside their knowledge. The tell: their answers to familiar questions have specific details, examples, and caveats. Their answers to unfamiliar questions are general and fluent but lack specifics. Push for specifics: "can you give me a specific example of when you've done this?"
No history of being wrong. Ask about a decision they made that turned out to be wrong. The candidate who can't recall one is either not being honest or hasn't been making decisions. Strong SREs are curious about their own errors in the same way they're curious about system failures. "We tried X, it didn't work because Y, and we learned Z" is the narrative you're looking for.
Dismissing non-technical concerns. Some SRE candidates treat stakeholder communication, documentation, and organizational alignment as soft requirements they can deprioritize. In a senior SRE role, these are as important as the technical skills. A candidate who can't engage thoughtfully with "how would you communicate a complex incident to non-technical leadership?" probably hasn't thought about this dimension of the job.
What to Look For in AI-Era SREs
The SRE role is changing as AI tooling becomes part of the standard toolkit. The new signals to look for:
Comfort with LLM-powered tooling. Does the candidate have experience building or operating AI-powered operational tools? Have they built an incident response agent, a cost optimization agent, or similar? This is increasingly a differentiator at senior levels.
Critical evaluation of AI outputs. Does the candidate understand the failure modes of AI in operational contexts? Can they articulate when to trust an AI recommendation and when to second-guess it? The SRE who treats AI output as authoritative is more dangerous than the SRE who refuses to use it at all.
Prompt engineering as an engineering discipline. Can the candidate articulate what makes a good system prompt for an operational use case? Do they think about LLM instructions the way they think about other software specifications — precise, testable, with explicit failure modes?
These aren't questions that most SRE interviews currently ask. They should be.
*Zak Hassan is a Staff SRE with extensive hiring and mentoring experience across enterprise SaaS organizations. Find him at zakhassan.com or on LinkedIn.*
Topic Paths