Site Reliability Engineer Interviews: How to Prepare for the Incident, Linux and SLO Rounds

SRE interviews look a lot like software engineering interviews on paper, but the rounds that decide the outcome are different. Most loops include a coding or scripting round, a Linux and networking fundamentals round, a system design round with a reliability focus, and an incident or troubleshooting round. Here is how to prepare for each. Fundamentals: be fast and precise Expect questions such as: what happens when you type a URL into a browser, what is the difference between a process and a thread, how would you find what is using all the memory on a box, and how does DNS resolution work. Answer with the commands you would actually run: top or htop, free -m, ps aux --sort=-%mem, ss -tulpn, dig. Interviewers listen for real habits, not textbook definitions. The troubleshooting scenario "A service keeps restarting, what do you do?" or "Disk is full at midnight on a production database host" are classic prompts. Use a steady order: check impact and scope, look at recent changes, read logs and metrics, form a hypothesis, test it, mitigate first, and fix the root cause later. Say out loud when you would page someone or roll back. A calm, ordered process matters more than finding the answer quickly. SLOs, error budgets and monitoring Be ready to define SLI, SLO and SLA, and to explain how an error budget changes release decisions. A good example: if a service has burned most of its monthly budget, you slow feature releases and spend time on reliability work. Mention monitoring tools you have used, such as Prometheus, Grafana or Datadog, and explain how you avoid alert fatigue by alerting on symptoms users feel rather than every metric. Reliability-focused system design Design prompts often include failure on purpose: design a multi-region service, or handle a noisy neighbour on shared infrastructure. Talk about redundancy, health checks, load shedding, graceful degradation, capacity planning and how you would test failover. Trade-offs are the point: explain what you would give up for higher availability. Scripting and automation You may be asked to write a script that parses logs, monitors disk usage or cleans up old files. Python, Go or Bash are usually fine. Keep it readable, handle errors, and mention how you would schedule and monitor the script. Incident stories Prepare two or three STAR stories: an outage you helped resolve, a postmortem you wrote, and a time you automated away repetitive toil. Keep them blameless and end with what changed afterwards. Practising the live format Most rounds are remote, often with a shared terminal or document. Practise narrating your thinking while you type. Linkjob AI (https://linkjob.ai) gives real-time help during live job interviews and technical interviews, which some SRE candidates use to stay structured when a troubleshooting scenario branches in several directions. Questions to ask Ask how on-call is organised, how many pages a week the team receives, and how reliability work is prioritised against features. The answers tell you a lot about whether the role is real SRE or rebranded operations.