Initial commit: Go SRE interview exercises

Includes solved 02-worker-pool and 09-safe-counter (mutex, atomic, sharded).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GbnJj9ZqEx9nUvzkjdwfMq

10-gotchas/README.md

@@ -0,0 +1,129 @@
+# 10 — Gotchas: "What Does This Print?"
+
+The trivia round. Each subfolder is a tiny program. The drill:
+
+1. Open `main.go`, **predict the exact output** (or panic/deadlock/compile error).
+2. `go run ./10-gotchas/exNN-.../` and check yourself.
+3. Read the answer below — then explain it OUT LOUD in one breath, because
+   that's the actual interview skill.
+
+Note: ex11 intentionally does not compile, and ex02 intentionally deadlocks —
+that IS the exercise. (This folder is excluded from `go build ./...` sanity by
+being all `main` packages; run them individually.)
+
+---
+
+## Answers (no peeking before predicting)
+
+<details><summary><b>ex01 — loop variable capture</b></summary>
+
+Go ≥1.22: `0 1 2` in some order — the `for` statement gives each iteration a
+fresh `i` (spec change in 1.22, one of the very few semantic changes ever made
+to Go). Pre-1.22: typically `3 3 3` — all closures captured the *same*
+variable, which was 3 by the time they ran. Old fixes: `go func(i int){...}(i)`
+or shadowing `i := i`. Always mention the version boundary; it proves your
+knowledge has a timestamp.
+</details>
+
+<details><summary><b>ex02 — unbuffered send deadlock</b></summary>
+
+`fatal error: all goroutines are asleep - deadlock!` An unbuffered send blocks
+until a receiver is ready; there is no other goroutine. Fix A:
+`make(chan int, 1)`. Fix B: do the send or receive in another goroutine.
+Key nuance: the runtime detects only *global* deadlock (every goroutine
+blocked). One stuck goroutine among many = silent leak, no error, ever.
+</details>
+
+<details><summary><b>ex03 — closed channel semantics</b></summary>
+
+Prints `1`, then `0 false`, then **panics**: `close of closed channel`.
+Buffered values survive close and drain normally; after drain, receive returns
+zero value + `ok=false` *immediately* (never blocks). Send on closed also
+panics. Recite the rules: only the sender closes; with multiple senders,
+nobody closes directly (coordinate via WaitGroup); closing is signaling, not
+cleanup — unclosed channels are GC'd fine.
+</details>
+
+<details><summary><b>ex04 — nil channel in select</b></summary>
+
+`b 42`. Operations on nil channels block forever, so a nil case is simply
+never ready — select ignores it. If *all* cases were nil (and no `default`):
+deadlock. This is a load-bearing idiom: set a channel var to nil to disable
+its case dynamically (see exercise 07's README for it powering a fan-in).
+</details>
+
+<details><summary><b>ex05 — slice aliasing via append</b></summary>
+
+`[1 2 99 4]` and `[1 2 3 4]`. First: `a[:2]` has len 2, **cap 4** — append
+fits within cap, writes into the shared backing array, clobbers `a[2]`.
+Second: full slice expression `a[:2:2]` caps the cap at 2 — append must
+reallocate, `a` untouched. Corollaries: this is why `append` returns a value;
+why functions receiving slices can visibly mutate the caller's data *sometimes*
+(only when no realloc happened — the worst kind of bug); and what
+`s[low:high:max]` is actually for.
+</details>
+
+<details><summary><b>ex06 — defer + named returns</b></summary>
+
+`6` then `5`; then `deferred: 2, 1, 0` at main's exit, LIFO. In `f`,
+`return 5` assigns to the *named* return `x`, then defers run and mutate it →
+6. In `g`, `return x` copies into an anonymous slot first → the defer's
+increment is invisible. Also hiding here: `defer fmt.Println("deferred:", i)`
+evaluates the *argument* `i` at defer time — so it's the deferred *closures*
+that capture, plain calls snapshot. Practical use of the f-pattern: wrapping
+errors on the way out via `defer func() { err = ... }()` with a named `err`.
+</details>
+
+<details><summary><b>ex07 — typed nil interface</b></summary>
+
+Prints `got error: boom` — the `err != nil` branch runs. An interface value is
+a (type, value) pair; here it's (`*MyErr`, nil) — a non-nil interface wrapping
+a nil pointer. Interface == nil only when BOTH halves are nil. (The method
+call then works because `Error()` never dereferences its nil receiver — nil
+receivers are legal in Go.) Fix: return literal `nil`, or declare
+`var err error` and assign. If you can whiteboard the two-word pair, you own
+this question.
+</details>
+
+<details><summary><b>ex08 — concurrent map writes</b></summary>
+
+Very likely dies with `fatal error: concurrent map writes` — and `recovered:`
+never prints, because it's a **runtime fatal error (throw), not a panic**:
+`recover()` cannot catch it, the process is gone. (Deliberate design: a
+corrupted map is unrecoverable state.) Fixes: mutex, `sync.Map` (append-mostly
+workloads only), or sharding. `-race` flags it deterministically even on runs
+that happen not to crash.
+</details>
+
+<details><summary><b>ex09 — WaitGroup Add placement</b></summary>
+
+Race: main can reach `wg.Wait()` while the counter is still 0 (no goroutine
+has run `Add` yet) → Wait returns instantly, prints `count: 0..3` — any value.
+Worse interleavings hit "WaitGroup misuse: Add called concurrently with Wait".
+Rule: `Add` in the *spawning* goroutine, before `go`. Plus `count++` is itself
+a data race (`-race` flags both). And always pass `*sync.WaitGroup` — copying
+one with nonzero state breaks the count (`go vet` catches the copy).
+</details>
+
+<details><summary><b>ex10 — goroutine leak on timeout</b></summary>
+
+Prints ~101 goroutines instead of 1. On timeout, nobody ever receives from the
+unbuffered `ch`; the worker goroutine blocks on `ch <- "body"` forever. At
+100 rps against a slow upstream that's OOM with a countdown. The
+one-character-ish fix: `make(chan string, 1)` — the send always succeeds, the
+orphaned result gets GC'd with the channel. The structural fix: pass ctx into
+the work and select the send against `ctx.Done()`. Detection in prod:
+`go_goroutines` metric trending up + pprof goroutine profile showing an army
+parked in `chan send` at one line.
+</details>
+
+<details><summary><b>ex11 — method sets</b></summary>
+
+Compile error: `T does not implement Stringer (method String has pointer
+receiver)`. Method set of `T` = value-receiver methods only; method set of
+`*T` = both. Fix: `var s Stringer = &T{}`. The *why*: interface values can
+hold unaddressable copies (map elements, temporaries), so the compiler can't
+conjure a `*T` from a `T` for you. Related asymmetry people forget: calling
+`t.String()` directly on an addressable `t` works fine — the compiler inserts
+`(&t)` — it's only interface *satisfaction* that's strict.
+</details>