I have about 17 years of IT experience, mostly as a technician, and around five years of hands-on Linux administration through my homelab and small-business client work. I run a headless Debian system continuously for DNS and DHCP, maintain multiple containers, and have worked with Proxmox, routers, network-based Clonezilla restores, backups, and infrastructure setup. I have also used Ansible to deploy repeatable configurations. This is my first interview in about five years, and I would like to know what kinds of technical and scenario-based questions to expect for a Linux administrator role. I often look up commands or documentation when I cannot remember the exact syntax, so I am more interested in how to present my troubleshooting approach and practical experience as capable and honest.
5 Answers
Some practical questions you could rehearse include: What do you check first when someone reports that a service is down? How do you find which process is listening on a port? Why would a service bound to 127.0.0.1 be unreachable from another machine? How do you inspect logs from the previous boot? How do you identify what is launching a process every few minutes? How do you find files containing a particular string or remove files older than a certain age? Also review subnet calculations, DNS over UDP and TCP, traceroute, hard versus symbolic links, file permissions, shared groups, and safe editing of configuration files.
For a mid-level role, expect questions about how you think rather than a quiz on obscure command options. They may ask how you would troubleshoot a slow server, a full filesystem, high CPU or memory usage, a service that will not start, or a network connection that fails. Be comfortable discussing systemd, journalctl, logs, SSH, permissions, DNS, routing, firewall rules, and tools such as top, ps, df, du, ss, tcpdump, and iostat. Explain what you would check first and why, then how you would narrow the problem down. Your homelab is useful experience, but clearly distinguish it from production work.
Do not pretend to know something you do not. A good answer can be: “I have not worked with that directly, but I would start by checking the documentation and relevant logs, reproduce the issue safely, compare it with a known-good system, and verify the fix.” Connect answers to real examples: explain how you configured DHCP, maintained your Debian host, managed containers, restored a backup, or automated client configurations. Interviewers are often evaluating judgment, communication, and the ability to learn as much as command-line recall.
Interviewers may also test whether you can scale and automate your work. Be ready to discuss Bash or Python, Git, Ansible, configuration management, containers, monitoring, backups, and infrastructure as code. A question might be: “How would you change a configuration on 50 or 5,000 servers?” A strong answer would mention version-controlled changes, testing, staged rollouts, idempotent automation, logging, monitoring, and a rollback plan. They usually care more about understanding the underlying operating system and networking than about memorizing a particular orchestration command.
I have used Ansible for repeatable configuration deployments and Docker for containers, mostly in my lab and occasionally for small-business systems. I will make sure to explain what I actually built and how I handled repeatability and troubleshooting.
There may be questions about Linux internals and architecture, such as how swap works, what load average represents, what a process in uninterruptible sleep means, how an HTTPS request travels through the network stack, or how you would investigate a failing disk. The expected depth depends on the position. It is fine to answer at the level you genuinely understand, then say where your knowledge ends. Also be ready to discuss incidents, documentation, teamwork, change control, and what happens when a reboot is not an acceptable solution.
It is worth practicing scenario answers aloud. For example, with an HTTP problem, start by confirming the scope and expected result, test DNS and connectivity, check the listening socket and local firewall, inspect service and system logs, review recent changes, and then trace the request path if needed.