Linux & Shell Scripting Interview Questions
Linux and shell scripting interviews tend to probe three layers simultaneously: conceptual understanding (can you explain what a process, inode, or exit code actually is), practical fluency (can you write a one-liner or short script under time pressure), and troubleshooting instinct (given a symptom, what would you check first). This guide compiles the questions that recur most often across sysadmin, DevOps, and SRE interviews, with concise, technically precise model answers you can adapt and expand on in your own words during a live interview — interviewers consistently favor candidates who explain their reasoning over those who recite memorized answers.
Cricket analogy: A batting trial doesn't just check if you can hit sixes — selectors watch your technique against the short ball, your temperament under pressure, and whether you can talk through your shot selection, not just recite a coaching manual.
Conceptual Fundamentals
Q: What happens between pressing Enter on a command and seeing output? A: The shell parses the command line (expanding variables, globs, and aliases), performs any redirection/pipeline setup, forks a child process, and the child execs the target binary, replacing its own image with the new program while inheriting the shell's environment and file descriptors; the shell then waits for the child to exit and captures its exit status. Q: What is the difference between a hard link and a symbolic link? A: A hard link is a second directory entry pointing to the same inode — both names are equally 'real' and the data persists until the last hard link is removed; a symbolic link is a separate file containing a path string, which breaks if the target moves and is visibly distinguishable via ls -l's leading 'l' and arrow notation. Q: What is the difference between a process and a thread? A: A process has its own isolated memory address space, file descriptor table, and PID; threads within the same process share that memory space and most resources but have independent execution stacks and are scheduled independently by the kernel.
Cricket analogy: The shell forking then execing a command is like an umpire signaling for a review — the third umpire (child process) takes over the decision, replacing the on-field call, while the on-field umpire (shell) waits for the verdict; a hard link is two scorecards recording the same innings total, while a symlink is a note pointing to "see the other scorebook," useless if that book is discarded.
Shell Scripting Questions
Q: Why should you always quote variable expansions like "$var" instead of $var? A: Unquoted expansion undergoes word splitting on IFS characters and glob expansion, so a variable containing spaces or shell metacharacters can be split into multiple arguments or unexpectedly match filenames — quoting preserves the variable as a single literal argument. Q: What is the difference between $@ and $*? A: Unquoted, they behave identically; quoted, "$@" expands to each positional parameter as a separate quoted word (preserving arguments containing spaces), while "$*" expands to a single word joining all parameters with the first character of IFS. Q: What's the difference between [ and [[ in Bash? A: [ is the POSIX test command (also available as /usr/bin/test), subject to word splitting and glob expansion on unquoted variables, requiring careful quoting; [[ is a Bash keyword with more forgiving parsing, supports pattern matching and regex (=~), and short-circuit logical operators (&&, ||) without needing -a/-o.
Cricket analogy: Quoting "$var" is like keeping a team's playing XI as one sealed list instead of letting names spill onto the wrong sheet; "$@" treats each player as a separate name while "$*" mashes them into one blurred entry; [ is the old strict umpiring manual, while [[ is the modern DRS system parsing intent more forgivingly.
# Common live-coding prompt: write a script that backs up a directory
# with a timestamped filename and exits non-zero on failure
#!/usr/bin/env bash
set -euo pipefail
SRC_DIR="${1:?Usage: $0 <source-dir> <backup-dir>}"
BACKUP_DIR="${2:?Usage: $0 <source-dir> <backup-dir>}"
TIMESTAMP="$(date +%Y%m%d-%H%M%S)"
ARCHIVE="${BACKUP_DIR}/backup-${TIMESTAMP}.tar.gz"
if [[ ! -d "$SRC_DIR" ]]; then
echo "Error: source directory '$SRC_DIR' does not exist" >&2
exit 1
fi
mkdir -p "$BACKUP_DIR"
tar -czf "$ARCHIVE" -C "$(dirname "$SRC_DIR")" "$(basename "$SRC_DIR")"
echo "Backup created: $ARCHIVE"
# Common one-liner prompt: find and delete files older than 7 days
find /tmp/app-cache -type f -mtime +7 -delete
# Common prompt: count unique IP addresses in an access log
awk '{print $1}' access.log | sort | uniq -c | sort -rn | headA frequent trick question: 'What does set -e NOT catch?' The answer separates strong candidates from weak ones — set -e does not trigger on a failing command that is part of a condition (if, while, until), part of a && or || list (except the last element), or inside a pipeline unless set -o pipefail is also enabled, since only the pipeline's last command's exit status is checked by default.
Troubleshooting Scenario Questions
Q: A cron job works when you run it manually but fails when run by cron — why? A: Cron executes jobs with a minimal environment and a much shorter PATH than an interactive login shell, so commands relying on PATH entries set in .bashrc, or on environment variables exported there, are not available; the fix is to use absolute paths in the script or explicitly source/export needed variables and set PATH at the top of the script or in the crontab. Q: A server's load average is high but CPU usage looks low — what would you check? A: High load with low CPU usage typically points to processes in uninterruptible sleep (D state) waiting on I/O, so I'd check ps aux for D-state processes, iostat or vmstat for disk I/O saturation, and dmesg for storage errors. Q: df shows a filesystem is full but du doesn't find large files — what's happening? A: Almost certainly a deleted file still held open by a running process; check with lsof +L1 or lsof | grep deleted and restart or signal that process to release the space.
Cricket analogy: A player who trains fine at home but struggles under floodlights is like a cron job missing its usual environment; a scoreboard showing high "overs pending" but no bowler actually working suggests players stuck waiting on slow ground staff rather than genuinely bowling; a stadium reported "full" despite empty seats usually means blocked sections still held by an old event not yet cleared.
Interviewers often probe whether you actually understand exit codes versus just reciting $?. Be ready to explain that exit codes are integers 0-255, that 0 means success and any nonzero means failure by convention (not enforced by the kernel), that 127 typically means 'command not found', 126 means 'found but not executable', and that codes above 128 often indicate the process was terminated by a signal (128 + signal number, e.g. 137 = 128 + 9 = SIGKILL).
- Be ready to explain fork/exec, hard vs symbolic links, and process vs thread from first principles, not just definitions.
- Quoting variables ("$var") and knowing $@ vs $* are among the most commonly tested shell scripting fundamentals.
- Understand exactly what set -e does and does not catch — pipelines, conditionals, and && / || chains are common blind spots.
- Practice the classic troubleshooting scenarios: cron jobs failing due to minimal PATH/environment, high load with low CPU (I/O wait), and df/du mismatches from deleted-but-open files.
- Exit code conventions (0 = success, 127 = not found, 126 = not executable, 128+signal = killed by signal) come up frequently.
- Interviewers reward reasoning process over memorized answers — narrate your diagnostic steps, not just the final conclusion.
Practice what you learned
1. Why does a cron job that works fine when run manually often fail when triggered by cron?
2. What does an exit code of 137 typically indicate?
3. Quoted, what is the key difference between "$@" and "$*"?
4. Which scenario does `set -e` fail to catch by default, without also enabling `set -o pipefail`?
5. A server shows high load average but low CPU utilization. What is the most likely cause to investigate first?
Was this page helpful?
You May Also Like
Exit Codes and Error Handling
Understand how every command reports success or failure through its exit status, and how to build scripts that detect and respond to errors reliably.
Common Shell Scripting Pitfalls
A field guide to the mistakes that silently break Bash scripts — unquoted variables, wrong test operators, subshell scoping, and error-handling gaps.
Monitoring Processes with ps and top
Learn to inspect running processes with ps snapshots and the interactive top monitor, reading CPU, memory, and state columns to diagnose system load.
Scheduling Tasks with cron
Learn crontab syntax for scheduling recurring jobs, the difference between user and system crontabs, and common pitfalls like PATH and logging.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics