30 Unix Interview Questions and Answers for Debugging Scenarios

30 Unix interview questions with short model answers, realistic debugging scenarios, and the decision rules interviewers actually want to hear.

You know Unix. You've used it. You can explain what a process is, what a pipe does, what chmod means. Then the interviewer says, "A service can't read its config file — walk me through what you'd check," and the commands that felt solid thirty seconds ago suddenly scatter. Unix interview questions have a way of doing that: the moment they stop being definitions and start being scenarios, the mental model that looked complete turns out to have gaps.

The gap isn't knowledge. It's practice answering in the right order. Interviewers testing Unix aren't checking whether you've memorized the man page for `chmod` — they're watching whether you can move through a broken system with a clear sequence of checks, make a decision at each step, and explain why. That's a different skill from knowing what the commands do, and most flat Q&A study sheets don't train it.

This guide is built around that distinction. Each section covers a real topic area — shell and kernel, files and links, pipes and redirection, permissions, processes — and frames it as the debugging scenario the interviewer is actually running. The goal is a 30-second answer that sounds like a diagnosis, not a definition.

Why Unix Interview Questions Turn Into Debugging Questions

Why a definition-only answer falls flat

Interviewers at companies hiring junior engineers and DevOps candidates aren't trying to catch you in a trivia gap. They're trying to find out whether you can operate in a broken environment. A system where a file is missing, a service won't start, a process is spinning — that's the real test environment, and the question is whether you'd know where to look first.

When a candidate answers "what is a hard link?" with a clean textbook definition and stops there, the interviewer doesn't know if that candidate has ever actually needed to distinguish a hard link from a symlink in a real situation. The follow-up — "okay, so when would you use one over the other?" — is where the definition-only preparation runs out. The USENIX Association has documented this pattern in technical interview research: command-line and systems questions are most reliably answered by candidates who can connect a concept to a scenario, not just define it.

The shape of a good 30-second answer

The answer pattern that lands well has three moves. First, state the concept in one sentence — just enough to show you know what it is. Second, name the command or signal you'd reach for first and why. Third, tie it to a concrete result: what would change, what you'd check next if the result was unexpected.

"A zombie process is a process that's finished but hasn't been reaped by its parent. I'd use `ps aux` and look for processes in Z state. If I see a bunch of them, the real problem is the parent — it's not calling `wait()`, so I'd check whether the parent itself is stuck or whether it needs a signal."

That's thirty seconds. It shows concept, command, and reasoning. The interviewer can follow up anywhere in that chain, and you've given them something to grab.

What people miss when they study from flat Q&A pages

The structural gap is this: memorizing what a command does doesn't tell you when to use it instead of something else. A candidate who's studied `chmod` can tell you it changes file permissions. But the interview question is usually "a service can't read its config — what do you check?" That question has a sequence, and `chmod` might not even be the answer. The owner might be wrong. The service user might not be in the right group. The file might have the right permissions but be in the wrong path entirely.

In prep calls with junior engineers and DevOps candidates, the unix interview questions that trip people up most are almost never the ones about what a command does — they're the ones about which command you'd reach for first, and what you'd do if it didn't solve the problem. The decision rule is what's missing from most study materials.

Shell, Kernel, and Unix Architecture Without the Hand-Waving

What is the shell actually doing here?

Unix interview prep often starts here, and the right answer isn't long. The shell is the command interpreter sitting between you and the kernel. When you type `ls -la`, the shell parses that, finds the `ls` binary, forks a child process to run it, and hands the output back to your terminal. That's the whole job: interpret, launch, and manage the I/O.

The follow-up is usually a simple pipe example — "what happens when you run `ls | grep config`?" — and the answer is that the shell creates two processes, connects the stdout of `ls` to the stdin of `grep` via a pipe, and runs them. The kernel manages the actual data movement between them. Knowing that split — shell orchestrates, kernel executes — is what the interviewer is listening for.

How do you explain the kernel in one breath?

The kernel manages hardware, processes, memory, and the filesystem. Every system call your code makes — opening a file, allocating memory, sending a network packet — goes through the kernel. In an interview, anchor this to a scenario: "If a command runs but the system is sluggish, I'd check whether the process is spending time in kernel space — that usually means I/O or a resource contention problem, not a bug in the application logic itself."

Think of it as the shell being the front-of-house manager and the kernel being the infrastructure it's running on. Shell commands become kernel actions the moment they touch hardware, files, or other processes. That analogy holds up in real admin work: when a script runs fine locally but hangs on a remote server, the first question is usually whether the kernel-level resource — disk, memory, open file descriptors — is the bottleneck.

What does 'single-user system' really mean in interview land?

It's a historical concept that comes up occasionally to test whether you understand Unix's design philosophy. The short answer: Unix was originally designed around a single kernel managing multiple users and processes, as opposed to early operating systems that were single-user, single-task. The interviewer's real point is usually whether you understand that Unix is a multitasking, multi-process system — and that even in a "single-user mode" (runlevel 1), the kernel is still there, still managing processes. It's not that the system becomes simpler; it's that network services and non-essential daemons are stopped to allow safe maintenance.

File Commands and Links That Expose Whether You Can Read the Filesystem

What would you check first if a file is missing?

This is one of the most common Unix commands interview questions in junior interviews, and the answer is a sequence, not a command. Start with `pwd` to confirm you're in the right directory. Then `ls -la` to see what's actually there, including hidden files. If the file still doesn't appear, `find / -name filename` to search the broader filesystem. If `find` returns it somewhere unexpected, check whether a path variable or symlink is pointing to the wrong location. If `find` returns nothing, check whether the process that should have created the file ran successfully — that's now a process or log question, not a file question.

The interviewer is watching whether you move through that sequence methodically or jump straight to a command that assumes you already know what's wrong.

Hard links vs symbolic links: what changes, and when do you care?

A hard link is a second directory entry pointing to the same inode — the same actual data on disk. A symbolic link is a separate file that contains a path to the target. The practical consequence: hard links survive if the original filename is deleted, because the data still has a reference count greater than zero. Symbolic links break if the target is moved or deleted, because they're pointing at a path, not an inode.

The deployment scenario that makes this concrete: if you have a config file that other services reference and you want to ensure those references survive a rename or move during a deploy, a hard link is safer. If you want a shortcut that always reflects the current location of a versioned binary — `/usr/local/bin/python` pointing to `python3.11` — a symlink is the right tool. The follow-up question is almost always about inode behavior: "what does `ls -i` show you about each?" Both a hard link and its original will show the same inode number. A symlink will show a different one. According to the GNU Coreutils documentation, this distinction is fundamental to how Unix filesystems track data versus names.

Which file commands should you know cold?

`ls`, `cd`, `pwd`, `find`, `cat`, `less`, `cp`, `mv`, `rm`, `mkdir`, `touch`. These are the commands you'd use while tracing a broken config or a missing artifact, and an interviewer expects you to reach for them without hesitation. `less` over `cat` when the file is long — so you don't flood the terminal. `find` with `-name`, `-type`, and `-mtime` flags when you need to narrow the search. `touch` when you need to create a placeholder or update a timestamp. Know what each one does, and know the one flag per command that changes its behavior most meaningfully.

Pipes, Redirection, and Filters in the Order Interviewers Expect

How do pipes, redirection, and filters work together?

Shell and process questions about pipes are almost always about the data flow. A pipe (`|`) connects the stdout of one command to the stdin of the next. Redirection (`>`, `>>`, `<`) connects a command's stdin or stdout to a file. Filters — `grep`, `awk`, `sed`, `cut`, `sort`, `uniq` — transform the data as it moves through.

The command chain that makes this concrete: `ps aux | grep nginx | awk '{print $2}' > nginx_pids.txt`. You're getting all processes, filtering for nginx, extracting the PID column, and writing those PIDs to a file. Each tool is doing exactly one job. The pipe is the connector. The redirect is the output destination. That's the mental model the interviewer wants to hear.

Why does grep usually come before awk or sed in your answer?

Decision rule: `grep` for matching lines, `awk` for column-based work or arithmetic on fields, `sed` for in-stream substitution or line editing. You filter with `grep` first because reducing the data set before you process it is faster and easier to reason about. In a log-sifting scenario — "find all 500 errors in the last hour's logs and extract the request path" — you'd run `grep "500" access.log | awk '{print $7}'`. If you ran `awk` first, you'd be processing every line before filtering. The GNU Bash manual covers the file descriptor model that makes this pipeline behavior predictable.

What breaks when redirection is used the wrong way?

The classic gotcha is stdout versus stderr. By default, `>` only redirects stdout. If the command fails and the error goes to stderr, your output file is empty and you have no idea what went wrong. The fix is `2>&1` to merge stderr into stdout, or `2>error.log` to capture them separately.

Real scenario: you're capturing the output of a failing build command — `make build > build.log` — and the log file is empty. The error was going to stderr the whole time. The correct command was `make build > build.log 2>&1`. This comes up in DevOps interviews specifically because it's exactly the kind of thing that burns a junior engineer on their first CI pipeline.

Here's what a correct pipeline looks like in practice:

That captures matching lines, extracts the timestamp and last field, writes to a file, and ensures any errors from the pipeline itself are also captured.

Permissions Questions Are Really About Ownership, Not Just chmod

What do chmod, chown, and chgrp each change?

Unix interview questions about permissions almost always start here, and the answer needs to be sharp. `chmod` changes the permission bits — read, write, execute — for owner, group, and others. `chown` changes who owns the file. `chgrp` changes which group owns it. They're three different axes of the same access control system, and the mistake candidates make is treating `chmod` as the universal fix.

In a deployment scenario: you've pushed a new config file and the service can't read it. Before you run `chmod 644`, check who owns the file and what user the service runs as. If the file is owned by `root` and the service runs as `appuser`, the mode bits don't matter — the service isn't the owner, and if the group doesn't include `appuser`, it's hitting the "others" permissions.

How do owner, group, and others show up in a real answer?

The permission string `-rw-r--r--` tells you three things in sequence: the owner can read and write, the group can read, and others can read. When you're debugging access, you read that string as a diagnosis. A process that can read but not write a file — when you expected it to write — usually means the process user is hitting the group or others column, not the owner column.

The scenario that makes this click: a web server process running as `www-data` can read a config file but can't write a log file in the same directory. `ls -la` shows the log file is owned by `root` with mode `644`. The fix isn't `chmod 777` — it's `chown www-data:www-data logfile` or adding `www-data` to the owning group.

What would you do if a service can't read its config?

Check in this order: `ls -la /path/to/config` to see the mode and owner. Check what user the service runs as — usually in the service unit file or with `ps aux | grep servicename`. Compare the service user against the file's owner and group. If the service user isn't the owner and isn't in the owning group, it's hitting "others" permissions. Decide whether to `chown`, `chgrp`, or adjust the mode — in that priority order, because changing ownership is usually safer than opening permissions to others.

The firsthand lesson from real admin work: the first instinct is always `chmod 755` or `chmod 644`. The actual fix, more often than not, is `chown` — because the file was created by a deploy script running as a different user than the service expects. The Linux man page for chmod documents mode bits clearly, but the ownership check comes first in practice.

Processes, fork(), ps, top, kill(), and Zombie Questions in One Story

How do you explain fork() without sounding academic?

Unix interview prep on processes usually starts with fork(), and the answer that lands is behavioral, not theoretical. `fork()` is the system call a process makes to copy itself — the original becomes the parent, the copy becomes the child. The child gets its own memory space (copy-on-write in modern kernels), its own PID, and inherits the parent's file descriptors.

The shell example makes it concrete: when you run a command in your terminal, the shell calls `fork()` to create a child process, then `exec()` to replace the child's image with the command binary. That's why your terminal doesn't disappear when you run `ls` — the shell is the parent, `ls` is the child, and the shell waits for the child to finish before giving you the prompt back.

What is a zombie process, and why does it show up in interviews?

A zombie process is a child that has finished executing but whose exit status hasn't been collected by its parent yet. The process is dead — it's not consuming CPU — but it still has an entry in the process table. The parent is supposed to call `wait()` to reap it. If the parent never does, the zombie stays.

In a long-running service scenario: a backend server forks child workers to handle requests. If the parent process has a bug and never calls `wait()`, every finished child becomes a zombie. Over time, the process table fills up and the system can't create new processes. `ps aux` would show these as processes in `Z` (zombie) state with `[defunct]` in the command column. The fix is in the parent — either fix the `wait()` call or send the parent a `SIGCHLD` signal to trigger cleanup.

ps vs top vs kill(): how do you choose?

`ps aux` for a snapshot — you want to see all processes, their PIDs, CPU and memory usage, and their state at a single moment. `top` for live activity — you're watching which processes are consuming the most CPU right now, and you want to see the numbers change. `kill` for sending signals — `kill -9 PID` for a forced termination, `kill -15 PID` for a graceful shutdown request.

The scenario that makes the choice obvious: a backend service is pegging CPU at 100% and responses have slowed to a crawl. You run `top`, sort by CPU, and identify the PID. You run `ps aux | grep PID` to get more context — what user is running it, how long it's been up, what its parent is. Then you decide: `kill -15` first to give it a chance to clean up, `kill -9` only if it doesn't respond. The process tree — visible with `ps auxf` — tells you whether killing the parent will orphan children or whether there's a supervisor process that will restart it.

The Unix Command Choices That Separate Memorized Answers From Working Ones

head or tail — which one are you reaching for first?

This is a decision question. `head` when you care about the beginning of a file — schema headers, config preambles, the first few lines of a CSV. `tail` when you care about the end or want to watch live updates — `tail -f /var/log/app.log` is the standard move when you're watching a service start up or debugging a live error stream. The Unix commands interview questions around these two are usually about log analysis, and `tail -f` combined with `grep` is the answer pattern that shows you've actually done it.

What do grep, awk, sed, cut, and xargs each do best?

• `grep`: match lines by pattern. First tool in any pipeline that starts with "find all lines where…"
• `awk`: column-based processing and arithmetic. Use it when you need field 3 of a space-delimited log, or when you need to sum a column.
• `sed`: in-stream substitution and line editing. Use it for find-and-replace in a file or stream — `sed 's/old/new/g'` is the pattern you'll use most.
• `cut`: extract fixed-position fields from delimited data. Faster than `awk` for simple column extraction when the delimiter is consistent.
• `xargs`: take stdin and pass it as arguments to another command. The canonical use: `find . -name "*.log" | xargs grep "ERROR"` — because `grep` doesn't read from stdin the way a filter does.

In a real log-processing workflow, you'd use `grep` to filter, `awk` or `cut` to extract the fields you care about, `sort | uniq -c` to count occurrences, and `xargs` when you need to feed results into a command that doesn't accept stdin directly.

Which Unix commands should a junior or DevOps candidate know cold?

`ls`, `cd`, `pwd`, `find`, `grep`, `cat`, `less`, `ps`, `top`, `chmod`, `chown`, `chgrp`, `kill`, `df`, `du`, `env`, `export`. That's the day-one debugging toolkit. `df` and `du` for disk space — `df -h` for filesystem-level usage, `du -sh *` for directory-level. `env` and `export` for environment variables — critical for debugging why a service can't find a binary or a config path. In prep polls with junior candidates, the commands most commonly missed are `du`, `xargs`, and `env` — candidates overprepare on `chmod` and underprepare on the tools that help them understand the environment a process is running in.

The Unix Debugging Scenarios Interviewers Actually Use

A file exists on disk, so why can't the app see it?

This is the Unix debugging scenario that shows up most often, and the model answer path is: check the path first — `pwd` and confirm the working directory. Run `ls -la` to verify the file is there and readable. Check who owns it and what mode it has. Check what user the application runs as — `ps aux | grep appname`. If the user doesn't match the owner and isn't in the owning group, that's your answer. If the permissions look fine, check whether the application is using an environment variable or config value to construct the path — `env | grep CONFIG_PATH` — and verify that variable is set to what you think it is. If everything looks right but the app still can't see it, check whether a symlink in the path is broken with `ls -la` on each directory component.

The follow-up is almost always: "what if the file is there and the permissions are correct?" That's the signal to check whether the process is running in a container or chroot with a different filesystem view — a scenario that's increasingly common in DevOps interviews.

The logs are there, but the command output looks empty

This is a stderr versus stdout question in disguise. If you run `grep "ERROR" app.log > errors.txt` and the file is empty, either there are no matches or the command itself errored and sent its output to stderr. Run the command without the redirect first to see what the terminal shows. If you see output in the terminal but not in the file, you've confirmed it's going to stdout and the redirect is working — which means the file was written and then something else emptied it. If the terminal shows nothing, check whether you're looking at the right log file, whether the pattern is correct, and whether the log rotation has moved the active log to a different path.

The deeper follow-up: "what if the grep output goes to a file but the file is always zero bytes?" That's the signal to check whether a separate process is truncating the file — `lsof | grep errors.txt` will show you every process with that file open.

The process is running, but the service is dead slow

Start with `top` to see whether the process is CPU-bound or I/O-bound. If CPU is high, check whether it's user-space CPU (`us`) or kernel-space (`sy`) — high kernel CPU usually means I/O contention. Run `ps aux` to get the process details and check how long it's been running and whether it's spawned unexpected children. Check open file descriptors with `lsof -p PID` — a process that's opened thousands of files and isn't closing them will slow down as the kernel manages the descriptor table. Check disk with `df -h` to rule out a full filesystem, and `du -sh /var/log/*` if log files are the suspect.

In a real backend debugging session, the sequence looks like this:

The strong candidate narrates this sequence and says what result at each step would change the next move. That's the answer that separates someone who's debugged a real system from someone who memorized the commands.

How Verve AI Can Help You Prepare for Your Software Engineer Job Interview

The structural problem this whole guide is built around — knowing the commands but freezing when the question becomes a scenario — doesn't get fixed by reading more definitions. It gets fixed by practicing the answer out loud, under something that approximates real pressure, and getting feedback on whether your reasoning sequence was clear.

That's the job Verve AI Interview Copilot is built for. It listens in real-time to your answer as you give it — not a canned prompt, but what you actually said — and responds to the specific gaps in your reasoning. If you said `chmod` when the scenario called for `chown`, Verve AI Interview Copilot catches that. If your debugging sequence skipped the ownership check and jumped straight to mode bits, it flags the gap. The feedback is specific to what you said, not generic encouragement. For Unix interview prep specifically, that means you can run the file-missing scenario, the zombie process scenario, and the permissions scenario back to back, get real-time coaching on your answer structure, and walk into the interview having actually practiced the decision sequence — not just reviewed it. Verve AI Interview Copilot stays invisible during live sessions, so it works as both a practice partner and a real-time support layer when you need it most.

---

Unix interview questions get easier the moment you stop treating them as a vocabulary test. The interviewers asking about zombie processes and broken permissions aren't checking whether you've read the man page — they're watching whether you can move through a broken system with a clear head and a logical sequence of checks. That's a skill you build by practicing scenarios, not by memorizing definitions.

Before your next interview, pick two or three of the scenarios in this guide — the missing file, the slow service, the zombie process — and practice your answer out loud. Say what you'd check first, what result would change your next step, and what command you'd reach for if the first one didn't solve it. That's the answer pattern that lands. The commands are just the vocabulary. The sequence is the argument.