Linux interview questions

The troubleshooting scenarios

"The server is slow"

• `top` or `htop` first - is it CPU, memory, or neither?
• Load average, and the crucial point that high load with low CPU usually means I/O wait or blocked processes.
• `iostat` or `iotop` for disk, `vmstat` for memory pressure and swapping.
• Is it actually this machine? Check the dependencies before optimising locally.

"The disk is full"

• `df -h` to find the full filesystem, then `du` to find where it went.
• The trap: `df` shows full but `du` does not account for it - a deleted file still held open by a process. `lsof | grep deleted`, then restart the holder.
• Inode exhaustion - `df -i` - where space is free but you cannot create files.
• Log rotation as the usual root cause.

Processes, signals and permissions

• What a zombie process is, and why it is the parent's problem rather than the child's.
• `SIGTERM` versus `SIGKILL`, and why you always try the former first - the latter gives no chance to clean up.
• What the OOM killer does and how it chooses a victim.
• `nohup`, background jobs, and why a process dies when the terminal closes.
• Permission bits read as numbers, plus what the setuid bit does and why it is risky.
• Why is a file not writable despite looking writable? Directory permissions, ownership, filesystem mounted read-only, or an immutable attribute.

Networking and files

`ss` or `netstat` to find what is listening, `curl -v` to test an endpoint properly, `dig` for DNS, and tracing a connection failure through DNS, routing, firewall and the listening service in that order. Then text processing - `grep`, `awk`, `sed`, pipes - and finding large files or recent changes with `find`. The container equivalents of much of this are in Docker interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and saying what you have not done reads better than bluffing.
• Mid-level: the same ground plus servers you have administered and an incident you debugged. Expect follow-ups asking why you made a choice rather than whether you know the syntax.
• Senior: kernel-level tuning, capacity work, and a postmortem you wrote. The recall questions get shorter and the judgement questions get longer.

Whatever the level, say your answers out loud rather than reading them. Most of what candidates lose in a Linux interview is lost between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common Linux interview questions?

Diagnosing a slow server, handling a full disk including the deleted-but-held-open file case, the difference between SIGTERM and SIGKILL, zombie processes, permission bits, and finding what is listening on a port.

What do you do when df says the disk is full but du does not agree?

A deleted file is still held open by a running process, so the space is not released. Find it with `lsof | grep deleted` and restart or signal the holding process. It is one of the most reliable experience checks in a Linux interview.

What is the difference between SIGTERM and SIGKILL?

`SIGTERM` asks a process to terminate and can be caught, allowing it to flush buffers and clean up. `SIGKILL` cannot be caught and terminates immediately, which risks corrupt state. Always try SIGTERM first and escalate only if it does not respond.

What does a high load average with low CPU usage mean?

Processes are runnable but blocked, most often on disk I/O, since Linux counts uninterruptible sleep in load. Check with `iostat` or `vmstat` rather than assuming a CPU problem - it is a distinction interviewers use to separate experience from recall.