Bash Scripting Tips for DevOps - 5 Must-Know Tricks

A recruiter or hiring manager asks this because they've all been burned by a bash script that looked fine, ran clean in testing, and then quietly corrupted a deployment at 2AM. It's a quick way to separate someone who writes shell scripts from someone who writes production shell scripts.

The answer interviewers want

Start every script with set -euo pipefail. This one line does three things: it exits immediately on any command failure, it catches references to undefined variables instead of silently treating them as empty strings, and it makes a pipeline fail if any command in it fails, not just the last one. Without this, bash's default behavior is to keep running after errors, which is how silent failures turn into bad deployments.

Second, validate inputs immediately, before your main logic runs. Check that required files exist, that expected environment variables are actually set, and that any external commands your script depends on are available on the system. Fail fast and fail loud here, rather than letting a missing file blow up halfway through a deploy.

Third, and this is the one that tends to separate senior engineers from juniors in interviews: use trap to clean up on exit. A trap on EXIT (or on specific signals) ensures temp files and other resources get removed even if the script crashes partway through. Without a trap, a crashed script leaves garbage behind, and that garbage can cause the next run to fail in confusing ways.

Why interviewers ask this

This question is a proxy for operational maturity. Anyone can write a bash script that works in the happy path; the interviewer wants to know if you've internalized that scripts run in production, unattended, and at 3AM when nobody's watching. Mentioning set -euo pipefail, input validation, and trap unprompted signals you've actually been burned by the failure modes they prevent.

Follow-ups to expect

What's a situation where set -e alone isn't enough? It's why pipefail matters too: set -e only catches a failing command at the end of a pipeline by default, so a failure earlier in a pipe chain can slip through silently without pipefail added.

Why validate inputs instead of just letting the script fail naturally? Letting a script fail deep inside its logic, because a file or variable was missing, produces confusing errors and can leave the system in a half-changed state; validating upfront fails fast and gives a clear, actionable error.

What happens if you don't use trap for cleanup? A script that crashes without a trap leaves temp files or partial state behind, which can cause the next run to misbehave or make debugging the original failure harder.

The common wrong answer

Most candidates mention set -e alone and stop there, as if that one flag makes a script production-ready. They skip pipefail and nounset, never mention validating inputs before running main logic, and forget cleanup entirely, which is exactly the gap interviewers are listening for.