Hello! I want to walk through the system administrator interview questions that actually come up, because a lot of prep guides for sysadmin roles focus on the obvious stuff (what is DNS, explain RAID levels) and skip the parts that trip people up in real interviews.
Sysadmin interviews vary more than most technical interviews. A small company hiring a sole sysadmin will ask very different questions than a large org hiring for a team of six. But there are patterns, and knowing them helps a lot.
What interviewers are testing (and it’s not just memorization)
The Bureau of Labor Statistics puts systems administrator employment at around 159,000 positions in the US, with a median pay of $95,360 as of 2023. It’s a solid field. The hiring process tends to test three things: can you troubleshoot under pressure, do you understand why things work (not just that they work), and can you communicate clearly with non-technical people.
That last one gets people. A lot of sysadmins are excellent technically and struggle to explain outages or decisions to non-technical stakeholders. Interviewers notice.
The networking questions
These come up in almost every interview I’ve heard about:
- Explain what happens when you type a URL into a browser. The expected answer walks through DNS resolution, TCP handshake, HTTP request, server response, and rendering. The interviewer wants to see whether you know all the layers or whether you skip the networking parts.
- What’s the difference between TCP and UDP? When would you use each? TCP for things where you need delivery guarantees (file transfers, web traffic). UDP for things where speed matters more than completeness (video streaming, DNS queries, VOIP). The candidate who can name a specific example for each lands better than the one who just defines the acronyms.
- Walk me through diagnosing a DNS resolution failure. Start at the client (`nslookup` or `dig`), check the local resolver, then move outward. This tests process as much as knowledge.
- What’s a VLAN and why would you use it? VLANs segment network traffic at layer 2 for security or performance reasons. A candidate who’s actually set one up can usually describe a specific reason they needed it.
Linux/OS questions
Most shops run Linux somewhere, even if the primary environment is Windows. Expect these:
- How do you find which process is using a specific port? `netstat -tulnp` or `ss -tulnp` on modern systems, or `lsof -i :
`. Interviewers often ask for multiple ways to do this. - A system is responding slowly. What do you check first? This is an open-ended troubleshooting question and there’s no single right answer, which is the point. A good answer mentions CPU load (`top` or `htop`), memory usage (`free -h`), disk I/O (`iostat`, `iotop`), and network saturation. The order you check them in matters less than covering all the vectors.
- Explain what `chmod 755` does. Owner: read/write/execute. Group: read/execute. Others: read/execute. Simple question, often asked to confirm you actually know octal permissions vs. just recognizing the number.
- How would you automate a recurring task? Cron for simple scheduled tasks, systemd timers for anything more complex on modern systems. Bonus points if you can talk about idempotency: the task should produce the same result whether it runs once or three times.
Questions about backup, recovery, and things going wrong
This section is where I think good candidates separate from average ones. Interviewers love failure scenarios because they reveal whether you’ve actually managed production systems or just studied for the interview.
- Describe your backup strategy for a critical server. The answer should cover 3-2-1 (three copies, two different media types, one offsite), how often backups run, and how you verify them. “I’d use rsync to an S3 bucket nightly” is fine. “I’d set up backups” is not.
- Tell me about a time a system went down and you had to recover it. Behavioral but technically grounded. The interviewer wants to hear your actual troubleshooting process, who you communicated with, and what you’d do differently. A real incident you handled is better than a perfect hypothetical.
- What’s your RTO and RPO? Define both and give an example of how you’d achieve a 1-hour RTO. Recovery Time Objective (how quickly you’re back up) and Recovery Point Objective (how much data you can afford to lose). A 1-hour RTO usually requires automated failover, not manual restoration.
The questions that catch people off guard
These come up less often but they matter:
- How do you stay current with security patches in a large environment? Patch management tools (WSUS for Windows, Ansible for Linux), a staging environment to test before production, and a maintenance window cadence. The interviewer wants to see a process, not “I apply patches when I get to it.”
- A user says their VPN is slow. How do you troubleshoot this? Split-tunnel vs. full tunnel, latency to VPN gateway, ISP issues on the user’s end, server load. This is a lateral-thinking question more than a knowledge question.
How to prepare without just memorizing answers
The best sysadmin interview prep is hands-on. Set up a homelab or use a free-tier cloud account (AWS, GCP, and Oracle Cloud all have generous free tiers) and actually build things: a web server, a basic LDAP setup, a backup pipeline. Being able to say “I set this up last month and ran into X problem” is worth more than a polished memorized definition.
For the behavioral parts, practice out loud. It sounds obvious, but most people don’t do it. If you want structured practice with an AI interviewer who can ask you follow-up questions and give feedback on your answers, Craqly has a mock interview mode that covers technical and behavioral questions in the same session.
That’s really the whole thing. Know your networking layers, know your troubleshooting process, be able to talk about a real failure you handled. Most sysadmin interviews don’t require you to know everything. They require you to show how you think when something breaks.