Go Developer interview questions

A bounded worker pool runs a fixed number of workers that consume jobs from a shared channel.

• The fixed worker count bounds concurrent work and resource usage independently of the number of jobs.
• A producer sends jobs and closes the jobs channel after the final job, allowing workers that range over it to exit.
• Each worker calls Done on a WaitGroup when it exits, and a coordinator waits for all workers.
• If workers produce results, the coordinator closes the results channel only after every worker has finished sending.

Fan-out distributes work from one input stream across multiple concurrent consumers.

• Multiple goroutines can receive from the same channel without additional synchronization around each receive.
• Each sent value is delivered to exactly one successful receiver, so workers divide the stream rather than duplicate it.
• The number of consumers controls the maximum parallelism of that stage.
• Completion order can differ from input order unless ordering is restored explicitly.

Fan-in combines values from multiple input channels into one output channel.

• A common implementation starts one forwarding goroutine per input channel.
• Each forwarder ranges over its input and sends every value to the shared output.
• A WaitGroup tracks the forwarders so their independent completion can be coordinated.
• One coordinator closes the output after all forwarders finish; no individual forwarder closes it.

A pipeline connects concurrent stages so each stage receives values, transforms them, and sends results onward.

• Stages expose channels with compatible element and direction types, which lets one stage feed the next.
• With unbuffered channels, a slow downstream stage immediately blocks upstream sends.
• A finite buffer absorbs a limited mismatch in rates, but upstream still blocks when the buffer becomes full.
• This blocking propagates toward the source and provides backpressure without an unbounded queue.

Every pipeline stage must observe a shared cancellation signal while it may block.

• The downstream consumer cancels a context or closes a shared done channel when it stops before draining the pipeline.
• Each stage selects between cancellation and blocking channel operations, especially sends to downstream stages.
• On cancellation, stages return, close any output channels they own, and release other resources.
• Merely stopping the final receive loop is insufficient because upstream goroutines can remain blocked forever on sends.

Channel ownership is the convention that one component controls sending and lifecycle decisions for a channel.

• The owner usually creates the channel, performs or coordinates all sends, and exposes a receive-only view to consumers.
• A channel is closed by the sending side only when no more values will ever be sent.
• Receivers should not close a channel, and a channel must not be closed more than once.
• With multiple senders, a separate coordinator closes the channel only after all senders have finished.

Directional channel types restrict which channel operations code may perform.

• chan<- T permits sending and closing but rejects receives at compile time.
• <-chan T permits receiving but rejects sends and closing at compile time.
• A bidirectional chan T can be assigned or passed as either directional type, but the restricted view cannot be widened back implicitly.
• Function signatures use these types to document ownership intent and enforce API boundaries.

A nil channel is never ready for either communication direction.

• A direct send to or receive from a nil channel blocks forever.
• In a select, a case using a nil channel is disabled and cannot be chosen.
• Assigning nil to a channel variable can dynamically disable its select case without changing the select structure.
• A select whose communication cases are all disabled blocks forever unless it has a default case.

Select chooses one operation that can proceed at the moment the statement is evaluated.

• If exactly one case is ready, that case is selected.
• If several cases are ready, one is chosen using a uniform pseudo-random selection, with no source-order priority.
• A default case runs only when no communication case is immediately ready, making the select nonblocking.
• Repeating a default select in a tight loop can busy-spin and consume CPU.

Channel capacity determines how tightly senders and receivers synchronize.

• An unbuffered send completes only when a receiver participates, creating a direct handoff between the goroutines.
• A buffered send can complete without an immediate receiver while free capacity remains.
• Once the buffer is full, further sends block, so capacity sets the amount of temporary slack before backpressure begins.
• Buffering changes timing and throughput characteristics but does not remove the need for lifecycle and cancellation coordination.

sync.Mutex provides exclusive access to a critical section.

• Its zero value is an unlocked mutex, Lock waits until the mutex is available, and Unlock may be called by a different goroutine.
• A successful Unlock synchronizes before a later successful Lock, so writes in the critical section are visible after that Lock.
• A mutex is not reentrant: locking it again in the same goroutine without an intervening Unlock deadlocks.
• A Mutex must not be copied after first use because the copy has distinct lock state that no longer coordinates all access to the protected data.

sync.RWMutex permits either multiple readers or one exclusive writer.

• RLock can coexist with other read locks, while Lock waits for all readers and excludes both readers and writers.
• Once a writer is waiting, new RLock calls block so that a continuous stream of readers cannot starve the writer.
• It does not support upgrading an RLock to Lock or downgrading Lock to RLock, and it must not be used for recursive read locking.
• Its extra bookkeeping is useful mainly for read-heavy workloads with sufficiently long critical sections; otherwise a Mutex can be simpler and faster.

sync.WaitGroup waits until a tracked set of tasks has finished.

• Call Add before starting each task, and have that task call Done exactly once, commonly with defer.
• Wait blocks until the counter reaches zero, and Add panics if an update makes the counter negative.
• A positive Add performed while the counter is zero must happen before Wait; racing that Add with Wait is unsafe because Wait may return too early.
• A WaitGroup may be reused only after the previous Wait has returned, with all Add calls for the next cycle occurring afterward.

These helpers perform lazy initialization at most once and publish its completed result safely.

• Once.Do invokes its function on the first call, blocks concurrent callers until that call finishes, and never invokes it again.
• If a Once.Do function panics, that invocation still counts as completed, so later Do calls return without rerunning it.
• OnceValue caches one return value, while OnceValues caches two, and each wrapper returns the same cached result on every call.
• If a OnceValue or OnceValues initializer panics, every call to the wrapper panics with the same panic value rather than silently returning.

Atomic operations make a single supported memory operation indivisible without defining a critical section.

• Loads, stores, swaps, adds, and successful compare-and-swap operations are atomic only for the addressed value and operation.
• A read-modify-write sequence made from separate atomic calls is not one atomic transaction unless it is implemented as a correct CAS loop.
• In Go, atomic operations behave as if all of them execute in one sequentially consistent order, which provides synchronization between goroutines.
• Use a mutex when an invariant spans multiple fields or several steps; use atomics for simple counters, flags, or carefully designed lock-free state.

Derived contexts form a tree rooted in an existing parent context.

• Background and TODO are non-nil root contexts, while WithCancel, WithDeadline, and WithTimeout create children.
• Canceling a parent cancels every descendant derived from it.
• Canceling a child does not cancel its parent, siblings, or other branches of the tree.
• A Context is safe for concurrent use and is normally passed explicitly as the first parameter across call boundaries.

Context cancellation is cooperative: code must observe the signal and stop its own work.

• Done returns a receive-only channel that is closed when the context is canceled or its deadline expires, and it may be nil for contexts that cannot be canceled.
• Err returns nil before Done is closed, then returns either context.Canceled or context.DeadlineExceeded.
• Blocking code commonly selects between its normal channel operation and ctx.Done() to avoid waiting indefinitely.
• After observing Done, code should return promptly and release owned resources rather than expecting the context to terminate the goroutine.

WithDeadline and WithTimeout derive a context that is canceled no later than the requested time.

• WithDeadline uses an absolute time, while WithTimeout computes a deadline relative to the current time.
• The effective deadline cannot extend beyond an earlier parent deadline.
• The returned cancel function should normally be deferred immediately, even when automatic expiration is expected.
• Calling cancel early releases the derived context's timer and parent linkage and prevents resources from being retained until the deadline.

Context values are for request-scoped data that must cross API and process boundaries.

• Keys should use a private, comparable type rather than built-in strings to avoid collisions between packages.
• Stored values should be safe for concurrent access and should usually be exposed through typed accessor functions.
• Value searches the current context and then its ancestors, returning the nearest value for the matching key or nil.
• Configuration and optional function parameters belong in explicit arguments or option types because context values hide dependencies and weaken type checking.

WithCancelCause lets cancellation carry a domain-specific error in addition to the standard context state.

• It returns a CancelCauseFunc that records a supplied non-nil error if the context is not already canceled; passing nil records context.Canceled.
• When CancelCauseFunc wins, Cause returns the recorded error while Err returns context.Canceled; an earlier parent cancellation retains the parent's Err and cause.
• The cause propagates to descendants unless a descendant establishes its own cancellation cause first.
• Before cancellation Cause returns nil, and after cancellation without an explicit cause it returns the same standard error as Err.