Six Failure Modes, One Host, Eight Minutes to Triage
One host, six plausible explanations, and eight minutes before the interviewer expects an ordered plan instead of a list of commands. That is the opening bind in this mid-level Site Reliability Engineer (SRE) mock interview on Linux System Administration: a stateless API host keeps getting pulled from rotation, SSH is flaky, and the service will not stay up after a restart. This walkthrough is built from a real InterviewStack.io mock interview blueprint, the same interview_package the AI interviewer scores you against, and it follows one candidate, Caleb, through the same 30-minute simulation, mistakes included, so you can see exactly where a knowledgeable candidate still loses points.
Key Findings
- The rubric splits 100 points across 4 dimensions: Interviewer Objectives Alignment (30), Level-Specific Expectations (30), Technical Proficiency (20), and Communication and Problem Solving (20).
- The interview runs 30 minutes across 3 phases: triage (0-8 min), deep-dive diagnosis (8-20 min), and recovery plus prevention (20-30 min).
- Phase 1 alone carries 5 checklist items to hit in the first 8 minutes.
- The deep-dive phase is the longest single phase at 12 minutes, and it carries 5 checklist items of its own.
- Phase 3 requires naming at least 2 durable prevention measures, not just one, to fully satisfy the checklist.
- 4 skill areas are explicitly off-limits for this scenario, including Kubernetes orchestration internals and cloud architecture design beyond the single host.
What Is the Site Reliability Engineer Linux System Administration Interview Grading You On?
The interview question
You are the primary SRE on call for a stateless API service running on a small fleet of Ubuntu Linux VMs behind a load balancer. Since this morning, one instance has been repeatedly marked unhealthy and removed from rotation. Product engineers report that SSH still works intermittently, but deployments to that host are failing and the service does not stay up for long after restart. You have terminal access to the host and are expected to stabilize it quickly without rebuilding it immediately, because capacity is already tight.
Walk me through how you would investigate and recover this Linux host.
The interviewer is not grading whether you know Linux commands in the abstract. The objective is practical: diagnosing a host-level incident, reasoning correctly about common failure modes like disk exhaustion, inode exhaustion, OOM kills, and stuck I/O, and mitigating safely under production constraints where capacity is already tight and a rebuild is not the first move. Judgment and level-appropriate depth carry 60 of the 100 points between them; getting the right Linux command is worth less than getting the right sequence.
Interviewer Objectives Alignment and Level-Specific Expectations each carry 30 points, together outweighing the 20-point Technical Proficiency and 20-point Communication dimensions combined.
What Does a Prepared Candidate Still Get Wrong Here?
Below are four of the interview's follow-ups, the ones that separate a candidate who knows Linux from one who can run an incident on it. Each turn tests a different phase of the blueprint, and each mistake is the kind that looks obvious in hindsight and easy to make live.
Turn 1: Naming the First Check
Interviewer: "What host-level signals or commands would you check first to decide whether this is a CPU, memory, disk, filesystem, network, or service-management problem?"
Turn 2: The Full Filesystem
Interviewer: "Suppose you discover the root filesystem is 100% full. How would you confirm the cause, recover the instance safely, and reduce the chance of this recurring?"
Turn 3: SSH Starts Lagging
Interviewer: "Imagine SSH becomes slow and commands hang intermittently during your investigation. What Linux failure modes would you suspect, and how would you keep troubleshooting without making the situation worse?"
Turn 4: Fixing It for the Fleet
Interviewer: "After stabilizing the box, what permanent fixes or hardening changes would you propose for the fleet so this kind of incident is easier to detect and recover from?"
What Changes When the Terminal Itself Starts Lagging?
Every mistake above is obvious once it is sitting in a red box with a label on it. Catching Caleb reaching for rm -rf on a slide is not the same skill as not reaching for it yourself when your own root filesystem is at 100%, the clock is at minute eleven, and a second host just got pulled from rotation. The scenario's own twist, an SSH session that starts lagging mid-investigation, exists to test exactly that gap: can you keep a level head and read one more signal, vmstat, free, dmesg, instead of panicking into a reboot that erases the evidence you actually need. That instinct only gets built through reps, not through reading about them.
The only way to build it under real conditions is to run the scenario yourself. Start the AI mock interview on Linux System Administration and see whether your triage order holds up when the pressure is real, not hypothetical.
From First Command to Fleet-Wide Fix: The Complete Blueprint
Eight minutes to frame the incident, twelve to diagnose it in detail, and ten to recover and harden the fleet, the same pacing the AI interviewer holds you to.
This is the blueprint a strong candidate hits end to end, and it is the exact thing the AI interviewer tracks you against in real time, phase by phase, checklist item by checklist item.
- ✓Clarifies immediate priorities such as impact, whether traffic can be drained, and whether the issue is isolated to one host or fleet-wide
- ✓States an ordered triage plan rather than listing random commands
- ✓Checks service state and recent logs using systemctl/journalctl or equivalent
- ✓Checks core host resources: CPU, memory, disk usage, inode usage, load, and possibly recent kernel messages
- ✓Mentions verifying recent deploy/config/package changes or scheduled jobs if relevant
- ✓Can explain how they would distinguish disk-full versus inode-full using df -h and df -i
- ✓Can identify likely sources of space growth such as application logs, journal growth, crash dumps, temporary files, old artifacts, or deleted-but-open files
- ✓Mentions using du carefully, checking journald/app logs, and using lsof for deleted open files if appropriate
- ✓Can describe signs of OOM or memory pressure via free/vmstat/dmesg/journalctl and connect them to service restarts
- ✓Explains how to inspect systemd unit status, restart loops, exit codes, and recent service logs to separate app failure from host failure
- ✓Proposes a recovery plan that is minimally risky, such as draining traffic, reclaiming space safely, validating service health, and only then reintroducing the host
- ✓Avoids unsafe actions like blind rm -rf, indiscriminate package removal, or repeated restarts without evidence
- ✓Mentions validating the fix with concrete checks such as service status, health endpoint, disk headroom, and logs after restart
- ✓Suggests at least two durable prevention measures for the fleet: logrotate/journald limits, disk/inode alerts, tmp cleanup policy, deployment artifact retention, or clearer runbooks
- ✓Communicates escalation criteria, such as replacing the node if filesystem corruption or hardware/I/O issues are suspected
Run This Recovery Before It's a Real Page
Reading a mistake is not the same as not making it at 2 a.m. with a live incident and a full disk. Start the mid-level SRE mock interview on Linux System Administration and get scored against this exact blueprint, phase by phase, as you go. Want to warm up on the underlying concepts first? Browse the Linux System Administration question bank or the broader SRE preparation guides before you run the live simulation. Already comfortable with host recovery and curious about the on-call leadership side of the job? The incident command walkthrough picks up right after this scenario's host is stable.
FAQ
Q. What does the Site Reliability Engineer Linux System Administration mock interview actually score?
It splits 100 points across four dimensions: Interviewer Objectives Alignment (30), Level-Specific Expectations (30), Technical Proficiency (20), and Communication and Problem Solving (20). For this scenario, that means structured triage and safe recovery decisions carry more weight than reciting Linux commands correctly.
Q. How is the 30-minute interview paced?
It runs in three phases: initial triage and hypothesis formation from minute 0 to 8, a deep dive on host-level diagnosis from minute 8 to 20, and recovery, prevention, and communication from minute 20 to 30. Each phase has its own checklist the AI interviewer tracks in real time.
Q. How do you tell disk-full from inode-full on a Linux host?
Run df -h to check block usage and df -i to check inode usage separately. A host can show free blocks in df -h while still refusing writes because it ran out of inodes, usually from millions of small files, so checking only df -h and assuming the disk itself is the problem is a common way candidates lose points in this interview.
Q. What if systemd keeps restarting the service and you can't tell why?
Check the unit's restart count and recent exit codes with systemctl status, then read the surrounding journalctl -u output for the application's own error before it exits. The goal is separating a misbehaving application from an unhealthy host underneath it, which the interview's deep-dive phase specifically evaluates.
Q. Is it ever correct to just reboot the host?
Only after you have gathered enough evidence to know a reboot will not destroy what you are trying to diagnose. Restarting repeatedly without evidence is explicitly called out as an unsafe move in this interview's rubric, and a mid-level candidate is expected to validate before restarting, not restart to see what happens.
Q. When should you replace the host instead of continuing to recover it?
The interview rewards naming escalation criteria explicitly: if you suspect filesystem corruption or a hardware or I/O failure underneath the host, the right call is replacing the node rather than continuing to nurse it back, especially once you have already spent real time on the box.
Triage Order Is a Skill, Not a Guess
Caleb's mistakes were never about missing Linux knowledge. Every fix Caleb needed was already available; the lost points were about sequencing, checking the host broadly before narrowing, confirming a cause before deleting anything, reading one more signal before rebooting. That discipline is exactly what this mock interview scores, and it is exactly what a page at 2 a.m. rewards too.
Topics
Ready to practice?
Put what you've learned into practice with AI mock interviews and structured preparation guides.