You have used Linux every day for two years. You deploy to it, you SSH into it, you tail its logs at 2 a.m. when something is on fire. Then the interviewer leans in and asks why a file you own refuses to be deleted, and your mind goes quiet. Not because you do not know Linux, but because you have never had to say it out loud.

That gap, between using Linux and explaining Linux, is exactly what interviews probe. The questions below are the ones that actually get asked, grouped from the fundamentals a junior must not fumble to the live troubleshooting that separates senior candidates from the rest. Every answer is written the way a strong candidate would say it in the room, with a short note on what the interviewer is really checking. Every command was run on a clean Ubuntu 24.04 box, and the output is copied, not invented.

How Linux Interviews Actually Work

Linux interviews rarely look like a quiz. They come in four shapes, and knowing which one you are in changes how you answer.

Rapid-fire fundamentals. Short questions to confirm you are not bluffing: what does chmod 644 mean, what is the difference between a hard and a soft link. Answer these in one or two sentences and move on. Over-explaining a basic question reads as nervousness.

"Explain this" questions. The interviewer names a concept (signals, inodes, the boot process) and watches how you structure an explanation. They are testing whether you understand the why, not just the command.

Live troubleshooting. You share a terminal, they break something, and you debug it out loud. This is the most senior-discriminating format because you cannot memorize your way through it. Narrate your thinking: what you check first, and why.

Take-home or scripting. A small bash task, graded on correctness and on whether you write a script that fails safely.

One more thing worth saying early: nobody knows every flag. A senior candidate who says "I would check man tar for the exact flag, but the approach is..." scores higher than one who guesses and gets it wrong. Knowing how to read the system documentation is itself a skill interviewers respect.

Fundamentals

Q1. What is the difference between a process and a thread?

A process is a running program with its own isolated memory space. A thread is a unit of execution that lives inside a process and shares that process's memory with its sibling threads. Creating a process is heavier (the kernel sets up a new address space), while threads are cheaper and can talk to each other directly through shared memory, which is also what makes them harder to get right.

What they're really testing: whether you understand isolation. Processes fail independently; one crashing thread can take down its whole process.

Q2. Explain chmod 644. What do those numbers mean?

Each digit is a permission set in octal, for owner, group, and others, in that order. Read is 4, write is 2, execute is 1, and you add them up. So 644 is read and write for the owner (6), read for the group (4), and read for others (4).

$ chmod 644 report.txt
$ ls -l report.txt
-rw-r--r-- 1 root root 6 Jun 17 06:42 report.txt
$ stat -c "%a %A %n" report.txt
644 -rw-r--r-- report.txt

The leading - in -rw-r--r-- is the file type (a dash for a regular file, d for a directory, l for a symlink). If you are still translating the rwx bits in your head, our guide to Linux permissions walks through them from scratch.

What they're really testing: can you read a permission string at a glance, the way you will need to every time you debug an access error.

Q3. What is the difference between an absolute and a relative path?

An absolute path starts from the root and always begins with /, so /var/log/syslog points to the same file no matter where you are. A relative path is resolved from your current directory, so log/syslog means something different depending on where you stand. In scripts, prefer absolute paths or anchor relative ones deliberately, because a script that assumes the wrong working directory is a classic 2 a.m. bug.

Q4. How do you check disk space, and how is that different from file size?

df reports free space per mounted filesystem; du reports how much space a given path actually uses.

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
overlay         458G   23G  412G   6% /
$ du -sh /tmp/wk
12K	/tmp/wk

The mnemonic that sticks: df is "disk free" (the whole filesystem), du is "disk usage" (a directory tree). They answer different questions, and confusing them is how people end up deleting the wrong thing.

Q5. What is the difference between a hard link and a symbolic link?

A hard link is a second name pointing at the exact same inode (the same physical data on disk). A symbolic link is a small separate file that just holds a path to another file. You can see it directly:

$ ls -li original.txt hardlink.txt softlink.txt
616701 -rw-r--r-- 2 root root  5 Jun 17 06:42 hardlink.txt
616701 -rw-r--r-- 2 root root  5 Jun 17 06:42 original.txt
616702 lrwxrwxrwx 1 root root 12 Jun 17 06:42 softlink.txt -> original.txt

Notice original.txt and hardlink.txt share inode 616701 and show a link count of 2. The symlink has its own inode and literally points at the name. The practical consequences: delete the original and the hard link still works (the data survives until the last name is gone), but the symlink becomes a dangling pointer. Hard links also cannot cross filesystems or link directories; symlinks can do both.

What they're really testing: do you understand that a filename is just a pointer to an inode, not the data itself. That idea pays off again in Q20 and Q26.

Q6. How do you find files on a Linux system?

find for a live search by name, type, size, or modification time, and locate for a fast lookup against a prebuilt database when you just need a path quickly.

$ find /tmp/wk -type f -name "*.txt"
/tmp/wk/original.txt
/tmp/wk/report.txt
/tmp/wk/hardlink.txt

find is the one to know cold, because it composes: find /var/log -name "*.log" -mtime +7 -delete finds and removes logs older than a week in one line. The trade-off is that find walks the tree every time, while locate is instant but only as fresh as its last database update.

Q7. What are stdin, stdout, and stderr, and how do you redirect them?

Every process gets three streams by default: standard input (file descriptor 0), standard output (1), and standard error (2). The key insight for interviews is that normal output and error output are separate streams, so you can route them independently. command > out.log sends stdout to a file, 2> err.log sends stderr, and command > all.log 2>&1 merges both into one file. That last one trips people up: 2>&1 means "send stderr to wherever stdout is currently going", so order matters.

Q8. How do you view and search the contents of a file?

cat for short files, less for anything large (it pages without loading the whole file into memory), and grep when you know what you are looking for. grep is the workhorse:

$ grep -E " (401|403)$" access.log
192.168.1.11 POST /login 401
192.168.1.42 GET /admin 403

For a senior answer, mention tail -f to watch a log live and grep -r to search a directory tree. Reaching for less instead of cat on an unknown file size is a small tell that you have been burned before.

Intermediate

Q9. How do you see what is running and stop a process?

ps aux for a snapshot, top or htop for a live view, and kill to send a signal to a PID.

$ ps aux --sort=-%mem | head -3
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2696  0.0  0.0   7888  4044 ?        R    06:43   0:00 ps aux --sort=-%mem
root         1  0.2  0.0   4324  3592 ?        Ss   06:42   0:00 bash

The detail that signals experience: kill does not mean "force stop", it means "send a signal". kill <pid> sends the polite SIGTERM and lets the process clean up; kill -9 <pid> sends SIGKILL, which the process cannot catch or ignore. Reach for -9 only after TERM has failed, because SIGKILL gives the process no chance to flush buffers or release locks.

Q10. What is a signal? Name the ones you use most.

A signal is an asynchronous notification the kernel delivers to a process. The three every candidate should know by number:

$ echo "HUP=$(kill -l HUP) KILL=$(kill -l KILL) TERM=$(kill -l TERM)"
HUP=1 KILL=9 TERM=15

SIGTERM (15) asks a process to shut down gracefully and can be handled. SIGKILL (9) cannot be caught, blocked, or ignored, so the process dies immediately with no cleanup. SIGHUP (1) originally meant the terminal hung up, but many daemons now treat it as "reload your config without restarting". Knowing that SIGKILL is uncatchable explains why a wedged process sometimes ignores everything except -9.

Q11. Walk me through the Linux boot process.

At a high level: firmware (BIOS or UEFI) runs its power-on checks and hands off to a bootloader, usually GRUB. GRUB loads the kernel and an initial ramdisk (initramfs) into memory. The kernel initializes hardware, mounts the root filesystem, and starts the first process, PID 1, which on every current mainstream distribution is systemd. systemd then brings the system up to its target state by starting services in dependency order.

The modern detail worth adding: systemd replaced the old SysV init and numbered runlevels with targets (for example multi-user.target for a server, graphical.target for a desktop). If they want depth here, our walkthrough of booting and changing operating modes covers targets in detail.

What they're really testing: whether you can reason about a box that will not come up, by knowing the stages where it can get stuck.

Q12. How do you manage services with systemd?

systemctl is the control surface, and journalctl reads the logs. Start, enable on boot, and check status:

$ systemctl start hello.service
$ systemctl status hello.service
* hello.service - Hello demo service
     Loaded: loaded (/etc/systemd/system/hello.service; static)
     Active: active (running) since Wed 2026-06-17 06:43:44 UTC; 11ms ago
   Main PID: 73 (sleep)

The distinction interviewers fish for: systemctl start runs a service now, systemctl enable makes it start on boot, and they are independent. A service can be enabled but stopped, or running but not enabled (so it vanishes after a reboot). For logs, journalctl -u <service> scopes to one unit, and -f follows it live.

Q13. How do package managers work, and how do apt and yum/dnf differ?

They resolve and install software along with its dependencies from configured repositories. On Debian and Ubuntu the high-level tool is apt (sitting on top of the lower-level dpkg); on RHEL, Fedora, and their relatives it is dnf (the successor to yum, on top of rpm). The split that matters: dpkg and rpm install a single package file you already have, while apt and dnf talk to repositories and pull in dependencies automatically. If someone hands you a lone .deb, dpkg -i installs it but will not fetch its dependencies; apt install ./file.deb will.

Q14. What is the difference between >, >>, and 2>&1?

> redirects stdout and truncates the target file first, so it overwrites. >> appends instead of truncating. 2>&1 redirects stderr to the same place stdout is going. The combination people get wrong is ordering: command > file 2>&1 works (point stdout at the file, then send stderr to that same place), but command 2>&1 > file sends stderr to the original terminal because you redirected it before moving stdout. State the rule plainly: redirections are evaluated left to right.

Q15. How do environment variables work, and where do you set them?

An environment variable is a key-value pair inherited by child processes. You set one for the current shell with NAME=value and export it to children with export NAME=value. The interview hook is where you persist them:

$ echo "$PATH" | tr ":" "\n" | head -4
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin

~/.bashrc runs for interactive non-login shells (a new terminal tab), while a login shell (an SSH session) reads ~/.bash_profile (or ~/.profile) and does not read ~/.bashrc on its own unless that file sources it, which Ubuntu's default ~/.profile does. Put a variable in the wrong one and it can mysteriously be missing in one context but present in the other. PATH is just a colon-separated list the shell searches, in order, to find a command.

Q16. How do you schedule a recurring task?

The classic answer is cron: you add a line to a crontab with five time fields (minute, hour, day-of-month, month, day-of-week) and a command. 0 2 * * * runs at 2 a.m. daily. The modern alternative is systemd timers, which are more verbose but give you logging through the journal, dependency handling, and the ability to catch up on a missed run (Persistent=true). For a quick periodic job, cron is fine; for anything that needs observability, timers are the better answer, and saying so shows range.

Q17. What is a zombie process, and what is an orphan?

A zombie is a process that has finished but whose parent has not yet read its exit status, so it lingers in the process table as a Z state with no resources except that one entry. An orphan is a process whose parent died first; it gets re-parented to PID 1 (systemd), which adopts it and reaps it when it exits. The practical point: a single zombie is harmless, but a flood of them means a parent that is not calling wait(), which is a bug in that parent, not something you fix by killing the zombie (it is already dead).

Advanced

Q18. What does it mean when a process is "OOM-killed", and how would you spot it?

When the system runs out of memory, the kernel's OOM killer picks a process and sends it SIGKILL to reclaim memory. You spot it two ways. First, the exit code: a process killed by a signal exits with 128 + signal number, and since SIGKILL is 9, an OOM-killed process shows exit code 137. Second, the kernel log: dmesg or the journal will contain an Out of memory: Killed process line naming the victim. This is a favorite because exit 137 shows up constantly in container land, and knowing it means "the kernel killed me for using too much memory" saves hours.

Q19. Explain SUID, SGID, and the sticky bit.

These are the special permission bits beyond rwx. SUID on an executable makes it run with the file owner's privileges rather than the caller's, which is how passwd lets an ordinary user update /etc/shadow. SGID does the same with the group, and on a directory it makes new files inherit that directory's group. The sticky bit on a directory (you have seen it on /tmp) means only a file's owner can delete it, even if others can write to the directory. In a long listing they replace the execute bit: an s where x would be for SUID/SGID, a t for the sticky bit. Interviewers like SUID because it is a real privilege-escalation surface, so an answer that mentions the security angle stands out.

Q20. What happens if you delete a file that a running process still has open?

The file's directory entry disappears immediately, but the data is not freed until the last open file descriptor is closed. Linux removes the name, while the inode and its blocks stay alive as long as a process holds the file open. You can see the kernel admit it:

$ exec 3>/tmp/openfile.log
$ rm /tmp/openfile.log
$ ls -l /proc/$$/fd/3
l-wx------ 1 root root 64 ... /proc/1/fd/3 -> /tmp/openfile.log (deleted)

The (deleted) marker is the whole answer. This is exactly why deleting a huge log file does not free disk space if a process still has it open: you have to restart or signal the process (or truncate the file with > file instead of deleting it). It connects straight to Q26.

Q21. What does the load average actually measure?

The three numbers from uptime are the 1, 5, and 15 minute averages of the number of processes that are either running or waiting to run, plus, on Linux specifically, processes in uninterruptible sleep (the D state, usually blocked on I/O).

$ uptime
 06:42:24 up 1 min,  0 user,  load average: 1.00, 0.40, 0.15

The senior nuance: load is not CPU percentage. On a 4-core box a load of 4.0 means fully busy, while the same 4.0 on a single core means heavily overloaded. And because Linux counts I/O waiters, a high load with idle CPUs points at disk or network blocking, not compute. Comparing the 1-minute against the 15-minute number tells you whether the spike is rising or fading.

Q22. What is ulimit, and what is the difference between a soft and a hard limit?

ulimit controls per-process resource caps, like the maximum number of open file descriptors.

$ ulimit -Sn   # soft limit
1048576
$ ulimit -Hn   # hard limit
1048576

The soft limit is the value actually enforced and can be raised by the user up to the hard limit. The hard limit is the ceiling: any process can lower its own hard limit, but raising it needs privilege (root, or CAP_SYS_RESOURCE). This shows up in the wild as the dreaded "too many open files" error: the fix is to raise the soft limit (often in /etc/security/limits.conf or a systemd unit's LimitNOFILE), and knowing the soft-versus-hard distinction is what lets you raise it correctly.

Q23. How does hostname resolution work on Linux?

When something needs to resolve a name, the order is governed by /etc/nsswitch.conf, whose hosts: line typically says files dns. That means the system checks /etc/hosts first and only then asks DNS, using the servers listed in /etc/resolv.conf. The reason this matters in an interview: a box that resolves a name "wrong" is often a stale /etc/hosts entry winning before DNS, and the person who checks nsswitch.conf and /etc/hosts before blaming DNS looks like someone who has debugged it before.

Q24. What is the difference between grep, sed, and awk?

grep finds lines that match a pattern. sed is a stream editor for transforming text, most often substitution. awk is a small language for column-oriented data. The cleanest way to show you know them is one example each on the same file:

# grep: show only error responses
$ grep -E " (401|403)$" access.log
192.168.1.11 POST /login 401

# awk: count requests per client IP
$ awk '{count[$1]++} END {for (ip in count) print count[ip], ip}' access.log | sort -rn
2 192.168.1.11
2 192.168.1.10
1 192.168.1.42

# sed: redact the last octet of each IP
$ sed -E 's/([0-9]+\.[0-9]+\.[0-9]+)\.[0-9]+/\1.XXX/' access.log | head -1
192.168.1.XXX GET /index.html 200

The one-line summary that lands: grep to find, sed to change, awk to work with fields. If you want to get comfortable composing these, the advanced bash scripting guide drills exactly this.

Q25. How do you write a bash script that fails safely?

Start it with set -euo pipefail. -e exits on the first command that fails, -u treats an unset variable as an error instead of an empty string, and -o pipefail makes a pipeline fail if any stage fails, not just the last one. Then quote your variables ("$var"), because an unquoted variable that is empty or contains spaces is how scripts delete the wrong files. The difference between a junior and a senior script is not cleverness, it is that the senior one stops at the first sign of trouble instead of charging ahead with a bad value. A solid grounding in shell scripting is worth more interview points than any single command.

Scenario and Troubleshooting

These questions mirror real incidents, not trivia, and the best way to prepare is to have actually fixed one. KodeKloud Engineer hands you exactly this kind of real Linux ticket on a live system, so you can walk in having already solved the thing they are asking about.

Q26. A server reports "disk full" but df -h shows free space. What is going on?

Two usual suspects, and a good candidate names both. First, inodes are exhausted even though blocks are free, which happens with millions of tiny files. You check the other dimension:

$ df -i /
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
overlay        30574800 616702 29958098    3% /

If IUse% is at 100, you are out of inodes, not space, and the fix is deleting or consolidating small files. Second suspect: a deleted file still held open by a process (straight from Q20), where the space will not return until that process is restarted. You find those with lsof | grep deleted. Naming both causes, and knowing df -i exists, is the senior answer here.

Q27. A service will not start after a config change. Walk me through debugging it.

Check status first, then the logs, then the config. The status line usually tells you most of it:

$ systemctl status badapp.service
x badapp.service - App with a bad config path
     Active: failed (Result: exit-code) since Wed 2026-06-17 06:44:06 UTC; 10ms ago
    Process: 74 ExecStart=/usr/local/bin/myapp --config /etc/myapp/missing.conf (code=exited, status=203/EXEC)

That status=203/EXEC is a specific, useful clue: systemd could not execute the binary (wrong path, or not executable). Then go to the journal for the why:

$ journalctl -xeu badapp.service
... badapp.service: Main process exited, code=exited, status=203/EXEC
... badapp.service: Failed with result 'exit-code'.

From there: confirm the binary path and its execute bit, validate the new config (many daemons have a -t test mode, like nginx -t), check file permissions on the config, and run journalctl for the actual application error. The method, status then journal then config, is what they want to hear, not a lucky guess.

Q28. You SSH into a box and it is painfully slow. How do you diagnose it?

Narrate a triage order, because that is the whole point of the question. Start with uptime to read the load average and decide if the box is overloaded at all. Then split the problem: top or htop to see if a process is pinning CPU; free -h to check whether memory is exhausted and the box is swapping; and because high load with idle CPU points at I/O, check disk with iostat or look for processes in the D state. Glance at dmesg for hardware errors or OOM kills. If even logging in was slow, suspect DNS (a reverse-lookup timeout on the SSH server). The structure matters more than any single tool: is it CPU, memory, I/O, or network, and what is the evidence.

Q29. A cron job runs fine when you run it by hand but fails from cron. Why?

Almost always the environment. Cron runs with a minimal environment and a bare PATH (often just /usr/bin:/bin), not your login shell's rich one, so a command you call by its short name is not found, or a variable you rely on is unset. The fixes: use absolute paths to every binary, set the variables you need explicitly inside the script, and redirect output (>> /tmp/job.log 2>&1) so you can actually see the error, because cron emails output into a void on most boxes. This question is really testing whether you understand that "it works in my shell" and "it works in cron" are different environments.

Q30. You own a file but cannot write to it. Give me the possible reasons.

Run through the layers out loud. The file's own permissions may not include write for you. The directory may lack write and execute permission, which you need to modify entries in it. The file may carry the immutable attribute (chattr +i), which blocks writes even for root until you clear it with chattr -i; you check with lsattr. The filesystem may be mounted read-only, often because it flipped to read-only after detecting errors. Or the disk or inodes are full (back to Q26). A candidate who lists permissions, then the immutable bit, then a read-only mount is showing real field experience, because each of those has bitten people in production.

Q31. How do you find which process is listening on a given port?

ss is the modern tool (netstat is the older one you will still see):

$ ss -ltnp | grep 8080
LISTEN 0  5  0.0.0.0:8080  0.0.0.0:*  users:(("python3",pid=2701,fd=3))

The flags read as listening, TCP, numeric, with the process. lsof answers the same question from the file-descriptor side:

$ lsof -nP -i :8080
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
python3 2701 root    3u  IPv4  13574      0t0  TCP *:8080 (LISTEN)

Both give you the PID, which is what you actually wanted: the thing holding the port so you can decide whether to stop it or reconfigure it. Reaching for ss over netstat is a small signal that you have kept current.

Quick-Revision Cheat Sheet

The night before the interview, scan this instead of rereading the whole guide.

Conclusion

The pattern across every question here is the same: interviewers are not checking whether you memorized a command, they are checking whether you understand the system underneath it. A filename is a pointer to an inode, a signal is a message the kernel delivers, load average counts more than CPU. Get the model right and the commands follow.

In the last 48 hours before an interview, do not try to cram all 30 answers. Pick the five concepts you are shakiest on, run the commands yourself on a real box, and watch the output. If you do not have a spare machine, the Linux Basics course gives you a browser terminal to practice in. KodeKloud's free Linux crash course is a fast refresher for the fundamentals here:

The muscle memory of having actually typed df -i or read a failed systemctl status is what lets you answer calmly when it comes up, instead of reciting.

Ready to Walk In Sure of Yourself, Not Just Rehearsed?

Reading answers is one thing. Diagnosing a slow box, reading a failed service's journal, and explaining why a "full" disk has free space are different skills, and they only come from doing the work on a real system. The Linux Basics course on KodeKloud puts you in a live browser terminal with auto-validated tasks, so the commands in this guide become reflexes instead of flashcards. If you are aiming for a system administration role, the complete LFCS study guide maps out the path from here.

Create your free KodeKloud account ->

FAQs

Sources: Linux Permissions Explained; Read and Use System Documentation; Learn Shell Scripting; Advanced Bash Scripting; Boot or Change System Operating Modes; Complete LFCS Study Guide. All commands executed on Ubuntu 24.04 LTS (kernel 6.x, bash 5.2, systemd 255).