Describe Go's memory management, garbage collection, and trade-offs

WHAT THIS TESTS: whether you understand the boundary between compile-time and runtime memory decisions in Go and can articulate the core trade-off of automatic garbage collection. Interviewers want to see that you know the GC is not a black box that handles everything, but part of a broader strategy where the compiler optimizes what it can and the runtime handles the rest.

A GOOD ANSWER COVERS: first, that the Go language manages storage for values automatically and the standard toolchain includes a garbage collector in its runtime to recycle heap memory that is no longer needed. Second, that non-pointer local variables are typically allocated on the goroutine stack by the compiler because their lifetime is tied to lexical scope, making cleanup faster and more predictable than heap allocation. Third, that when the compiler cannot determine a value's lifetime, the value escapes to the heap, where memory is dynamically allocated and the GC must identify unreachable objects to free them. Fourth, that the fundamental trade-off for developers is convenience and safety versus runtime cost: automatic recycling consumes CPU cycles and can introduce pauses, meaning you sacrifice fine-grained control over memory layout and deallocation timing.

COMMON WRONG ANSWERS: claiming that every memory allocation in Go is managed by the GC, which ignores stack allocation entirely. Confusing Go's automatic management with manual memory management or Rust's ownership model. Asserting that the GC behavior described is guaranteed by the Go specification, when the spec only says value storage is managed by the language and intentionally omits GC details to allow different implementations. Pretending there is no runtime cost to garbage collection.

LIKELY FOLLOW-UPS: how does escape analysis work and how can you inspect it with the compiler flags. What techniques reduce heap allocations in performance-critical code. Whether the Go spec makes any guarantees about GC latency or if those are implementation details. How goroutine stack growth interacts with heap memory and whether stacks are ever GC-managed.

ONE CONCRETE EXAMPLE: consider a helper function that allocates a large array of integers. If the array is local and never returned or referenced outside the function, the compiler keeps it on the stack; when the function returns, the stack pointer moves and the memory is reclaimed instantly with no GC work. If you refactor the function to return a pointer to that array, the value escapes to the heap because the compiler cannot prove the lifetime ends at the return. The array now occupies heap memory and the GC must trace it during a cycle to prove it is unreachable, consuming CPU that could have executed application logic.