Question 1
What would you page a human for in this system, and what should stay a ticket?
Approach. Tie the page to user pain, and say the alert you would delete because it trained people to ignore pages.
Site reliability engineer interview questions from a job description
Turn an SRE job description into likely incident, SLO, and systems questions, grouped by the requirement they test.
Matched in your browser from the requirements in the posting and Luna’s interview-question hub. These are practice prompts, not a claim that this wording will be asked.
Requirements in the posting
Site Reliability Engineer
Keep a customer product up, and make the next incident smaller.
You will:
- Define SLOs and monitoring for the main user actions, including what is worth an on-call page
- Run incident response and write the change that follows, not only the timeline
- Work in Kubernetes and the CI/CD path that ships the service
- Review system design for latency, failure, and capacity before a launch
- Partner with product engineers who still own the code
We will ask about an alert that trained the team to ignore pages.
Keep a customer product up, and make the next incident smaller.
You will:
- Define SLOs and monitoring for the main user actions, including what is worth an on-call page
- Run incident response and write the change that follows, not only the timeline
- Work in Kubernetes and the CI/CD path that ships the service
- Review system design for latency, failure, and capacity before a launch
- Partner with product engineers who still own the code
We will ask about an alert that trained the team to ignore pages.
Likely questions
System design
Reliability and observability
Site Reliability Engineer
Question 2
Walk through an incident. What did the user see, and what changed afterward?
Approach. Timeline in a few beats, then one system change and one team change.
System design
System design
Review system design for latency, failure, and capacity before a launch
Question 3
Design the system behind the main workflow in this posting. What has to be fast, and what can wait?
Approach. Users and API first. Name one bottleneck and the piece you will not build in the interview.
Question 4
How would you estimate capacity before picking a database?
Approach. Use rough numbers, label every assumption, and say which number would change the design.
System design
Containers and cloud
Work in Kubernetes and the CI/CD path that ships the service
Question 5
What would you run in this stack, and what is overkill for the traffic you expect?
Approach. Pick the simplest place the workload can live, then the signal that would justify a move.
Question 6
A container is healthy and the user path is not. How do you debug that?
Approach. Separate process health from the request path, and say the first signal you would open.
System design
Backend services
Work in Kubernetes and the CI/CD path that ships the service
Question 7
Where would you draw the service boundary for this product, and what would you keep in one process for now?
Approach. Start from the request that must be fast, then name the split you would postpone.
Question 8
A dependency you call is slow or down. What does this product do?
Approach. Say the user-visible fallback and the failure you will not hide.
System design
CI/CD and infrastructure
Work in Kubernetes and the CI/CD path that ships the service
Question 9
Walk through how a change for this team should get to production. Where can it stop?
Approach. Name the checks before deploy and the rollback that does not need a hero.
Behavioral
Collaboration
Partner with product engineers who still own the code
Question 10
Tell me about a disagreement with someone who did not report to you. What did you do with their objection?
Approach. Name the objection, what you changed, and what you did not. Do not flatten it into “we aligned.”
What to prepare
- Write one user-facing symptom and the dashboard that would show it within five minutes.
- Narrate one design in sixty seconds before you draw any boxes.
- Explain one deploy target: what runs, what scales, and what you would not autoscale yet.
- Draw one service boundary and say what you would not split out yet.
- Draw the path from merge to production and mark the step that can fail safely.
- Have one story where someone disagreed and you kept the working relationship.
- Mark the three requirements you cannot yet support with a story.
SRE postings are incident interviews with a design chaser. On-call, SLO, and monitoring bullets become “what would you page a human for?” Kubernetes and deploy bullets become how a change gets out and how it comes back. System design bullets become capacity and the user promise you refuse to shed.
They will ask for a timeline: what the user saw, what you looked at, what changed in the system, what changed in the team. A tool list without that story will not carry the round.
Write one SLO for a product you know and one alert you would delete. The sample is a product SRE role.
Sample job description
The posting below is already in the tool. The questions are the ones its requirements point to. Replace it with a posting you are actually interviewing for.
Related: Google system design questions · Netflix system design questions · Capacity estimation