Go Interview Questions and Answers

context.Context carries deadlines, cancellation signals and request-scoped values across API boundaries and goroutines. It is how cancellation and timeouts propagate through a call tree.

func handler(ctx context.Context) error {
    ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
    defer cancel()

    req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
    _, err := http.DefaultClient.Do(req)
    return err
}

Key rules:

• Cancellation propagates down the tree: cancelling a parent cancels every derived context.
• Always call the cancel function, usually with defer, to release timers and resources.
• Pass ctx as the first parameter and check ctx.Done() in loops and blocking selects.
• Use WithValue sparingly, only for request-scoped metadata such as trace IDs, never for optional parameters.
• Never store a Context inside a struct; pass it explicitly through calls.

Common bugs are ignoring cancellation so work continues after a client disconnects, and misusing values as a hidden dependency injection channel.

Go's advice is "do not communicate by sharing memory; share memory by communicating", but both tools are legitimate.

• Use a mutex when protecting a small piece of shared state such as a counter, cache or struct field. It is simpler, cheaper and avoids goroutine leaks.

type SafeMap struct {
    mu sync.RWMutex
    m  map[string]int
}

func (s *SafeMap) Get(k string) int {
    s.mu.RLock()
    defer s.mu.RUnlock()
    return s.m[k]
}

• Use channels to transfer ownership of data, to build pipelines, to signal completion, or to coordinate a bounded worker pool. Channels give you synchronisation plus select-based multiplexing for free.

The trade-offs: channels are heavier and overuse leads to convoluted control flow. A mutex protects state but does not coordinate lifetimes. Never copy a mutex after first use, prefer sync.RWMutex for read-heavy data, keep critical sections small, and always run go test -race to catch data races.