Go interview questions – practice quiz for developers

A map's zero value is nil, and a nil map has no backing storage allocated, so writing to it panics at runtime with "assignment to entry in nil map". Reading is asymmetric and safe — m["a"] on a nil map returns the value type's zero value (0 here) without panicking — which is exactly why the write panic surprises people. Go does not auto-allocate on first write; you must call make(map[string]int) (or use a literal) before assigning. The compiler can't catch this because nilness is a runtime property.

A deferred call's arguments are evaluated immediately, at the point the defer statement executes — only the call itself is postponed until the function returns. So defer fmt.Println(x) snapshots x as 1, and the later x = 2 has no effect on what is printed. To defer evaluation of the value until return time, wrap it in a closure: defer func() { fmt.Println(x) }(), which reads x when the closure runs. Misremembering this is a common source of bugs when deferring cleanup that logs a variable expected to be mutated later.

A buffered channel with capacity 2 accepts two sends without a receiver — they fill the buffer. The third send blocks because the buffer is full and there is no receiver to free a slot. Capacity is the number of values the channel can hold before a send must wait. An unbuffered channel (capacity 0) is the case where every send blocks until a receiver is ready (option b). Misjudging buffer capacity is a classic cause of deadlocks (fatal error: all goroutines are asleep - deadlock!) when a producer overruns a buffer no one is draining.

The %w verb wraps the original error, building a chain that errors.Is walks layer by layer, comparing each against the target — so errors.Is(err, os.ErrNotExist) correctly matches even though err is the wrapping error, not the sentinel itself. Direct == (b) fails because err is the new *fmt.wrapError, not os.ErrNotExist. String comparison (c) is brittle and breaks the moment a message changes. errors.As (d) is for extracting a concrete error type into a variable via a pointer, not for matching a sentinel value, and its second argument must be a pointer to a target — passing the sentinel directly won't compile. Using == on wrapped errors is the bug that makes "not found" handling silently stop working after someone adds context with %w.

Slices, maps, pointers, channels, functions, and interfaces are the reference-like types whose zero value is nil. So var s []int, var m map[string]int, and var p *int are all nil. An int zero-values to 0, not nil, and a struct zero-values to a struct with every field set to its zero value (so var t time.Time is a usable zero Time, never nil — you cannot compare a struct to nil and it won't compile). The practical trap: a nil slice is safe to range and append to, but a nil map panics on write — same nil, very different usability — which is why people get burned reaching for the wrong one.

True for Go 1.22+. The loop variable was redefined to have per-iteration scope: the variable is effectively re-declared each iteration, so a captured i holds the value from its own iteration. Before Go 1.22 there was a single shared i for the whole loop, and goroutines/closures launched in the loop notoriously all observed the final value — the decade-old 'loop variable capture' gotcha. The behavior is gated on the go directive in go.mod, so the same source can behave differently depending on the declared language version. This is why the version must be pinned when reasoning about loop-capture code.

b := a[:2] makes a slice of length 2 but capacity 4 that shares a's backing array. Because there is spare capacity, append(b, 99) writes into the existing array at index 2 instead of allocating a new one — so it overwrites a[2] (the 3) with 99. a becomes [1 2 99 4] and b is [1 2 99]. The trap (option b) is assuming append always copies; it only reallocates when capacity is exhausted. This aliasing bug bites in production when a subslice handed to one function silently mutates the caller's data — the fix is a full copy or the three-index slice a[:2:2] to cap the capacity and force a reallocation on append.

In Go 1.22+ the loop variable i is per-iteration, so each goroutine's closure captures its own i. wg.Wait() guarantees all three goroutines finish before the print, and because each writes a different index there is no race, making the output deterministic: out[0]=0*0=0, out[1]=1*1=1, out[2]=2*2=4, i.e. [0 1 4]. Option b ([4 4 4]) is the pre-1.22 result, where a single shared i had already reached its final value 2 by the time the goroutines ran (and 2*2=4). The version pinned in go.mod decides which behavior you get, so the same source can produce either output across Go versions — a real hazard when upgrading or copying old code.

wg.Add(1) runs inside each goroutine, so there is a race between the main goroutine reaching wg.Wait() and the workers getting scheduled to call Add. If Wait() runs first, the counter is still 0 and it returns immediately without waiting; it can also panic with 'WaitGroup is reused before previous Wait has returned' or a negative counter under bad interleavings. The fix is to call wg.Add(1) in the loop before go func(...), so the count is registered before any goroutine can finish or Wait can be reached. Option b is wrong — defer works fine inside goroutines. Option c is wrong here because the closure captures the outer wg by reference already (it isn't a parameter). This 'Add inside the goroutine' mistake is one of the most common Go concurrency bugs and produces flaky, schedule-dependent failures.

An interface value holds a (type, value) pair and is nil only when both halves are nil. Returning a nil-valued *MyError into an error sets the type half, so the interface is non-nil despite the nil pointer — err != nil is true and a later method call can panic. The fix is to return the untyped nil on success, never a typed nil pointer. This 'typed nil' bug is a senior-level favorite because the code looks obviously correct; it surfaces in production as panics in error-handling paths that 'should never run'.

Context is Go's standard mechanism for cancellation, deadlines, and request-scoped data. The crucial mechanic is that ctx.Done() returns a channel closed on cancellation, so goroutines select on it to exit cleanly — this is how you avoid leaking goroutines that keep running after their work is no longer needed. Forgetting defer cancel() is a common resource leak. Passing Context as the first parameter and respecting Done() is core to writing well-behaved Go services.

mu.Lock() acquires the mutex and mu.Unlock() releases it. Pairing Lock() with an immediate defer Unlock() is the standard Go idiom because the deferred call runs on every return path — including a panic — so the lock can't be leaked. A forgotten or skipped Unlock causes every other goroutine waiting on that mutex to block forever, a classic deadlock. Note sync.Mutex is not reentrant: locking it twice from the same goroutine deadlocks.

A strong answer treats 'worker pool' as concrete channel/goroutine plumbing: N workers ranging a closed-when-done jobs channel to bound concurrency, results flowing back over a channel (not a racy shared slice), a context selected on for prompt cancellation, and a WaitGroup-plus-closer so the results channel is closed exactly once after all senders exit. The recurring interview signal is whether the candidate can answer 'who closes the channel and how do you avoid send-on-closed and leaks on cancel' — the questions that separate someone who has shipped Go concurrency from someone who has only read about goroutines.

Two rules combine here. First, deferred-call arguments are evaluated immediately, so each defer fmt.Println(i) snapshots the current i — capturing 0, 1, then 2. Second, deferred calls run in last-in-first-out order when main returns, so they fire as 2, 1, 0 — after "done", which prints during normal execution. The result is done, 2, 1, 0. Option d (3 3 3) is the answer you'd get if defer captured the variable by reference and ran after the loop — but argument snapshotting prevents that, and in Go 1.22+ each i is per-iteration anyway. LIFO ordering matters in real code when stacking defer file.Close() / defer mu.Unlock() calls that must unwind in reverse.

The key distinctions: goroutines are scheduled by the Go runtime in user space (not the kernel), are multiplexed M:N onto a small pool of OS threads, and start with a tiny growable stack (~2KB) versus a thread's large fixed stack. That's what makes them cheap enough to spawn by the hundreds of thousands. A strong answer names the small/growable stack and the runtime scheduler; weak answers just say 'goroutines are lighter' without the mechanism. This matters at work when deciding concurrency strategy — goroutines make per-request or per-connection concurrency practical where a thread-per-connection model would not scale.