← Interview Prep
Live Coding — How to Approach
A meta guide to performing in a codepad / live-coding interview for a network-automation engineer role: talk through your process, pick the right structure, and dodge the language-specific traps that silently sink people.
In a live-coding round the interviewer is grading your process at least as much as
the finished code. A blank editor with no interpreter, no linter, and no autocomplete is a hostile
environment — and the way you narrate your thinking is what separates a hire from a pass. The single
most important habit to internalize:
Silence reads worse than imperfect code. If you are stuck, say out loud exactly
where you are stuck and propose a temporary fix (// TODO: linear for now, speed up below).
An interviewer can work with a narrated, half-optimal solution; they cannot grade a silent, frozen screen.
The think-aloud protocol
Rehearse these five moves until they are automatic — say them while you code, not after.
They are the phrases the interviewer is listening for.
- Clarify inputs / outputs & edge cases before coding. "Is the input always valid or
do I need to validate it? What do I do with duplicates? Does IPv6 need to work?" Pin down the contract
before you type a single line.
- State the plan and the complexity before writing. "I'll go in two passes: first parse
into a structure, then compute. That's O(n log n) because of the sort." Announce the shape of the
solution and its cost up front.
- Say the edge cases out loud. "Empty input, a single element, everything contiguous,
counter wrap-around." Naming them proves you thought about them even if you don't code every one.
- State tradeoffs explicitly. "I'm writing a linear scan for now — O(n). If there are
millions of routes, this wants a patricia trie and I can rewrite it." Make the interviewer see that you
know the cheap solution's limits.
- Name the tests you'd write. "I'd cover four cases: happy path, empty input, duplicates,
and bad input." Name them even if there's no time to actually write them — this is exactly what a
process-focused interviewer values.
How to answer
The winning strategy is boringly reliable:
- Simplest working solution first, then optimize aloud. Get something correct on the
screen, then narrate the improvement: "This works and is O(n²); now let me trade a hash set for the
inner loop to make it O(n)." A correct slow answer beats an ambitious broken one.
- Pick the data structure and justify it. Don't just reach for a dict or a slice — say
why: "I'll key by prefix in a hash map for O(1) lookup," or "I need stable order, so a list plus a seen-set,
not a set alone." The justification is half the point.
- Talk through complexity as you go. Every time you add a loop or a sort, state what it
costs. It keeps you honest and keeps the interviewer with you.
Python — common codepad mistakes
These are the "on dry paper, no interpreter" traps that bite when there's no linter to catch them:
- Off-by-one in
range: range(start, end) where you meant
range(start, end + 1) — classic on inclusive VLAN/port ranges.
- Lost last interval after the loop: you accumulate a run inside a
for and
forget to flush the final one after it ends.
- dict/set where stable order is needed: the test expects deterministic ordering, so
wrap it in
sorted() instead of trusting set/dict iteration.
- Mutating a collection during iteration — deleting from or appending to a list/dict
you're looping over.
- Bare
except: instead of catching the specific exception.
- Forgotten
return in one branch — the function silently returns
None.
- Mutable default argument:
def f(x=[]) shares one list across calls.
- str vs int comparison on parsed values — comparing a parsed
"10" against
an int, or sorting numbers lexically.
Go — common mistakes
- Random map iteration order: Go randomizes
map ranging, so a test
"sometimes" fails without a sort. This is the single most frequent failure on BFS or any
ordered output.
- Nil map write panics: writing to a
nil map panics — use make
or lazily initialize.
- err shadowing in
:=: re-declaring err inside a block hides
the outer one and drops the error.
- panic instead of returning an error — a library should return
error
values, not panic.
- Struct copy vs index when updating a slice element:
for _, v := range s { v.X = 1 } mutates a copy and does nothing; index with
s[i].X = 1.
- Integer division vs float: computing rates/bps with integer division truncates —
convert to
float64 first.
- Loop-variable capture in goroutines: pre-1.22 the closure captured the shared loop
variable — mention that Go 1.22 changed the semantics (per-iteration variable), which
earns points.
Go concurrency pitfalls (run with -race)
Half the point of the concurrency drills is getting the race detector to stay silent —
go test -race ./...:
- Shared map/var writes without a mutex from multiple goroutines → data race. Collect
results through a channel or guard with
sync.Mutex.
- Closing the output channel too early (before
wg.Wait()) → "send on closed
channel" panic or lost data. The sender always closes.
- Forgetting
close(jobs) → workers block forever on range jobs
and wg.Wait() never returns.
- Deadlock: waiting on an unbuffered channel in the same goroutine that's supposed to
send/receive on it.
- Missing
defer cancel(): a context created but never cancelled leaks the
goroutines waiting on ctx.Done().
WaitGroup.Add inside the goroutine instead of before launching it → race
against Wait.- Holding a mutex across a user fn / I/O serializes everything (in single-flight the fn
must run outside the mutex).
- Buffered vs unbuffered channel confusion: mixing them up gives you either a deadlock
or unexpected asynchrony.
Practice method
The training that actually transfers to a codepad:
- Write on dry paper (or a plain editor), timer on. No run, no autocomplete, no linter,
no internet — exactly the codepad conditions. Solve out loud, literally speaking.
- Only when the timer is up, run the tests. Copy into the project, run, and see what
didn't compile or which test failed and why.
- Keep a
mistakes.md. Log every miscompile and failing test. After about
three passes you'll see the same 3–4 recurring mistakes — those are precisely what to fix before the
interview.