Go's concurrency model — goroutines, channels, and the select statement — is one of its defining features. These exercises cover the core concurrency primitives and patterns every Go developer uses to write safe, efficient concurrent programs.
0 / 5 completed
1 / 5
At standup, a colleague asks what a goroutine is in Go. What is the correct answer?
Goroutines are Go's lightweight concurrency primitive. Unlike OS threads, goroutines start with a small stack (~2KB) that grows as needed, and the Go runtime schedules thousands or millions of them across a pool of OS threads using the M:N scheduler. You launch a goroutine with the go keyword: go myFunc(). The low overhead makes goroutines practical for per-connection or per-request concurrency.
2 / 5
During a PR review, a teammate asks how channels enable safe communication between goroutines. Which answer is correct?
Go channels are typed, concurrent-safe conduits. An unbuffered channel (make(chan T)) blocks the sender until the receiver reads — providing synchronisation. A buffered channel (make(chan T, n)) allows up to n values to be buffered before blocking. The Go proverb is: 'Do not communicate by sharing memory; share memory by communicating' — channels prevent data races by design.
3 / 5
In a design review, the team discusses the select statement in Go. A junior engineer asks what it does. What is correct?
Go's select statement listens on multiple channels simultaneously and executes the first case whose channel operation can proceed. If multiple cases are ready at the same time, Go picks one at random — ensuring fairness. Adding a default case makes select non-blocking (it executes immediately if no channel is ready). select is the idiomatic way to handle timeouts (time.After), cancellation, and fan-in patterns.
4 / 5
An incident report shows goroutines leaking because they never terminate after their context is cancelled. A senior engineer asks how context cancellation is correctly used in Go. What is correct?
Go's context.Context is the standard cancellation mechanism. You create a cancellable context with context.WithCancel(parent), pass it to goroutines, and call cancel() when done. The goroutine uses select { case <-ctx.Done(): return } to detect cancellation and exit cleanly. Without this pattern, goroutines block indefinitely on channel operations and leak. The defer cancel() pattern ensures cancellation is always called even on early returns.
5 / 5
During a code review, a senior engineer asks what sync.WaitGroup is used for. What is accurate?
sync.WaitGroup is the idiomatic way to wait for a set of goroutines to complete. Call wg.Add(1) before spawning each goroutine (or wg.Add(n) before a loop), and have each goroutine call defer wg.Done() before returning. The main goroutine (or coordinator) calls wg.Wait(), which blocks until the internal counter reaches zero. This is commonly used for fan-out patterns: spawn N worker goroutines, wait for all to finish, then aggregate results.