Interview Questions For System Administrator

What Actually Separates Good Answers From The Rest

Most people prep for these interviews by memorizing a list of common questions. That approach gets you past the first screening at best. I've sat on panels for three companies and watched candidates parrot textbook answers while quietly failing under basic pressure. What actually matters is how someone thinks when they don't know the answer. I once watched a candidate get a simple scenario — a server's disk usage jumps to 94% at 2 AM and the monitoring dashboard is showing everything as green. They froze. Not because the problem was hard, but because they'd only ever studied the happy path. The right answer involves checking the monitoring agent itself, looking at the journal logs, and realizing that 94% might be misleading if the inode table is exhausted rather than the data blocks. These people knew df and du by heart but had never actually debugged a false-negative monitoring alert.

The Core Interview Questions For System Administrator Candidates

Linux fundamentals come first, obviously. You need candidates who understand process management without reading a cheat sheet every time. Ask about killing a zombie process. The gotcha is that you can't kill a zombie with SIGKILL — it's already dead, its parent just hasn't reaped it. A good candidate explains that. A mediocre one starts listing kill signal numbers. Networking questions separate the people who actually maintain production from the ones who only work in tutorials. Don't ask what a subnet mask is. Ask them to walk through what happens from the moment a browser request hits their Linux box. DNS resolution, TCP handshake, TLS negotiation, the actual HTTP request, and how the kernel processes it at each layer. If they skip the iptables/netfilter part, they're lying about their experience level. I've seen candidates confidently explain rsync as a synchronization tool without understanding that it uses delta transfers. That's not a dealbreaker on its own, but it tells you whether they've actually tuned backups or just read a how-to article. When I asked about compressing a 2TB database dump over a 100Mbps link with a 900ms latency, the people who just said "use rsync" got nowhere. The answer involves pg_dump with custom format, gzip at highest compression, and splitting the transfer across multiple parallel ssh streams using a tool like parallel-ssh.

Shell scripting questions need to be practical. Give them a real log file and ask them to find the top ten IP addresses hitting a 500 error between 3 AM and 4 AM on a Tuesday. Anyone who reaches for grep | sort | uniq -c without mentioning awk for field extraction or a more memory-efficient approach if the log is multi-gigabyte hasn't done this at scale. I've had candidates try to load a 40GB Apache log into memory with Python and then ask why it took eight minutes.

What Most Candidates Get Wrong About Cloud Infrastructure

Every job posting now says "AWS experience preferred" and then lists seven different services in the requirements. Most candidates haven't touched more than S3 and EC2. The honest ones say so. The dangerous ones fumble through answers and you only find out on day three when they accidentally terminate a production RDS instance. Ask about IAM policy structure and least privilege. I had a candidate design a role that granted FullAccess to S3 with a condition key that didn't actually restrict anything. The condition was comparing a string against an empty value, which always evaluates true. They'd copied a template and never questioned whether it worked. This person could deploy a stack in fifteen minutes. They couldn't tell you why that stack had write access to every bucket in the account. Docker questions usually reveal more than people expect. Ask about the difference between COPY and ADD in a Dockerfile. The simple answer is that ADD handles URLs and tar extraction while COPY doesn't. But the deeper answer involves build cache behavior, security implications of ADD pulling from remote sources, and why most multi-stage builds don't need ADD at all. People who've only followed tutorials will give you the surface answer.

Scenario-Based Questions That Actually Predict Performance

The best questions have no single correct answer. Give them a situation with competing constraints and watch how they reason through it. Here's one I use: you have a web application with intermittent latency spikes that correlate with high load, but the CPU and memory metrics look normal. The database query times are within acceptable range. What do you investigate? A strong candidate doesn't jump to a conclusion. They talk about collecting more data first — sampling the network interface for packet loss, checking for TCP retransmissions, looking at disk I/O wait times, reviewing systemd resource limits on the application process, and considering whether a noisy neighbor in a container environment is causing the issue. They mention tools like sar, netstat, ss, iostat, and cgroups introspection. They might even suggest running a flame graph or strace on a affected process. A weak candidate says "check the logs" and stops there. Logs don't help when the problem is intermittent and the application isn't writing errors. I once spent six hours on a similar issue that turned out to be a misconfigured NIC offloading setting on an older Intel card. The hardware was dropping packets under load and the application stack couldn't tell the difference between dropped packets and slow responses.

Another useful question: your backup job has been failing silently for three days and you just found out. Walk me through your response. This tests whether someone has any concept of backup verification or if they're the type who sets and forgets until data loss forces an emergency.

Security Questions Nobody Asks But Should

Most sysadmin interviews skim over security. That's a mistake. Ask about sudoers configuration and the danger of including directories in PATH. A candidate who explains why /tmp is a risk if sticky bit isn't set properly and how symlink attacks work in cron jobs shows they've actually thought about this stuff instead of just running security scans. Also ask about kernel updates and reboot windows. In some organizations you can't schedule reboots. The candidate should understand live patching options, GRUB default entry management, and the difference between yum update and dnf system upgrade in terms of risk. I've worked with people who treated kernel updates as optional. That's not optional in a security-conscious environment.

What To Do When Candidates Can't Answer

Sometimes they genuinely don't know something. That's fine. What matters is whether they admit it or start inventing an answer. I once hired someone partly because they said "I don't know, but here's how I'd find out" and then walked through checking the man pages, reading the relevant RFC, and testing in a lab environment. Another person confidently explained a solution that would have deleted half the production database. Both had four years of experience on paper. Practical tests beat written answers every time. Set up a broken VM, give them a checklist of symptoms, and let them diagnose it in thirty minutes. Watch whether they read the documentation first or start randomly changing settings. The ones who check dmesg and journalctl before rebooting are the ones you want. The people who survive these interviews aren't the ones who know every command. They're the ones who understand that systems fail in weird ways, who stay calm when something breaks, and who can figure out what they don't know without making it someone else's problem at 3 AM.