Go Developer interview prep

Short answer: Polymorphism comes from implicit (structural) interface satisfaction: a type satisfies an interface automatically if it has the required method set — no implements. Instead of inheritance there is composition via embedding, and encapsulation is driven by the first letter's case.

In depth:

1. Structural typing (duck typing) — "if it quacks like a duck". Type and interface are never explicitly linked; the link is checked by method signatures at compile time.
2. Composition over inheritance — embedding promotes the embedded type's methods outward, but that is has-a, not is-a.
3. Encapsulation — an uppercase name is exported, a lowercase one is private to the package.

type Stringer interface{ String() string }

type Point struct{ X, Y int }

func (p Point) String() string { // Point implements Stringer
    return fmt.Sprintf("(%d,%d)", p.X, p.Y)
} // no "implements Stringer" — matching the method is enough

⚠️ Common mistake: calling embedding "inheritance". There are no subtypes and no virtual dispatch: the outer type does not convert to the embedded one, and an embedded method is not "overridden" and cannot see the outer type's fields.

Short answer: A goroutine is a lightweight unit of execution managed by the Go runtime, not the OS kernel. Its stack starts at ~2 KB and grows dynamically, while an OS thread reserves megabytes of fixed stack. The runtime multiplexes thousands of goroutines onto a small number of threads in an M:N model, so a single process comfortably hosts hundreds of thousands of goroutines.

In depth:

1. Stack — goroutine: ~2 KB, grows/shrinks on demand; OS thread: a fixed 1–8 MB reserved up front.
2. Scheduler — goroutines are scheduled by the Go runtime (the GMP model: G — goroutine, M — OS thread, P — processor context) in user space; threads are scheduled by the kernel.
3. Switch cost — a goroutine switch never enters the kernel and is orders of magnitude cheaper than a thread context switch.
4. Scale — threads realistically number in the thousands, goroutines in the hundreds of thousands and beyond.

⚠️ Common mistake: answering "it's a lightweight thread" and stopping there. Without mentioning the runtime scheduler and the M:N model the answer sounds junior — the interviewer wants the mechanics.

Short answer: Mutex gives exclusive access — one goroutine in the critical section at any moment. RWMutex splits the lock in two: under RLock() readers enter in parallel, while a writer's Lock() is exclusive and waits for all readers to leave. RWMutex only pays off where reads greatly outnumber writes.

In depth:

1. Mutex — a plain lock: Lock()/Unlock(), always a single owner. The default choice.
2. RWMutex — RLock() for readers (many at once), Lock() for the writer (one, exclusive).
3. When to reach for RWMutex — only after profiling shows contention on reads and the read:write ratio is high (say 10:1 or more), and the critical section isn't microscopic.

⚠️ Common mistake: using RWMutex "just in case" and warning about writer starvation. Go has none: RWMutex is write-preferring — a waiting Lock() blocks new readers (side effect: a recursive RLock() in one goroutine can deadlock). The real cost is the pricier acquire: for short sections a plain Mutex is often faster.

Short answer: GOMAXPROCS sets the number of P — the maximum count of OS threads executing Go code simultaneously. By default it equals the number of logical CPUs (runtime.NumCPU()) — the case since Go 1.5.

In depth:

1. What it actually caps. Only parallel execution of Go code. Goroutines blocked on a syscall or network I/O don't count toward the limit — a process can have far more threads than GOMAXPROCS.
2. How to change it. Via the GOMAXPROCS env var or at runtime with runtime.GOMAXPROCS(n).
3. The container trap. Historically the default took the whole node's core count and ignored the cgroup CPU limit: on a 64-core node limited to "2 CPU" the runtime spun up 64 P — extra context switches and throttling. The classic fix is uber-go/automaxprocs.
4. Recent Go. As of Go 1.25 the runtime honors the cgroup CPU limit by default — on Linux the default rounds up from the limit, so check the version before reaching for the workaround.

// GOMAXPROCS=4 ./app — via the environment variable
runtime.GOMAXPROCS(4)      // or at runtime
n := runtime.GOMAXPROCS(0) // 0 — read the current value without changing it

⚠️ Common mistake: on Go < 1.25, relying on the default inside Kubernetes with a CPU limit. Without automaxprocs the runtime sees all of the node's cores, not your allotted quota.

Short answer: Use fmt.Errorf with the %w verb: fmt.Errorf("read config: %w", err). It's %w that stitches the original error into the Unwrap chain, so errors.Is/errors.As keep seeing it. The verbs %v and %s insert only the text and break the chain.

In depth:

1. %w preserves the chain — it wraps the error while keeping access to the original via Unwrap. Add short context: what the code was doing, not a restatement of the error.
2. %v/%s break the chain — use them only when you deliberately hide the underlying error from the caller (an abstraction boundary).
3. Layered context — each level adds its own prefix, giving a readable trail: open user file: read config: permission denied.

if err != nil {
    return fmt.Errorf("read config %q: %w", path, err)
}
// errors.Is(err, os.ErrPermission) still works

⚠️ Common mistake: handling an error twice — logging it and also returning it up. Each layer either wraps and returns, or (at the very top) logs — not both, or your logs double up.