Unix Commands Interview Questions And Answers

What Actually Shows Up in Unix Command Interviews

Most people prep for these interviews by memorizing grep and awk syntax from some website. That gets you through the first five minutes. Then the interviewer asks something about process states and you realize you have no idea what a zombie process actually does on disk. I went through about twelve of these interviews between 2014 and 2018. Some were decent, most were just people reading off a screen trying to catch you in a trick question. The Unix Commands Interview Questions And Answers that actually matter aren't the ones you find on the first page of Google results. Interviewers don't care if you can remember every flag for tar. They want to know whether you understand how Unix works under the hood. Here is a realistic example that comes up constantly. Question: What happens when you run chmod 777 on a file?

Most candidates explain read, write, execute bits and move on. The real answer involves understanding that 777 makes the file world-writable and executable, but more importantly, it disables the sticky bit protections that might exist on parent directories. On shared systems this is a security landmine. I once saw a candidate get pushed harder on why they would never use 777 in production. They had no answer because they had only ever used it to fix permissions on a local dev machine quickly. Question: Explain the difference between a hard link and a soft link. This shows up in about every other interview. A hard link points directly to the inode. A soft link points to the filename. When you delete the original file, the hard link still works because the inode is still there. The soft link breaks immediately. Here is the part most people miss: you cannot create a hard link across filesystems, and you cannot create a hard link to a directory. That second restriction exists because it would let you create circular references in the directory tree, which would break tools like find and rm that traverse hierarchies expecting a DAG structure.

Pipes and Redirection Are Where People Fall Apart

Pipes and redirection come up constantly because they look simple but have surprising depth. Here is one that trips up even senior engineers. Question: What is the difference between 2>&1 and 1>&2? The order matters because redirection is evaluated left to right. In 2>&1, you redirect standard error to wherever standard output currently points. In 1>&2, you redirect standard output to wherever standard error currently points. If you write a script with 2>&1 and expect stderr to go to a log file while stdout stays on the terminal, it won't work the way you think. I spent two hours debugging a deployment script in 2016 that had exactly this problem. The CI server was capturing stdout normally but stderr was silently going into /dev/null because of a misordered redirection somewhere upstream in the pipe chain. The fix was rewriting the whole section with explicit file descriptors: exec 3>deploy.log so I could control where each stream actually went.

Question: How do you find all files modified in the last 24 hours? The straightforward answer is find /path -mtime -1. But here is what the interviewer is actually looking for: do you understand that -mtime uses 24-hour periods starting from 00:00 of the current day, not a rolling 24-hour window from right now? If you need a true rolling window, you should use find with -mmin and calculate minutes, or use touch with a reference file and -newer. I prefer the reference file approach because it is exact and doesn't depend on cron scheduling.

Process Management Questions Separate Juniors From Everyone Else

Question: How do you kill a process that ignores SIGTERM? Sigterm is graceful. The kernel delivers it and gives the process time to clean up. If the process is stuck in an uninterruptible sleep state, nothing will kill it, not even SIGKILL. That state happens when the process is waiting on I/O, usually disk or network. I ran into this on a production server where a Oracle database process was stuck waiting on a slow SAN array. The array had failed but the processes were still in D state. The only solution was to take down the storage array cleanly and reboot. SIGKILL on that process just sat there doing nothing for three days. This is the kind of thing you learn the hard way. Question: What is a zombie process and how do you clean it up?

A zombie is a process that has finished executing but still has an entry in the process table because its parent hasn't called wait() to read its exit status. You cannot kill a zombie with any signal. The only way to get rid of it is for the parent process to be reaped, which means either the parent calls wait() or the parent dies and init adopts the zombie. In practice, zombies are mostly a monitoring nuisance. They don't consume CPU or memory, just a process table slot. On systems with heavy process spawning like some Java applications, you can fill the process table and get cannot fork errors. I had to restart a worker service once because it had accumulated over four thousand zombies and the system was rejecting new process creation entirely.

Awk and Sed Will Come Up Even If You Say You Don't Use Them

Question: How would you extract the third column from a CSV file where the delimiter is a comma? The basic answer is awk -F, '{print $3}'. The better answer acknowledges that this breaks if the CSV has quoted fields containing commas. A proper solution uses a library like Miller or gawk with FPAT. In production, I switched to Miller years ago because parsing CSV with awk is just asking for subtle bugs. The interview question is testing whether you recognize the limitation. Question: Explain what this sed command does: sed -n '5,10p'

It prints lines five through ten from the input. Simple enough. But the follow-up is where it gets interesting. What if you wanted to do this on a ten-gigabyte log file and you only needed those lines? Reading the whole file is wasteful. You can use sed to quit early in some implementations, but the reliable approach is to use dd to seek past the first four lines or combine head and tail. I once ran a pipeline on a massive file without realizing sed was reading the entire thing before stopping. The job took forty minutes instead of twelve seconds.

Unix Commands Interview Questions And Answers That Actually Matter

Here is the practical truth: the most useful prep isn't memorizing answers. It's understanding the mental model. Unix is built on a few simple ideas. Everything is a file. Pipes connect programs. Standard streams are predictable. When you understand that framework, you can reason your way through questions you've never seen before. Common question: How do you check disk usage in human-readable format? du -h or df -h depending on whether you want per-directory breakdown or filesystem-level overview. The trap here is that du counts hard links multiple times and doesn't follow symlinks by default. If you need accurate space usage on a filesystem with lots of deduplicated data or network mounts, du will give you wrong numbers. Use lsblk or blockdev for actual block allocation, or just trust what the filesystem reports through df. The discrepancy between du and df is one of the oldest jokes in system administration for a reason.

Question: What is the difference between ps aux and ps -ef? Both show processes but with different formats and field ordering. ps aux is BSD-style and includes the PID, user, CPU%, memory%, VSZ, RSS, tty, stat, start time, elapsed time, and command. ps -ef is System V style and includes UID, PID, PPID, C, STIME, TTY, TIME, and CMD. The real answer the interviewer wants is whether you know that neither command shows kernel threads by default without specific flags, and that both can be misleading about resource usage because CPU% is calculated differently across implementations. On Linux, ps by default shows accumulated CPU time divided by elapsed time since process start, which flattens out for long-running processes. A process that spiked to 200% CPU for ten seconds and then sat idle will show nearly zero percent CPU in ps output. Question: How do you find which process is using a specific port?

ss -tlnp or netstat -tlnp to see listening sockets, then lsof -i :PORT or ss -tp to find the owning process. The caveat is that ss requires newer Linux kernels and may not be available on older systems, while netstat is deprecated but still everywhere. On macOS, lsof is more reliable than netstat for this task. I always carry a mental cheat sheet of the different commands across platforms because production environments are rarely uniform.

What I Wish Candidates Understood Better

Permission bits are not abstract. They map directly to system calls. When you understand that open() checks permissions against the effective UID and GID of the calling process, not the file owner, everything else clicks. Setuid executables work because the kernel temporarily elevates privileges to the file owner during open(). This is also why setuid scripts are ignored on Linux for security reasons. I see this question come up rarely but it separates people who understand the kernel from people who just memorized chmod commands. Signal handling is another area where surface knowledge fails you. Every process receives SIGPIPE when writing to a closed pipe. The default action is termination. This is why Python scripts that write to pipes sometimes crash unexpectedly. The workaround is trapping SIGPIPE and ignoring it, or better yet, checking write return values. I spent a Friday night debugging a data pipeline that died silently every few hours because one of the intermediate stages crashed and the next stage kept writing to a dead pipe until SIGPIPE killed it. No logs, no error messages, just sudden disappearance.

Practical Limitations of This Type of Prep

Reading interview questions won't make you good at Unix. It will help you pass interviews. There is a difference. The commands you use daily are a tiny fraction of what shows up in these conversations. Most senior engineers who ace these interviews have just read through a large question bank. The knowledge doesn't stick without practice. I recommend actually running through each command on a system, breaking things intentionally, and watching what happens. A virtual machine with a stripped-down Linux install costs nothing and teaches more than any number of Q&A sheets.