Concurrency interview questions and coding rounds

Goroutine versus OS thread

A goroutine is managed by the Go runtime, not the operating system. It starts with a small stack of a few kilobytes that grows as needed, and the runtime scheduler multiplexes many goroutines onto a few OS threads (often described as the G-M-P model: goroutines, machine threads, processors). Creating and switching goroutines is much cheaper than threads, so a server can run hundreds of thousands. GOMAXPROCS controls how many threads run Go code at once.

Buffered versus unbuffered channels

An unbuffered channel synchronises: the send completes only when a receiver takes the value. A buffered channel of capacity n lets n sends complete without a receiver; sends block when it is full and receives block when it is empty. Use unbuffered for hand-offs and signals, buffered to absorb bursts or as a semaphore.

Deadlocks and goroutine leaks

A deadlock is when goroutines wait for each other forever. If ALL goroutines are blocked, the runtime stops with "all goroutines are asleep - deadlock!". If only some are stuck (for example a sender whose receiver timed out and left), the program keeps running but leaks those goroutines. Prevent leaks with buffered result channels, context cancellation, and clear ownership of who closes each channel.

Mutex or channel?

Channels are for passing ownership of data and for signalling between goroutines (pipelines, worker pools, done signals). A mutex is for protecting shared state that several goroutines read and update (a cache, a counter). Both are correct; choose the one that makes the code simplest. Always mention the race detector (go test -race) when discussing either.

Pattern 1: bounded parallelism (a semaphore)

func fetchAll(ctx context.Context, urls []string, limit int) []string {
	results := make([]string, len(urls))
	sem := make(chan struct{}, limit) // at most "limit" fetches at once
	var wg sync.WaitGroup
	for i, u := range urls {
		wg.Add(1)
		go func() {
			defer wg.Done()
			sem <- struct{}{}        // acquire a slot
			defer func() { <-sem }() // release it
			results[i] = fetch(ctx, u)
		}()
	}
	wg.Wait()
	return results
}

Pattern 2: worker pool with results

func process(ctx context.Context, jobs []int, workers int) []int {
	in := make(chan int)
	out := make(chan int)
	var wg sync.WaitGroup
	for range workers {
		wg.Add(1)
		go func() {
			defer wg.Done()
			for j := range in {
				select {
				case out <- j * j:
				case <-ctx.Done():
					return
				}
			}
		}()
	}
	go func() {
		defer close(in)
		for _, j := range jobs {
			select {
			case in <- j:
			case <-ctx.Done():
				return
			}
		}
	}()
	go func() { wg.Wait(); close(out) }()

	var res []int
	for r := range out {
		res = append(res, r)
	}
	return res // order not guaranteed
}

Pattern 3: a simple token-bucket rate limiter

type Limiter struct {
	mu       sync.Mutex
	tokens   float64
	max      float64
	perSec   float64
	last     time.Time
}

func NewLimiter(perSec, burst float64) *Limiter {
	return &Limiter{tokens: burst, max: burst, perSec: perSec, last: time.Now()}
}

func (l *Limiter) Allow() bool {
	l.mu.Lock()
	defer l.mu.Unlock()
	now := time.Now()
	l.tokens = min(l.max, l.tokens+now.Sub(l.last).Seconds()*l.perSec)
	l.last = now
	if l.tokens >= 1 {
		l.tokens--
		return true
	}
	return false
}

Questions to expect