Linux fundamentals
Bash Error Handling Coding Interview Problem
Written and reviewed by Sahil Srivastav
What this interview round tests
Bash error handling interviews show up in backend, SRE, DevOps, and platform screens because fragile scripts are still part of real deploy pipelines. The prompt often starts with "bash set -euo pipefail" or "shell script error handling," but the interview is really testing whether you understand how failures get masked and how paths get broken by word splitting.
This challenge gives you a real shell repository with a failing test suite. You need to harden a deploy script so failures stop the release flow, non-zero exits are visible to automation, and filenames with spaces stay intact under test.
The scenario
You are pulled into an on-call incident after a deploy script reported success while leaving the release in a partially updated state. One command failed, a later step still ran, and a path containing spaces was treated as multiple arguments.
The starter script captures the same class of production bug in a small Bash repo. The tests inject a failing command through PATH, exercise a space-containing fixture path, and check that the final state reflects a safely aborted or correctly completed deploy. Your job is to fix the script without changing the tests or fixtures.
What you’ll practice
- Reasoning about Bash exit behavior across ordinary commands, unset variables, and pipelines
- Understanding where set -euo pipefail helps and why masked failures are dangerous in deploy scripts
- Tracing a shell script from a failing step to the final side effect it must prevent
- Quoting parameter expansion and command substitution so paths with spaces remain one argument
- Preserving meaningful non-zero exit codes for CI, release automation, and incident triage
- Making shell changes that are deterministic, reviewable, and safe under a test harness
How to approach it
Start from the failing tests and reproduce the incident path: identify the command that should stop the deploy, then follow the script to see which later side effect proves the failure was ignored. Treat the test expectations as the contract for abort behavior, exit status, and artifact handling.
Then audit the script as a shell program, not just as a sequence of commands. Make failure handling explicit, check pipeline behavior deliberately, and inspect every expansion that touches a filename, argument list, or derived path. The goal is a deploy flow that fails loudly when an upstream step fails and still handles legitimate paths exactly as provided.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Is this a set -euo pipefail interview problem?
Yes. The challenge is centered on Bash failure behavior, including unset variables, pipeline exit status, and commands that should abort a deploy. It asks you to apply those ideas in a repository with executable tests rather than reciting shell options from memory.
What shell script error handling skills does it test?
It tests whether you can find masked failures, preserve non-zero exits for automation, avoid unsafe final side effects after an earlier error, and handle paths with spaces by treating values as arguments instead of accidental word-split fragments.
Does this page reveal the exact Bash fix?
No. The public page describes the incident shape and the skills involved. The starter repo gives you the failing contract, and the reviewed Gronex Pro solution stays behind the challenge flow.