The Resume Says Linux Expert. The Terminal Disagrees.
A hiring manager at a mid-size managed services firm once described the same interview twice in one week: two candidates, both listed five-plus years of Linux administration, both passed a phone screen with confidence. One sat down at a terminal and immediately typed ls -la /etc/ to orient himself. The other opened a browser and searched "how to check running services linux." Same resume section. Completely different competence levels.
That gap is not unusual. It is the norm. Linux SysAdmin roles attract candidates who have touched Linux, candidates who have administered Linux, and candidates who have memorized enough terminology to sound like they have done both. The screening problem is separating those three groups quickly, fairly, and without relying on gut instinct or a whiteboard quiz that rewards memorization over muscle memory.
The answer is the terminal itself. Specific commands, run against real scenarios, reveal how a candidate actually thinks under operational conditions. Here is a practical breakdown of what to look for and why it matters.
Process and Resource Visibility
Ask a candidate to identify the top five memory-consuming processes on a system. A surface-level response is top or htop. Both are fine starting points. But watch what they do next.
A competent SysAdmin will reach for ps aux --sort=-%mem | head -6 when they need a snapshot they can pipe, parse, or log. They understand the difference between an interactive tool and a scriptable command. They know that top is for watching and ps is for capturing. If they also mention /proc/meminfo or smem for shared memory accounting, that is a signal of depth, not just familiarity.
What to listen for: do they explain why they chose the command, or do they just type it? Genuine competence includes situational awareness. A candidate who says "I'd use ps here because I want output I can grep later" is demonstrating systems thinking, not just command recall.
Disk and Filesystem Triage
Disk-full incidents are one of the most common SysAdmin emergencies. Give a candidate a system where df -h shows a partition at 99% and ask them to find the cause without deleting anything yet.
The competent path looks something like this: du -sh /* 2>/dev/null | sort -rh | head -20 to identify the largest directories at the root level, then drill down. They will suppress permission errors cleanly with 2>/dev/null rather than being confused by the noise. They will use lsof | grep deleted to check for files held open by processes that are consuming space even though they appear removed from the filesystem. That last command is the real differentiator. It requires understanding how Linux file descriptors work, not just how to run du.
Bonus signal: do they check df -i for inode exhaustion? A partition can appear to have free space in bytes but be completely full of inodes. Candidates who check both are thinking like administrators who have actually been paged at 2 a.m.
Service and Systemd Fluency
Most modern Linux distributions use systemd. A candidate who still reaches exclusively for service nginx restart instead of systemctl restart nginx is not necessarily wrong, but it is a data point worth noting. More revealing is what they do when a service fails to start.
Ask them to diagnose a failed service. The correct first move is systemctl status servicename followed by journalctl -u servicename -n 50 --no-pager. Candidates who go straight to /var/log/ without checking the journal first are working from older mental models. That is not disqualifying, but it tells you something about how recently they have been hands-on with modern distributions.
Watch for candidates who use journalctl -xe to get context around the most recent errors. That flag combination, -x for explanatory catalog entries and -e to jump to the end, is the kind of operational shortcut that comes from repetition, not study.
Networking and Connectivity Diagnosis
Network troubleshooting is where Linux SysAdmin and networking competence overlap. A practical scenario: a server cannot reach an external endpoint. Walk me through your diagnosis.
The competent sequence: ping to test basic reachability, traceroute or tracepath to identify where packets stop, ss -tuln (not netstat, which is deprecated on many systems) to check what is listening locally, and curl -v to test application-layer connectivity with verbose output. If DNS is suspected, dig with a specific resolver (dig @8.8.8.8 example.com) isolates whether the problem is local resolver configuration or upstream.
Candidates who reach for nmap before they have ruled out basic connectivity are jumping ahead. That is a pattern worth noting: it suggests they know tools without fully understanding diagnostic sequencing.
Permissions and Security Hygiene
Give a candidate a directory with a permissions problem and ask them to fix it without over-permissioning. This tests two things at once: technical accuracy and security instinct.
The right approach is not chmod 777. It never is. A competent candidate will use ls -la to read the current state, reason through what the application or user actually needs, and apply the minimum necessary permissions. They will know the difference between chmod and chown, and they will understand when setgid on a directory is the correct solution for shared group access rather than opening permissions broadly.
Ask them to find all SUID binaries on a system: find / -perm -4000 -type f 2>/dev/null. Candidates who know this command and can explain why SUID binaries are a security concern are demonstrating the kind of security-aware administration that matters in production environments.
Scripting and Automation Instinct
A SysAdmin who can only work interactively is a bottleneck. Ask a candidate to write a short bash snippet that checks whether a service is running and restarts it if not. The logic is simple. What you are evaluating is whether they structure it cleanly, handle exit codes, and avoid common pitfalls like unquoted variables.
A candidate who uses systemctl is-active --quiet servicename || systemctl restart servicename and can explain the || operator is showing both scripting fluency and systemd knowledge in one line. That is efficient. That is what production scripts look like.
What Deterministic Assessment Adds to This Process
The commands above are a useful interview framework, but subjective evaluation of terminal sessions introduces inconsistency. Two interviewers watching the same candidate will weight different behaviors differently. Structured, rubric-based terminal assessments remove that variance. Platforms like OpsTicket, a product of IT Custom Solution LLC, put candidates through real Linux SysAdmin scenarios scored against deterministic rubrics, producing verifiable results that hiring teams can compare across candidates without relying on interviewer interpretation.
That kind of evidence-first hiring is especially valuable when screening volume is high or when the hiring team includes non-technical stakeholders who need a clear signal they can trust.
The Short Takeaway
Resume keywords and self-reported years of experience are weak signals for Linux SysAdmin competence. The terminal is not. Build your screening around real commands in real scenarios: process triage, disk diagnosis, service management, network sequencing, permissions reasoning, and scripting instinct. Evaluate the reasoning behind the command, not just the command itself. That combination will surface the candidates who have actually done the work.
If you want to talk through how to structure a technical screening process for Linux or other IT roles, reach out to our team. We are happy to share what we have seen work in practice.