Go (Golang) Language Core Interview Preparation Guide

A Go array has a fixed length defined as part of its static type (e.g., [5]int), meaning its size cannot change and it is passed by value in function calls. Conversely, a slice is a dynamically-sized, flexible descriptor containing a pointer to an underlying array, a length, and a capacity. Slices provide reference semantics to underlying arrays, allowing constant-time windowing and dynamic resizing via the append function without copying underlying elements.

Go maps are intentionally designed without internal mutex locking because most code does not require concurrent map access, and adding locks would impose unnecessary performance overhead on single-threaded operations. When multiple goroutines read and write to a map concurrently, the runtime detects the race condition and triggers a fatal panic. To handle concurrent access safely, developers must protect map operations using a sync.RWMutex, utilize sync.Map for specialized append-heavy workloads, or manage map state via a dedicated owner goroutine communicating over channels.

An unbuffered channel enforces strict rendezvous synchronization. A sending goroutine blocks until a receiving goroutine is ready to receive the data, and vice versa. A buffered channel contains a circular queue of a specified capacity, allowing senders to transmit data asynchronously without blocking until the buffer is completely full. Similarly, receivers can consume items from a buffered channel without blocking until the buffer is completely empty.

Escape analysis is a static analysis pass performed by the Go compiler during compilation. It inspects variable lifetimes and usage to determine whether a variable can be safely allocated on the thread-local stack or if it must 'escape' to the heap. Stack allocations are exceptionally fast and require no garbage collection overhead, whereas heap allocations increase garbage collector mark-sweep pressure. Understanding escape analysis helps engineers write zero-allocation code paths for ultra-low-latency systems.

Go's M:N scheduler multiplexes goroutines (G) onto OS threads (M) via logical processors (P). Each logical processor maintains a local run queue of runnable goroutines. When a processor exhausts its local run queue, it enters a work-stealing phase where it attempts to steal half of the runnable goroutines from another processor's local run queue or the global run queue. This dynamic balancing ensures high CPU core utilization and prevents idle CPU cycles.

Sending data to a closed channel triggers an immediate fatal runtime panic that crashes the application. In contrast, receiving from a closed channel never blocks; it immediately returns the zero value of the channel's element type along with a boolean second return value (ok) set to false, indicating that the channel is closed and no further values will arrive.

A goroutine leak occurs when a goroutine is spawned but blocks permanently on an unbuffered channel send/receive or a synchronization primitive, never exiting its execution function. Because its stack and metadata remain pinned in memory, it leaks resources indefinitely. Prevention techniques include using buffered channels, propagating context cancellation via context.WithTimeout or context.WithCancel, and ensuring all spawned worker goroutines have clear termination paths.

The garbage collector uses a tri-color abstraction (white, grey, black) to traverse heap objects. During concurrent marking, application goroutines continue running while the collector scans object graphs. To prevent application threads from hiding white objects from grey objects during mutation, the runtime employs a hybrid write barrier. This barrier intercepts pointer updates, ensuring all live objects are correctly marked before the sweep phase reclaims unmarked white memory.

In a 'for i, v := range slice' loop, Go reuses the exact same iteration variable v across every iteration, updating its value in place. If you spawn a goroutine inside the loop that captures v by reference (e.g., go func() { println(v) }()), all spawned goroutines will likely evaluate v at its final loop value or race across memory modifications. The fix is to bind the variable locally inside the loop block (v := v) before passing it into the closure.

GOMAXPROCS defines the maximum number of operating system threads that can execute Go code simultaneously, which equals the number of logical processors (P). By default, Go queries the underlying host OS for total CPU core counts. In containerized environments with strict CPU quotas (cgroups), this can cause Go to spin up too many threads, resulting in CPU throttling and scheduler latency. It should be configured using libraries like go.uber.org/automaxprocs to match container limits automatically.

When a goroutine executes a blocking system call (such as a file I/O or database driver call) that blocks its underlying OS thread (M), the runtime detaches the logical processor (P) from that blocked M thread. The detached P is then paired with a new or idle M thread, allowing it to continue running other runnable goroutines from its local queue while the original thread waits on the kernel system call.

While passing pointers avoids copying struct data, excessive pointer usage forces small objects to escape to the heap during escape analysis. This increases garbage collector mark-sweep pressure, causes heap allocation churn, and reduces CPU cache locality because pointer dereferencing requires jumping across non-contiguous memory locations. Small structs and primitive values should generally be passed by value.