September 18, 2026·5 min read
The best Linux interview question is not a question. It is an SSH prompt on a machine where something is wrong, and the sentence "the service should be answering on port 8080 and it is not".
Everything useful happens in the next ninety seconds, and almost none of it is knowledge. Anyone can memorise what lsof does. Very few people can pick which of six plausible causes to rule out first, while someone watches, without saying "I would google it" as though that settled the matter.
This post is the set of scenarios we have found most discriminating, what each one is actually for, and how to score them.
Command recall is the cheapest thing to acquire and the first thing to go. An engineer who has run production Linux for eight years and lived in a managed environment for the last two will fumble the exact flags for ss and diagnose the problem correctly anyway. A candidate who revised last night will name the flags and have no idea which to run.
The famous questions have famous answers. What happens when you type a URL and press enter. Explain the boot process. Explain a fork bomb. These are essays, and essays are what models are best at.
Nothing about the answer tells you the order. Diagnosis is a sequence of decisions under uncertainty. A conversation flattens that into a list of things the candidate knows, which is the part you least need to measure.
Each of these takes ten to twenty minutes on a throwaway machine. Run two, not six.
1. The disk that is full, except it is not. Writes fail and the numbers do not agree. Either df shows space free while the inodes are exhausted, or df shows the filesystem full while du cannot account for the space, because a deleted file is still held open by a running process. What it separates: candidates who check df -i and lsof +L1 from candidates who start deleting logs. The second group will eventually free enough space and will not know what happened, which is the same outcome you will get from them in production at 3am.
2. The service that is running and not listening. systemctl says active. Nothing answers on the port. The cause can be a bind to localhost only, a firewall rule, a SELinux denial, or a process that started, failed its real work, and stayed up. What it separates: whether they check the socket rather than the service. The move you want to see is ss -lntp in the first minute, then reading the actual journal instead of the status summary.
3. The machine that is slow with nothing running. Load average of 12, CPU mostly idle. It is IO wait, or it is a huge number of processes in uninterruptible sleep on a hung mount. What it separates: whether the candidate knows load average is not CPU usage. This one question sorts more people than any other on the list.
4. The permission that looks right. The file is owned by the right user with the right mode and the process still cannot read it, because a parent directory lacks execute, or the process runs under a different user than assumed, or there is an ACL, or the unit file has ProtectHome set. What it separates: whether they check the whole path and the actual effective user rather than the file they were told about.
5. The certificate, the clock, or the resolver. A client fails to connect to a service that is healthy. Cause is DNS returning a stale record, or the system clock drifted far enough to invalidate TLS, or the resolver is pointed at something that no longer exists. What it separates: whether they test the layers separately. Resolve the name, connect to the IP, then do the TLS handshake, in that order. Candidates who conflate all three and conclude "the network is broken" are telling you how their incident calls will go.
6. The cron job that works when you run it. Runs fine by hand, does nothing on schedule, because the environment under cron is not the interactive environment. cron sets a minimal PATH of /usr/bin:/bin and sources no shell profile, so anything the login shell exported is gone. HOME and SHELL are set, which is part of what makes it confusing. What it separates: engineers who have been bitten by this exactly once and never forget it. It is a good closing question because it is fair, common, and rarely revised for.
The single strongest signal in this interview is what the candidate does before typing anything.
Do they say what they expect? "If it were the firewall, I would see the port listening and the connection refused from outside. Let me check whether it is listening at all." A candidate who narrates a hypothesis is doing science. One who runs commands in an order you cannot reconstruct is doing archaeology.
Do they check the cheap thing first? Reading a config file is expensive and speculative. ss, journalctl -u, dmesg -T | tail are cheap and decisive. Ordering by cost is a habit, and the habit is what you are hiring.
Do they change one thing at a time? The candidates who worry us most are the fast ones who edit three files, restart, and find it working. They have not solved anything, they have reshuffled it, and they will do the same to your production host.
Do they say when they are stuck? Twelve minutes of silent flailing is a real answer about how they behave on a call. So is "I have ruled out the socket and permissions, I am now going to look at the unit file, and if that is clean I am out of ideas".
Every one of these scenarios is a fact about a running system. Described out loud, they all collapse into "I would check the logs", which every candidate says and which distinguishes nobody.
In EasyEnv the candidate gets a real box, pre-broken in the way you chose, with a terminal and a recorded session. You review the command sequence afterwards, which matters because the sequence is the assessment. The same environment serves the rest of the loop: what a real DevOps interview should look like fits the wider process around it.
Let them use a model. A model will explain inode exhaustion beautifully and cannot tell them whether it is what is happening on this host. Watch whether they go and check, and whether they notice when a confident suggestion does not match what the machine is saying.
Do not break four things at once. A single fault with a clear symptom produces a clean read. A machine with several faults produces confusion, and confusion is not a measurement.
Do not require the fix. Finding the cause and stating the fix is a pass. Actually applying it is often the least interesting part, and it eats the clock.
Do not sit in silence. Play the role of the colleague who knows the system: answer factual questions, refuse to give hints. That is the real working condition, and the questions they ask you are half the signal.
What is the last thing that broke on one of your hosts, and would your interview have found somebody who could fix it?
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Timed task platforms measure correct code written alone against a clock, which is a real skill and a narrow slice of the job. Here is what a task score can and cannot see, and how to decide whether you need a different kind of assessment.
Engineering managers should not take coding tests, and most EM loops overcorrect into pure behavioural questions that everyone has rehearsed. Here is a middle path that tests the judgment calls the job actually consists of.
Read more
Most QA interviews test vocabulary, and vocabulary is not the skill. Here is how to assess testers and test automation engineers on a running application, starting with the single best question there is: a genuinely flaky test.
Read more
