Linux interview questions: commands and troubleshooting

Linux interview questions fall into two groups. Freshers are asked to explain commands and concepts: file permissions, hard and soft links, processes and signals, systemd. Experienced engineers get troubleshooting scenarios: the disk is full but df disagrees with du, the load average is high but the CPU is idle, a service won't start, a process was killed for memory. The second group is where interviews are won, and the questions in it barely change from company to company.

This guide covers the commands and concepts first, with what a strong answer says, then works through seven troubleshooting scenarios with the exact commands and messages from the Linux man pages, then lists the old answers to stop giving (ifconfig, netstat, SysV init) and the Git questions that often come in the same round. For the rest of a DevOps interview, see DevOps interview questions.

What a Linux interview checks

Interviewers want to see that you can find out what's wrong on a machine you've never seen, using standard tools, in a sensible order. For a fresher, that means knowing what the basic commands do and why. For an experienced engineer, it means reading symptoms (an error string, a number from top) and knowing which layer they point to: disk, memory, CPU, a process, the network, or the init system. Say what you'd check, run it, and say what the output would tell you. That narration is most of the score.

Linux commands interview questions

File permissions, chmod and umask

Each file has read, write and execute bits for its owner, its group and everyone else, set with chmod (for example chmod +x script.sh) and ownership changed with chown and chgrp. Expect the follow-up on umask, the mask that removes permissions from newly created files, and on the special bits. The sticky bit on a shared directory such as /tmp (mode 1777) lets everyone create files, but only a file's owner, the directory's owner or root can delete it; a practice question on the sticky bit tests it. "Permission denied" when running a script usually means the execute bit is missing.

Hard links vs symbolic links

A hard link is another directory entry for the same inode, so the data survives until the last link is removed, but it can't cross filesystems: trying gives ln: Invalid cross-device link. A symbolic link (ln -s src dst) stores a path, can cross filesystems, and breaks if the target is removed. A practice question on hard vs symbolic links covers what happens when the target goes away.

Processes and signals

ps aux lists processes. kill -15 PID sends SIGTERM, which asks the process to shut down cleanly and can be caught or ignored; kill -9 PID sends SIGKILL, which the kernel enforces and the process can't catch. The right order is SIGTERM first, SIGKILL only if it doesn't exit, as a practice question on a process ignoring SIGTERM shows. Expect zombies too: a process in state Z has exited but its parent hasn't collected its status, so killing the zombie does nothing; the parent must reap it or exit. A practice question on reaping zombie processes covers that.

systemd and services

systemctl status <unit> shows a service's state and its recent log lines. After you edit a unit file, run systemctl daemon-reload before restarting, or systemd keeps using the old definition; a practice question on daemon-reload sets that trap. systemd replaced SysV init scripts with declarative unit files, and journalctl reads its structured logs.

Users, sudo and scheduled jobs

user is not in the sudoers file means the account lacks sudo rights; grant them by adding it to the right group or editing with visudo, which checks the syntax before saving. A related favourite is a cron job that works by hand but fails on schedule, because cron runs with a minimal environment and PATH; a practice question on cron's environment covers it.

Linux troubleshooting interview questions for experienced engineers

The disk is full, but df shows free space

Writes fail with No space left on device while df -h shows gigabytes free. Run df -i: if inodes are at 100%, the filesystem has run out of file entries, usually from millions of tiny cache or session files, and the fix is to delete them. A practice question on inode exhaustion is exactly this.

du and df disagree after deleting a large log

You deleted a huge log file, but df still shows the disk full. Deleting a file removes its directory entry, but the kernel keeps its blocks until every process that has it open closes it. lsof +L1 lists open files with no links left. Restart the process holding it, or truncate the file through /proc/<pid>/fd/<fd>, and the space comes back.

Load average is high, but CPU usage is low

uptime shows a load average well above the number of cores, but top shows the CPU mostly idle with high %wa. Linux's load average counts tasks that are runnable and tasks in uninterruptible sleep (state D), usually waiting on disk or network storage. So the cause is I/O: a hung NFS mount, a slow disk, failing hardware. Look for processes in state D; for a hung NFS mount, a lazy unmount (umount -l) is one way out. A practice question on load average and I/O wait tests this distinction.

A process was killed for memory

The process vanished, and dmesg -T | grep -i oom shows a line like Out of memory: Kill process <pid> (<name>). When the kernel can't find memory or swap, the OOM killer picks a task to terminate. Check memory with free -h. Fixes: find the leak, add swap, cap the process's memory with cgroups, or protect a critical service such as a database by lowering its /proc/<pid>/oom_score_adj.

A service won't start

systemctl start reports Job for <unit>.service failed because the control process exited with error code, and the status shows Active: failed (Result: exit-code). Read the logs with journalctl -xeu <unit>, which adds explanations to each entry. Check the unit file with systemd-analyze verify <unit-path>. The usual causes are a bad directive, wrong file permissions, a missing environment file, or another process already holding the port.

The service is up, but nobody can connect

Work up the stack. ip addr show and ip route show for the interface and default route; ss -tulpn for what's listening, and on which address and port; dig @server name +short for DNS; curl -Iv url for the HTTP layer; traceroute -n -T host for the path. Connection refused means nothing is listening on that port, No route to host points to routing or a firewall, and Address already in use means a second process is trying to bind the same port. A practice question on finding which process holds a port with ss covers that last case.

Bonus: logs disappear after a reboot

If journalctl -b -1 finds nothing from the previous boot, the journal is probably in volatile storage under /run/log/journal. Create /var/log/journal to make it persistent, cap its size with SystemMaxUse in /etc/systemd/journald.conf, and reclaim space with journalctl --vacuum-size=500M.

Old answers to stop giving

Many question lists still teach tools that modern distributions have replaced. In an interview, use the current ones:

• ip (from iproute2) instead of ifconfig, and ss instead of netstat. The net-tools package is deprecated; ss queries the kernel directly and is faster.
• systemd units and systemctl instead of SysV init scripts.
• journalctl for logs, alongside or instead of plain-text files such as /var/log/messages.
• cgroups v2, a single unified hierarchy under /sys/fs/cgroup, which also brings Pressure Stall Information for spotting resource pressure.

Questions on LILO, or comparisons with DOS, are a sign the list you're studying from is decades old. Skip them.

Git questions that come with Linux rounds

Git questions often appear in the same round, and searches for them are rising. Three to have ready: what git diff compares by default (the working tree against the index, so staged changes don't show), which a practice question on git diff and the index covers; how to recover commits after a git reset --hard (with git reflog), as in a practice question on recovering work with the reflog; and why git push --force-with-lease is safer than --force, with the one trap where it isn't, covered by a practice question on force-with-lease. The Git cert page and Git practice questions go further.

How to prepare

Practise on a real machine or VM rather than reading. Fill a small filesystem with tiny files until inodes run out. Delete a file a process still has open and watch df. Start a memory hog in a cgroup with a limit and read the OOM line in dmesg. Break a systemd unit and fix it from journalctl. Each scenario above takes minutes to reproduce, and having done it is what makes your answer convincing.

Then test yourself: the Linux cert page explains the bank, and the Linux practice questions cover permissions, processes, storage, systemd, networking and shell scripting, including a practice question on pipefail in shell pipelines. If you're preparing for a container-heavy role, the Docker interview questions and Kubernetes interview questions guides build on the same skills.

Frequently asked questions

What are the most common Linux interview questions?

File permissions and chmod, hard vs soft links, kill vs kill -9, what an inode is, how to check processes and resource use, and how systemd manages services. Experienced rounds add troubleshooting: a full disk, high load, an OOM kill, a failed service, a network fault.

What Linux troubleshooting questions are asked of experienced engineers?

"No space left on device" with free space (inodes), df and du disagreeing (deleted open files), high load with low CPU (I/O wait and state D), a process killed by the OOM killer, a service that won't start, and connections refused. You're judged on the commands you use and the order you check things.

What is the difference between kill and kill -9?

kill sends SIGTERM by default, which asks a process to exit and lets it clean up; the process can catch or ignore it. kill -9 sends SIGKILL, which the process can't catch, so it stops immediately without cleanup. Use SIGTERM first.

What is an inode?

An inode is the filesystem's record for a file: its permissions, owner, size and where its data blocks are, but not its name. Names are directory entries that point to inodes, which is why hard links work, and why a filesystem can run out of inodes while it still has free space.

How should a fresher prepare for a Linux interview?

Learn the core commands by using them daily: navigation, permissions, ps and kill, systemctl and journalctl, ip and ss. Be able to explain each in two sentences. Then reproduce one or two troubleshooting scenarios, such as a full disk, so you can describe how you'd diagnose it.

What is the difference between the shell and the kernel?

The kernel is the core of the operating system: it manages memory, processes, devices and filesystems, and programs reach it through system calls. The shell, such as bash, is an ordinary program that reads your commands and asks the kernel to run them. You can swap the shell; you can't run Linux without its kernel.