Batch Script Interview Questions

Analogy categoryAnalogies

Interviewers testing batch scripting knowledge tend to focus less on syntax trivia and more on whether a candidate understands the language's sharp edges: delayed variable expansion inside loops, the difference between %VAR% and !VAR!, why ERRORLEVEL checks are fragile, and how scoping works with setlocal. These questions are popular in DevOps, sysadmin, and build-engineering interviews specifically because batch's quirks reveal whether a candidate has actually debugged real scripts or only skimmed documentation.

🏏

Cricket analogy: A bowling selector testing a fast bowler's yorkers under match pressure rather than in a relaxed net session reveals real skill, the way interviewers probe batch's edge cases rather than easy syntax questions.

Core Conceptual Questions

A frequent question is 'why does a variable set inside a FOR loop not update on each iteration when you echo it with %VAR%?' The answer is that %VAR% is expanded once, when the entire command (including the FOR block) is parsed, before the loop even runs — so every iteration echoes the same value captured at parse time. The fix, and the follow-up question interviewers ask, is 'setlocal enabledelayedexpansion' combined with '!VAR!' syntax, which defers expansion until the line actually executes, letting each iteration see the value set by the previous one.

🏏

Cricket analogy: A pre-recorded pitch report read out before every session, never updated as conditions change through the day, mirrors %VAR% capturing its value once at parse time regardless of what happens during the loop.

batch

@echo off
setlocal enabledelayedexpansion
set "total=0"
for %%n in (10 20 30) do (
    set /a total+=%%n
    echo Running total: !total!
)
echo Final total: !total!

rem Without enabledelayedexpansion, !total! would print literally
rem or %total% would always show 0 inside the loop.

Practical Scenario Questions

Interviewers also probe practical judgment: 'how would you make a script safely handle being run twice at once?' expects an answer involving a lock file created with 'mkdir' (which atomically fails if the directory exists, unlike creating a regular file), checked at the top of the script before proceeding. Another common scenario is 'the script works when you run it, but fails when Task Scheduler runs it' — the expected answer covers differences in working directory (Task Scheduler often starts in System32), missing environment variables that only exist in an interactive session, and the importance of using %~dp0-based absolute paths instead of relying on the current directory.

🏏

Cricket analogy: A ground using a single physically-locked gate to the pitch to guarantee only one groundskeeper preps it at a time mirrors using mkdir as an atomic lock to prevent two script instances running concurrently.

A classic interview follow-up: 'why mkdir instead of just checking if exist for a lock file?' Because mkdir's directory creation is atomic at the filesystem level — two processes racing to create the same directory will have exactly one succeed and one fail, whereas 'if not exist X (create X)' has a race window between the check and the creation.

Candidates often forget that Task Scheduler jobs, by default, run with 'Start in' left blank, meaning the working directory can be C:\Windows\System32 rather than the script's own folder. Any relative path reference in the script silently resolves against the wrong directory unless %~dp0 is used consistently.

%VAR% is expanded once at parse time, before a FOR loop runs, so it shows a stale value across iterations.
setlocal enabledelayedexpansion plus !VAR! syntax defers expansion until each line actually executes.
mkdir provides an atomic, race-free way to implement a lock file, unlike a check-then-create pattern.
Scheduled tasks often run with a different working directory than interactive sessions, breaking relative paths.
%~dp0 is the standard fix for path issues caused by an unpredictable working directory.
ERRORLEVEL should be captured into a variable immediately, since later commands can silently reset it.
Interviewers favor scenario-based questions because they reveal hands-on debugging experience, not just syntax recall.