Linux interview prepShell and awk30-minute review

Linux Shell Scripting Interview Preparation

Written and reviewed by Sahil Srivastav

Shell interviews reward precise reasoning about text, files, processes, and failure. This guide connects four practice areas: parsing logs by field, choosing safe ownership and mode defaults, aggregating simple CSV data with awk, and hardening Bash scripts without treating strict mode as magic.

Clarify the contract before typing

Ask what can appear in the input, whether malformed rows should be skipped or rejected, whether stdout must match exactly, how ties are ordered, what privileges the script has, and which failures must stop later side effects. Those answers determine the command shape more than command memorization does.

What Linux shell interviews test

Exact prompts vary, but these four exercises expose the same underlying habits: read the data contract, choose the narrowest safe tool, make output deterministic, and prove both success and failure behavior. Each section links to a concept guide and its repository-based practice problem.

Practice area 01

Log parsing: extract fields before counting

A strong solution starts from the log format and the required report. It extracts the client, request, and status fields deliberately, then keeps filtering, aggregation, and presentation as separate steps. That makes it easier to explain why a match is valid and why repeated runs produce the same order.

  • Compare the status-code field instead of searching the entire line for 500.
  • Use numeric sorting for counts and define a stable tie-break for equal values.
  • Decide what empty input and malformed rows should produce before writing the pipeline.
Small fixture: isolate status-field matching
# sample.log
10.0.0.8 GET /health 200
10.0.0.4 GET /api 503
10.0.0.8 POST /jobs 202

$ awk '$4 ~ /^5[0-9][0-9]$/ { errors++ }
> END { print "5xx", errors + 0 }' sample.log
5xx 1

This checks one field-level rule. It intentionally does not implement the client ranking required by the linked challenge.

Practice area 02

chmod, chown, and umask: state the intended filesystem result

Permission questions test whether you can describe a path as an owner, a group, and a mode instead of reaching for a broad recursive command. chmod changes access bits, chown changes ownership, and umask removes permissions from the defaults used when new paths are created. Umask does not repair an existing file.

  • Translate the requirement into separate owner, group, and other permissions.
  • Remember that directories need execute permission for traversal, not just read permission.
  • Verify the final state with stat; do not assume a command succeeded merely because it was issued.
Disposable fixture: observe a restrictive creation mask
$ sandbox=$(mktemp -d)
$ (umask 077; : > "$sandbox/interview-secret")
$ stat -c '%a' "$sandbox/interview-secret"
600

The example creates only a new file in a fresh temporary directory. chown is not run because changing ownership is privilege-dependent; in an interview, explain the desired identity separately from the mode.

Practice area 03

awk CSV aggregation: separate parsing, grouping, and output

For a deliberately simple comma-delimited fixture, awk can skip a header, validate fields, and accumulate numeric values. A grouped answer normally uses an associative array keyed by the grouping column, then formats and sorts the result explicitly. State the boundary: splitting on commas is not a general CSV parser when quoted fields can contain commas or newlines.

  • Confirm the delimiter, header behavior, key column, numeric column, and output contract.
  • Do not rely on associative-array iteration order for the final report.
  • Keep aggregation independent from formatting so numeric sort keys remain numeric.
Small fixture: verify header handling and one numeric total
# sales.csv
region,amount
north,7
south,4
north,3

$ awk -F, 'NR == 1 { next } { total += $2 }
> END { print "all-regions", total }' OFS='\t' sales.csv
all-regions    14

This demonstrates header skipping and accumulation only. The grouping logic and challenge-specific ordering remain part of the linked problem.

Practice area 04

Bash hardening: make failure and argument boundaries explicit

Strict options are a useful baseline, not a complete error-handling design. A careful answer explains which failures must stop the script, which non-zero statuses are expected inside conditions, how pipeline status is handled, and why every path-like expansion is quoted. It also preserves a meaningful non-zero exit for the caller.

  • Use set -euo pipefail deliberately and understand that errexit has context-dependent behavior.
  • Quote scalar expansions and use arrays when one logical argument must stay one argument.
  • Test both the success path and an injected upstream failure before trusting the final side effect.
Small script: require an argument and preserve spaces
# check-path.sh
#!/usr/bin/env bash
set -euo pipefail
target=${1:?usage: check-path.sh PATH}
printf 'target=<%s>\n' "$target"

$ ./check-path.sh 'release candidate'
target=<release candidate>

This demonstrates argument validation and quoting only. It does not reveal the failure flow in the linked deployment challenge.

A compact 30-minute preparation plan

Use one tiny fixture per step. The goal is to refresh reasoning and explanation, not to memorize four long one-liners immediately before an interview.

  1. 0-4 minRead the contractWrite down the input format, exact stdout, required ordering, and one assumption you need to clarify.
  2. 4-10 minRehearse log parsingIdentify fields from a tiny log, count one condition, and say how you would sort counts with a tie-break.
  3. 10-16 minReview permissionsTranslate a secret and a directory into owner/group/mode intent; explain where chmod, chown, and umask apply.
  4. 16-23 minSketch awk aggregationMark the header, delimiter, group key, amount field, accumulation step, and deterministic output step.
  5. 23-30 minHarden and testAudit quoting and failure propagation, then name tests for empty input, ties, spaces in paths, and an upstream failure.

Self-evaluation rubric

Score each dimension from 0 to 2 after a timed attempt. This is a practice rubric, not an employer-specific scoring claim; use the first weak row to choose what to rehearse next.

Linux shell scripting interview self-evaluation rubric
Dimension0 - Missing1 - Partial2 - Ready
Contract readingStarts typing without fixing the input and output contract.Finds the main fields but leaves ordering or edge cases implicit.States format, assumptions, exact output, ordering, and edge behavior.
Parsing and aggregationMatches incidental text or relies on input order.Computes the happy path but has unstable output or weak validation.Extracts fields, aggregates numerically, and emits deterministic output.
Permission reasoningUses a blanket mode or confuses ownership with access bits.Chooses plausible modes but cannot explain creation defaults.Separates owner, group, mode, and umask, then verifies final state.
Bash reliabilityLeaves expansions unquoted or allows failures to be masked.Adds strict mode without testing its important contexts.Handles expected failures explicitly, quotes values, and preserves status.
Verification and explanationStops after one happy-path run.Tests a few cases but cannot defend command choices.Uses focused fixtures, tests failure paths, and explains tradeoffs clearly.

Common failure modes

These mistakes usually come from collapsing distinct concerns into one shortcut. Name the risk, then show the smaller verification step that removes it.

Matching the whole line instead of a field

A status-like number in a URL or message can be counted as an error.

Corrective move: Parse the documented format and compare the status field itself.

Producing unstable or lexical ordering

Associative-array order can vary, and text sorting puts 10 before 2.

Corrective move: Emit normalized sort keys, sort numerically, and specify a tie-break.

Treating comma splitting as a complete CSV parser

Quoted commas, escaped quotes, or embedded newlines change field boundaries.

Corrective move: Confirm the fixture is simple; otherwise choose a CSV-aware parser.

Using chmod -R or 777 as a shortcut

Files and directories receive the same bits, and sensitive paths become overexposed.

Corrective move: Set intent by path type, preserve least privilege, and audit with stat or find.

Expecting umask or chown to do chmod work

Existing modes stay unchanged, or ownership changes while unsafe access bits remain.

Corrective move: Treat creation defaults, identity, and access bits as separate controls.

Treating strict mode as automatic correctness

Expected non-zero statuses, pipelines, and unquoted values can still behave unexpectedly.

Corrective move: Use explicit conditions, inspect pipeline semantics, quote expansions, and test injected failures.

Turn the review into a timed attempt

Pick the lowest-scoring rubric row, open its matching problem, and state your assumptions before changing the starter script. Keep the first fixture small, make the output exact, and add one failure case before expanding the solution.