Go interview questions — practice with real interview problems

A goroutine begins life when the go statement executes and the runtime creates it. It then runs the function body. When that function returns (or the goroutine panics), the goroutine terminates. These three stages are strictly sequential: creation precedes execution, and execution precedes termination.

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.

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.

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.

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.

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.

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.

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.

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.

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.