72 Golang Interview Questions and Answers (2026)

An array has a fixed length that is part of its type, while a slice is a flexible, growable view over an underlying array: in practice you almost always use slices.

• Array: fixed size, value type:

  • [3]int and [4]int are distinct types; length is compile-time fixed.

  • Assigning or passing an array copies all its elements.

• Slice: dynamic view, reference-like:

  • A slice is a small header of three fields: pointer to backing array, length, and capacity.

  • Copying a slice copies the header but shares the same underlying array, so mutations are visible across copies.

• Growth and operations:

  • Slices support append and reslicing (s[1:3]); arrays do not grow.

  • len() and cap() apply to slices; arrays only have a fixed length.

• Gotcha: Two slices from the same array share memory: editing one can change the other.

Because strings are immutable in Go, each + concatenation allocates a brand-new string and copies all existing bytes, making a loop O(n²); strings.Builder appends into a growable buffer and avoids those repeated allocations and copies.

• Strings are immutable:

  • a + b cannot modify a in place; it must allocate a new string and copy both operands.

  • In a loop this re-copies the accumulated result every iteration: quadratic time and heavy garbage.

• strings.Builder amortizes growth:

  • It writes into an internal []byte that grows like a slice, so total work is amortized O(n).

  • String() returns the result without copying the buffer (uses an unsafe internal trick).

• Extra tips:

  • Call Grow(n) if you know the final size to preallocate.

  • For a known small fixed number of pieces, + or strings.Join is fine; the win is in loops.

The zero value is the default value Go automatically assigns to any variable declared without an explicit initializer, so every variable is always usable and there is no concept of uninitialized memory.

• Defaults by type:

  • 0 for numeric types, false for bool, "" for strings.

  • nil for pointers, slices, maps, channels, functions, and interfaces.

  • For structs, every field is recursively set to its own zero value.

• Why it's useful:

  • No uninitialized-variable bugs: declaring is always safe.

  • Enables 'useful zero values': a type works out of the box without a constructor (e.g. sync.Mutex, bytes.Buffer, and strings.Builder are ready to use when zero).

• Caveats:

  • A nil map can be read but panics on write; you must make it first.

  • You sometimes can't distinguish 'set to zero' from 'never set' (use a pointer or ok-flag if that matters).

Go is fast because it compiles directly to native machine code ahead of time (no interpreter or VM warm-up), pairs that with a lightweight concurrency model and an efficient garbage collector, giving near-C startup and execution while staying memory-safe.

• Ahead-of-time native compilation:

  • Code becomes a standalone machine-code binary, so there is no per-line interpretation (Python) or JIT warm-up (JVM).

  • Startup is instant: the binary just runs.

• Static typing and value types:

  • Types are resolved at compile time, avoiding runtime type dispatch overhead.

  • Structs are laid out as compact value types with good cache locality, not boxed objects.

• Efficient concurrency: Goroutines are cheap (a few KB stacks) and multiplexed onto OS threads by the runtime scheduler, scaling concurrency without thread-per-request cost.

• Low-latency garbage collector: A concurrent GC tuned for short pauses keeps throughput high while remaining memory-safe.

• Honest caveat: Go is typically a bit slower than C/C++/Rust (GC overhead, less aggressive optimization) but far faster than interpreted languages.

int8 and int16 are sized integers with explicit bit widths (8 and 16 bits, fixed ranges), while int is a platform-dependent type sized to the machine's word (32 or 64 bits): Go offers multiple types so you can trade range against memory and control exact layout.

• Fixed-width types:

  • int8 holds -128..127, int16 holds -32768..32767; ranges and sizes are guaranteed regardless of platform.

  • Useful for memory-tight data, binary protocols, and predictable on-disk/wire layouts.

• int is word-sized:

  • It is 64 bits on 64-bit platforms and 32 bits on 32-bit ones, matching the CPU's natural register size for speed.

  • It is the idiomatic default for counters, loop indices, and lengths.

• Why not one type:

  • Different jobs need different tradeoffs: minimal memory in large arrays vs. fast default arithmetic.

  • Exact sizes are required for serialization and hardware/protocol correctness.

• No implicit conversion: Go won't mix types silently: you must convert explicitly (int16(x)), preventing accidental overflow/truncation bugs.

iota is a predeclared identifier that auto-increments within a const block: it starts at 0 and increases by 1 for each ConstSpec line, making it the idiomatic way to define enumerated constants.

• Resets and increments per const block: iota is 0 on the first line of a const group and increments by one for each subsequent line, regardless of how many constants are on that line.

• Expressions carry down: If a line omits its value, it repeats the previous expression with the new iota value, so you write the formula once.

• Skip values with _: Use the blank identifier _ to skip an unwanted value (often 0).

• Useful for bit flags: 1 << iota generates powers of two for bitmask-style enums.

Go is always pass-by-value: every argument is copied into the function. The confusion arises because some types are small descriptors that contain pointers, so copying the descriptor still lets you reach the same underlying data.

• Everything is copied: A function receives a copy of the value; reassigning the parameter never affects the caller.

• Slices: A slice is a header (pointer, len, cap) that is copied; the copy points to the same backing array, so mutating elements is visible to the caller, but append that reallocates is not.

• Maps: A map value is a reference to the same internal hash table, so writes through the copy are seen by the caller.

• Pointers: The pointer itself is copied, but it still addresses the same memory, so dereferencing and mutating affects the original.

• Rule of thumb: To modify a struct or basic value in the caller, pass a pointer (*T); slices, maps, and channels already share underlying state.

An unbuffered channel has no capacity and requires a sender and receiver to meet (rendezvous); a buffered channel has a fixed capacity and only blocks the sender when that buffer is full.

• Unbuffered (make(chan T)):

  • Send blocks until another goroutine receives; it's a synchronization point (handshake).

  • Guarantees the value was handed off before the sender proceeds.

• Buffered (make(chan T, n)):

  • Send succeeds immediately while the buffer has room; the sender only blocks when the buffer is full.

  • Decouples sender and receiver timing, useful for smoothing bursts.

• Receiver side: Receive blocks whenever the channel is empty, buffered or not.

• Design note: Unbuffered gives stronger ordering/happens-before guarantees; buffering trades that for throughput and looser coupling.

init() is a special function for package-level setup that runs automatically before main, and Go guarantees a deterministic order: dependencies initialize before the packages that import them.

• Purpose:

  • Initialize state that can't be expressed as a simple declaration: registering drivers, validating config, building lookup tables.

  • Takes no arguments and returns nothing; you cannot call it explicitly.

• Order of execution:

  1. Imported packages are fully initialized first (recursively, deepest dependency first).

  2. Within a package, package-level variables are initialized in dependency order.

  3. Then init() functions run in the order the files are presented to the compiler (alphabetical by filename).

  4. Finally main() runs.

• Multiple init() allowed: A single file or package can declare several init() functions; all run.

• Caution: heavy or order-sensitive init() logic hides dependencies and complicates testing; prefer explicit constructors where practical.

new(T) allocates zeroed memory and returns a *T, while make initializes and returns a ready-to-use slice, map, or channel (not a pointer): the difference is that those three types need internal setup beyond zeroing.

• new(T):

  • Works for any type; allocates and zeroes it, returning a pointer *T.

  • The zero value is usable for many types but not for maps/channels (a nil map panics on write).

• make:

  • Only for slice, map, and chan; returns an initialized value of type T, not a pointer.

  • Why these three: they are reference types backed by runtime data structures (slice header, hash table, channel buffer) that must be constructed before use.

• Quick mental model: new = "give me a zeroed pointer"; make = "give me a usable built-in collection".

Go favors composition over inheritance: a struct embeds other structs or interfaces to reuse their fields and methods, and interfaces define behavior that any type can satisfy implicitly, giving reuse and polymorphism without class hierarchies.

• Struct embedding (promotion):

  • An embedded type's fields and methods are promoted to the outer struct, so the outer type can call them directly.

  • This is composition, not inheritance: the outer type "has-a" embedded value, and you can override by defining a method with the same name.

• Interface embedding: Interfaces compose by embedding smaller interfaces (e.g. io.ReadWriter embeds Reader and Writer).

• Polymorphism via implicit interfaces: Any type with the right methods satisfies an interface, no implements declaration, decoupling callers from concrete types.

• Why no inheritance: Avoids fragile deep hierarchies; behavior is shared by delegation and small interfaces instead.

Go treats errors as ordinary values returned alongside results, forcing callers to handle failure at the point it happens instead of letting it propagate invisibly up a call stack like exceptions.

• Errors are values, not control flow:

  • A function returns (result, error), and the caller checks if err != nil right there.

  • Failure paths are visible in the code, not hidden behind an invisible throw.

• Readability in large systems:

  • You can trace every place a function can fail by reading it linearly; no need to guess which calls might throw.

  • The trade-off is verbosity: lots of repetitive if err != nil blocks.

• Reliability benefits:

  • Errors can't silently skip cleanup or unwind across many layers unexpectedly.

  • Handling is explicit and local, so engineers consciously decide to handle, wrap, or propagate each error.

• Panic exists for truly exceptional cases: Programmer bugs and unrecoverable states, not expected failures like a missing file.

panic and recover are meant for truly exceptional, unrecoverable situations (programmer bugs, corrupt state), not for ordinary errors: using them as control flow hides failure paths and breaks Go's explicit-error idiom.

• Intended use of panic:

  • Signal an unrecoverable condition: index out of range, nil dereference, an impossible invariant violation.

  • It unwinds the stack, running deferred functions along the way, then crashes the program if not recovered.

• Intended use of recover:

  • Called inside a defer to stop a panic, e.g. keeping a server alive by isolating one crashing request handler.

  • Often the recovered panic is converted back into a returned error at a package boundary.

• Why it's bad as normal control flow:

  • It's like hidden exceptions: callers can't see from the signature that a function might bail out.

  • It's slower and harder to reason about than returning an error.

  • recover only works in a deferred function, so misuse leads to surprising, hard-to-debug flow.

Deferred calls run in LIFO (last-in, first-out) order when the surrounding function returns, after the return values have been assigned but before control returns to the caller, which lets a deferred function observe and even modify named return values.

• LIFO order: The last defer registered runs first; think of a stack.

• Arguments evaluated at defer time: The deferred call's arguments are captured when defer executes, not when it runs.

• Timing relative to return:

  • A return x first sets the return value, then deferred functions run, then the function actually returns.

  • With named return values, a deferred function can mutate them (common for error wrapping in recover).

errors.Is checks whether an error chain contains a specific sentinel error value, while errors.As checks whether the chain contains an error of a specific type and extracts it: both unwrap nested errors so you don't compare against the outer wrapper.

• errors.Is(err, target):

  • Use to match a known sentinel, e.g. errors.Is(err, sql.ErrNoRows).

  • Walks the wrapped chain via Unwrap() comparing for equality.

• errors.As(err, &target):

  • Use when you need a concrete/custom error type to read its fields.

  • It assigns the first matching error in the chain into the pointer you pass.

• Why they matter with wrapping: Wrapping with %w changes the outer value, so a plain == comparison would fail; these functions look through every layer.

You wrap an error by including the %w verb in fmt.Errorf, which adds context while keeping the original error retrievable in the chain via errors.Is and errors.As.

• How to wrap:

  • Use %w once per format string: fmt.Errorf("loading config: %w", err).

  • Use %v instead if you deliberately want to obscure/flatten the underlying error.

• Why it's useful:

  • Builds a readable, layered message that shows the path the error traveled.

  • Preserves the original so callers can still inspect it programmatically.

  • Retrieve the wrapped error with errors.Unwrap, or test it with errors.Is / errors.As.

• Caveat: Wrapping exposes the inner error as part of your API contract, so don't wrap implementation details you may want to hide.

A slice is a small header value of three fields (pointer, length, capacity) that describes a window into a backing array; when a slice grows past its capacity, Go allocates a new, larger array and copies the elements over.

• Slice header (three words):

  • A pointer to the first element in the underlying array.

  • len: number of elements currently accessible.

  • cap: elements from the start pointer to the end of the backing array.

• Sharing: Slicing creates a new header pointing into the same array, so writes through one slice can be seen through another.

• Growing beyond capacity:

  • append within cap reuses the existing array.

  • When len would exceed cap, Go allocates a bigger array (roughly doubling for small slices, growing more slowly for large ones), copies the data, and the slice now points to the new array.

  • After reallocation, the new slice no longer shares storage with the original, a common source of bugs.

Strings in Go are immutable read-only sequences of bytes, which makes them safe to share and cheap to copy; a []byte is the mutable counterpart, and converting between them normally copies the data.

• Why immutable:

  • A string header is just a pointer and a length; immutability lets many strings safely share the same backing bytes.

  • Safe to use as map keys and across goroutines without copying or locking.

• Relationship to []byte:

  • Both hold raw bytes; a string is read-only, a []byte is mutable.

  • string(b) and []byte(s) copy the underlying bytes, so mutating the slice can't corrupt the original string.

  • Ranging a string yields runes (decoded UTF-8 code points), while indexing yields individual bytes.

• Practical note: For heavy concatenation, build with strings.Builder or a []byte to avoid repeated allocations from immutability.

A byte is an alias for uint8 (a single raw byte), while a rune is an alias for int32 representing a Unicode code point: since Go strings are UTF-8 byte sequences, a single character can span multiple bytes but is one rune.

• byte = raw data:

  • Indexing a string (s[i]) gives a byte, not a character.

  • len(s) returns the number of bytes, not characters.

• rune = Unicode code point: A multibyte UTF-8 character (e.g. 'é' or '世') is one rune but two or three bytes.

• range decodes UTF-8 automatically:

  • A for range over a string yields the byte index and the decoded rune, advancing by the rune's byte width.

  • Invalid UTF-8 yields the replacement rune U+FFFD.

• Convert to count or index characters: []rune(s) lets you index by character; utf8.RuneCountInString(s) counts characters.

No: Go constants must be fully computable at compile time, so they can only be built from literals and other constant expressions, never from runtime values like function calls or variables.

• const is compile-time only:

  • The value must be known when compiling: const x = 2 * 60 is fine, but const t = time.Now() won't compile.

  • Only constant expressions of booleans, numbers, strings, and runes are allowed.

• Limited to basic types: You cannot make a constant slice, map, struct, or pointer: those require runtime allocation, so use var.

• Untyped constant advantage: An untyped constant has high precision and adapts to context, so the same constant can be used as int, float64, etc., without explicit conversion.

• var is the runtime counterpart: Use var when the value depends on runtime computation, can change, or needs a composite/reference type.

A type is comparable if values of it can be used with == and !=. Only comparable types may be used as map keys. Most basic types are comparable; slices, maps, and functions are not.

• Comparable types:

  • Booleans, numerics, strings, pointers, channels.

  • Interfaces (compared by dynamic type and value, but panics at runtime if the dynamic type is not comparable).

  • Structs and arrays are comparable only if all their fields/elements are comparable.

• Non-comparable types: Slices, maps, and functions: only comparable against nil, never against each other (a compile error).

• Map key requirement: Map keys must be comparable, so a map[[]byte]int won't compile, but a map[string]int or struct key will.

• Generics: The built-in comparable constraint restricts a type parameter to types usable with ==.

The empty struct struct{} is a type with no fields that occupies zero bytes of memory. It's used when you need a value purely as a signal or a set member, but the value itself carries no information.

• Zero memory footprint: All empty struct instances share the same address; storing millions of them costs essentially nothing.

• Signaling channels: chan struct{} makes intent explicit: the channel transmits an event, not data, e.g. a done/cancel signal via close(ch).

• Sets: map[string]struct{} models a set where only the key matters; the value uses no space, unlike map[string]bool.

In Go 1.22 the loop variable in a for loop is scoped per-iteration instead of being a single variable reused across iterations. This fixed the classic bug where closures and goroutines launched in a loop all captured the same variable and saw its final value.

• Old behavior (pre-1.22): One variable was shared by every iteration, so a goroutine or closure capturing it by reference observed the value at execution time, usually the last one.

• New behavior (1.22+): Each iteration gets a fresh copy of the loop variable, so captured values are what you expect.

• The bug it solved: The common for i := range items { go func(){ use(i) }() } pattern that printed the same value repeatedly; the old workaround was i := i inside the loop.

• Scope caveat: The change applies to modules whose go.mod declares Go 1.22 or later, so behavior depends on the language version.

Shadowing creates a new variable with the same name in an inner scope, temporarily hiding the outer one; redeclaration with := reuses an existing variable in the same scope as long as at least one other variable on the left is new. The key difference is scope.

• Shadowing (different scope):

  • An inner block (if, for, function body) declares a new variable of the same name; the outer one is untouched and reappears when the block ends.

  • A frequent bug source: shadowing err in an inner block so the outer err never gets the value you intended.

• Redeclaration (same scope): With :=, if at least one variable on the left is new, the already-declared ones are just assigned, not recreated.

• Detection: go vet and tools like shadow help catch accidental shadowing.

A closure is a function value that captures and references variables from its surrounding scope, keeping them alive beyond their normal lifetime. The main pitfalls involve capturing variables by reference rather than by value, especially in loops and goroutines.

• Captures by reference: The closure shares the actual variable, not a snapshot, so later mutations are visible inside it and vice versa.

• Loop variable trap: Before Go 1.22, closures in a loop all captured the same loop variable and saw its final value; pass it as an argument or shadow it (v := v) to fix.

• Goroutine timing: A goroutine reading a captured variable races with code that mutates it; synchronize or pass a copy.

• Memory retention: A long-lived closure keeps captured variables (and anything they reference) from being garbage collected.

Use a channel when you're transferring ownership of data or coordinating the flow of work between goroutines; use a sync.Mutex when you're protecting shared in-place state that multiple goroutines read and write. The "share memory by communicating" philosophy favors channels for clearer ownership, but it isn't always the simplest or fastest option.

• Channels fit data flow: Passing a value over a channel transfers ownership, so only one goroutine touches it at a time without explicit locking (pipelines, work queues, signaling).

• Mutex fits shared state: When goroutines must update the same structure in place (a cache, counter, shared map), a Mutex is simpler, lower-overhead, and easier to reason about than routing every access through a channel.

• "Share memory by communicating":

  • The idea: instead of locking shared memory, hand data between goroutines so ownership is explicit, reducing race-condition surface.

  • Trade-offs: channels add latency and complexity for fine-grained shared state, and misuse can cause deadlocks or goroutine leaks.

• Rule of thumb: The Go proverb: use channels to orchestrate goroutines, use a mutex to protect a small piece of shared state.

A goroutine leak happens when a goroutine is started but never terminates: it blocks forever (on a channel, lock, or select) so its stack and resources are never reclaimed, slowly exhausting memory.

• Common causes:

  • Sending to a channel no one will ever receive from, or receiving from one no one will send to.

  • A goroutine waiting on a channel after the consumer has gone away (e.g. caller returned early).

• Why it matters: Leaked goroutines are not garbage collected because they are still "runnable" references; the leak grows under load.

• Prevention:

  • Always give blocking goroutines a way out: pass a context.Context and select on ctx.Done().

  • Use buffered channels or ensure every send has a guaranteed receiver, and close channels to signal completion.

  • Detect leaks in tests with tools like goleak or by watching runtime.NumGoroutine().

No, Go maps are not safe for concurrent use: concurrent read/write (or write/write) triggers a runtime fatal error (concurrent map writes). You must synchronize access yourself.

• The runtime actively detects it: It is a fatal panic that can't be recovered, not a silent data race, to force you to fix it.

• Option 1: sync.RWMutex: Lock with Lock() for writes and RLock() for reads; best when reads dominate writes.

• Option 2: sync.Map: Built for concurrency, optimized for write-once/read-many or disjoint keys; loses type safety (uses interface{}) and isn't faster generally.

• Always run with -race to catch unguarded access during development.

Use a sync.WaitGroup when you only need to wait for a set of goroutines to finish and don't need their return values; use channels when you need to pass results or stream data back.

• WaitGroup is about completion, not communication:

  • Perfect for "fire off N tasks, then continue once all are done" with no data returned.

  • Simpler and cheaper than coordinating a done-channel and counting receives manually.

• Channels are about passing values: Choose them when each goroutine produces a result you must collect or aggregate.

• They combine well: A common pattern: workers send results on a channel, while a WaitGroup knows when to close() that channel.

Nothing forces the goroutine to stop: it keeps running independently of the function that spawned it. The parent returning does not cancel or wait for its children.

• Goroutines are not tied to their creator's stack frame: They share the same address space and run until they return or the whole program exits.

• Two likely outcomes:

  • It finishes its work normally and exits on its own (fine for true background tasks).

  • It blocks forever because the consumer is gone: that's a goroutine leak.

• The program-exit caveat: When main returns, the process exits immediately and kills all remaining goroutines, even mid-work.

• Fix: explicitly coordinate lifetime with a sync.WaitGroup, a channel, or context cancellation.

Call wg.Add(1) before the go statement, in the parent goroutine. Calling it inside the new goroutine creates a race where wg.Wait() can return before Add runs.

• The danger of Add inside the goroutine: The scheduler may not start the goroutine before Wait() is reached; the counter is still 0, so Wait returns and the work is skipped.

• Correct ordering: Increment synchronously, then spawn; put defer wg.Done() at the top of the goroutine.

• Counter rules: The count must never go negative or the program panics; balance every Add with a Done.

An unrecovered panic unwinds its goroutine's stack and, when it reaches the top, crashes the entire program: all other goroutines die with it. A recover() only works within the same goroutine that panicked.

• Panics don't cross goroutine boundaries: You can't catch a panic from goroutine A by recovering in goroutine B; each must guard itself.

• The blast radius is the whole process: One unrecovered panic in any goroutine terminates the program, not just that goroutine.

• Defending background goroutines:

  • Put a deferred recover() at the top of long-lived or untrusted goroutines (e.g. per-request handlers).

  • Recover to log and contain, not to silently swallow real bugs.

Fan-out spreads work across multiple goroutines reading from one channel; fan-in merges results from multiple goroutines back into a single channel. Together they parallelize a pipeline stage and then recombine its output.

• Fan-out:

  • Start N worker goroutines all receiving from the same input channel to process items concurrently.

  • Use it when work is CPU- or I/O-heavy and items are independent, to scale throughput across cores.

• Fan-in:

  • Combine multiple producer channels into one so a single consumer can read all results.

  • Often a WaitGroup tracks the producers and closes the merged channel when all are done.

• When to apply:

  • Pipelines with a slow stage: fan-out that stage to many workers, then fan-in to keep downstream simple.

  • Pair with context cancellation to stop all workers cleanly on error or timeout.

sync.Once guarantees a function runs exactly one time across all goroutines, no matter how many call it concurrently: it's the idiomatic way to do thread-safe lazy initialization (singletons, config loading).

• Single method, Do(f func()):

  • The first call invokes f; every subsequent call returns immediately without running it again.

  • If f panics, the Once is still considered "done" and won't retry.

• How it guarantees exactly-once:

  • Uses an atomic done flag for a fast path plus an internal Mutex for the slow path.

  • Concurrent callers block on the mutex until the first finishes, so all callers see completed initialization (a happens-before guarantee).

• Caveats: Don't copy a sync.Once after first use; pass by pointer or keep it as a struct field.

Go's runtime detects deadlock when every goroutine is blocked and none can make progress: it then panics with fatal error: all goroutines are asleep - deadlock!. It's a runtime safety check, not a sophisticated analysis.

• What the runtime actually checks:

  • The scheduler tracks runnable goroutines; if zero are runnable and at least one exists, it concludes nothing can ever wake them.

  • It only catches a total, global stall, not a partial deadlock where some goroutines are still running.

• Common triggers:

  • Sending to or receiving from an unbuffered channel with no other goroutine on the other side.

  • Receiving from a channel that is never written to or closed.

  • All goroutines blocked on sync.WaitGroup.Wait() or a mutex no one will release.

• Key limitation: A blocked goroutine while a timer or network poller keeps another "alive" won't trip detection, so logical hangs can still go undetected.

Use interface{} (aliased as any since Go 1.18) only when a value's type genuinely can't be known at compile time: it trades away static type safety for flexibility, so prefer concrete types or generics whenever possible.

• Legitimate uses:

  • Heterogeneous data: JSON decoding into map[string]any, or printing helpers like fmt.Println(args ...any).

  • Boundaries where types are dynamic: container/registry code before generics existed.

• Type-safety risks:

  • The compiler can't verify what's inside; you must use type assertions or switches at runtime.

  • A wrong assertion panics (or returns the zero value with the comma-ok form), turning compile errors into runtime bugs.

  • Loses self-documenting signatures and IDE help.

• Modern alternative: Generics often replace any, giving reuse plus compile-time type checking.

In Go, a type satisfies an interface simply by having the required methods: there's no implements declaration. This structural (duck) typing decouples the interface from its implementations.

• What implicit means: If a type has the right method set, it satisfies the interface automatically, with no link between them in source.

• Advantages over explicit implements:

  1. Decoupling: you can define an interface in the consumer package and have existing types (even from other libraries) satisfy it without modifying them.

  2. Smaller interfaces: it encourages defining tiny interfaces at the point of use (e.g. io.Reader), following "accept interfaces, return structs".

  3. Retroactive abstraction: you can introduce an interface over types that already exist, enabling easy mocking in tests.

• Trade-off: Intent is less obvious; a common idiom is var _ MyInterface = (*MyType)(nil) to assert satisfaction at compile time.

Go achieves polymorphism through interfaces and composition rather than class inheritance: code depends on behavior (a method set), and any type providing that behavior can be substituted.

• Interfaces provide runtime polymorphism: A function taking an io.Writer works with any type implementing Write, dispatched dynamically at call time.

• Composition replaces inheritance:

  • Struct embedding promotes the embedded type's fields and methods, reusing behavior without an "is-a" hierarchy.

  • This favors "has-a" relationships, avoiding fragile deep inheritance trees.

• Generics add compile-time polymorphism: Type parameters let one function operate over many types with static checking, complementing interfaces.

• What Go deliberately omits: No subclasses, no method overriding, no virtual hierarchy: behavior is shared via embedding and satisfied via interfaces.

A type assertion extracts one specific concrete type from an interface value, while a type switch tests against multiple possible types in one construct. Use an assertion when you expect a single type; use a switch when behavior depends on several.

• Type assertion: v, ok := x.(T):

  • Always prefer the comma-ok form: ok is false on mismatch instead of panicking.

  • The single-return form v := x.(T) panics if the type doesn't match.

• Type switch: switch v := x.(type):

  • Cleaner than chained assertions when handling many types; each case binds v to that case's type.

  • Supports a default case for unexpected types.

• Choosing between them: One expected type, use an assertion; branching over two or more types, use a switch.

Yes, conceptually it's duck typing, but enforced statically at compile time: a type satisfies an interface simply by having the right methods, with no explicit declaration of intent.

• Structural, not nominal: There is no implements keyword; if the method set matches, it satisfies the interface automatically.

• "If it has the methods, it counts": This is the duck-typing spirit: behavior, not declared lineage, determines fit.

• But statically checked: Unlike Python's runtime duck typing, mismatches are caught at compile time, so it's sometimes called "static duck typing" or structural typing.

• Practical benefit: You can define an interface in your package that an existing third-party type already satisfies, without modifying that type.

Sending to a closed channel panics; receiving from a closed channel never blocks and returns buffered values first, then the zero value with a false "ok" flag once drained.

• Send on closed channel: Immediately panics with send on closed channel; this is why only the sender side should close.

• Receive on closed channel:

  • Drains any remaining buffered values normally first.

  • After draining, returns the element type's zero value without blocking.

  • Use the two-value form to detect closure: v, ok := <-ch; ok is false when closed and empty.

• Other rules:

  • Closing an already-closed or nil channel panics.

  • A range over a channel exits cleanly when it is closed and drained.

When multiple cases are ready, select picks one at random (uniformly). This is deliberate, to prevent starvation and avoid programs relying on case order.

• Random fair choice: The runtime gathers all ready cases and selects one pseudo-randomly, so no channel is consistently favored.

• If none are ready:

  • With a default case, it runs immediately (non-blocking select).

  • Without default, it blocks until one case becomes ready.

• Practical implication: Don't assume top-to-bottom priority; if you need priority, use nested selects or a separate non-blocking check.

A select normally blocks until one of its cases is ready; adding a default case gives it something to do immediately when no channel is ready, so the operation never blocks.

• Without default, select blocks: It waits until at least one case (send or receive) can proceed.

• With default, select falls through: If no case is ready at that instant, the default branch runs instead of blocking.

• Common uses:

  • Non-blocking receive: try to read, otherwise do other work.

  • Non-blocking send: skip or drop if the buffer is full and no receiver is ready.

  • Polling a done/quit channel without stalling a loop.

• Caveat: a tight loop with default can busy-spin the CPU; pair it with a timer or backoff if looping.

Channel direction types restrict a channel to only sending (chan<- T) or only receiving (<-chan T); in function signatures they document and enforce intent so the compiler catches misuse.

• The two directional forms:

  • chan<- T: send-only, the arrow points into the channel.

  • <-chan T: receive-only, the arrow points out of the channel.

• Why they help:

  • Self-documenting: a parameter type tells callers whether a function produces or consumes.

  • Compile-time safety: sending on a <-chan or closing a receive-only channel is a compile error.

• Implicit conversion: A bidirectional chan T converts automatically to a directional type when passed, but not the reverse.

By convention the sender (the goroutine that produces values) closes the channel, never the receiver, because only the sender knows when no more values will be sent.

• Closing signals completion: A closed channel lets receivers drain remaining values, then a range loop ends or the comma-ok form returns ok == false.

• Why receivers must not close:

  • Sending on a closed channel panics, so a receiver closing could crash a still-active sender.

  • Closing an already-closed channel also panics.

  • Receivers don't know whether other senders are still running.

• Multiple senders case: No single sender should close; coordinate with a sync.WaitGroup and have a separate goroutine close once all senders finish.

• You don't always need to close: closing is only required to signal receivers, not to free the channel (GC handles that).

Go Modules pin exact dependency versions in go.mod and record cryptographic checksums in go.sum, so every build resolves the same versions and verifies their contents are unchanged.

• Semantic versioning + MVS:

  • Dependencies are tagged vMAJOR.MINOR.PATCH; Go uses Minimal Version Selection, choosing the lowest version that satisfies all requirements.

  • This makes resolution deterministic, not "latest wins."

• go.mod: Declares the module path, Go version, and the required dependency versions.

• go.sum's role:

  • Stores expected hashes of each module's content and its go.mod.

  • On download Go re-hashes and compares; a mismatch fails the build, protecting against tampering or a mutated tag.

  • It is for verification, not version selection; commit it to source control.

• Reproducibility: Same go.mod + go.sum yields identical dependency trees anywhere, aided by the module cache and checksum database (GOSUMDB).

Workspaces (go.work, added in Go 1.18) let you develop several local modules together as one unit, so cross-module changes are picked up immediately without editing each go.mod.

• Replaces the replace-directive hack:

  • Before workspaces you used replace directives in go.mod to point at local copies, which risked being committed accidentally.

  • go.work lives outside the modules and is typically not committed, keeping go.mod files clean.

• Key benefits:

  • Edit a library module and its consumer in the same repo/checkout and see changes instantly.

  • The use directive lists which local module directories participate.

  • Build and test across modules with normal commands.

• Setup: go work init ./moduleA ./moduleB creates the file; go work use adds more.

Table-driven tests define test cases as a slice of structs (inputs plus expected outputs) and loop over them running the same assertions, so one test function covers many scenarios with minimal duplication.

• Structure:

  • A slice of anonymous structs, each holding a name, inputs, and expected result.

  • Run each case with t.Run(tc.name, ...) to get a named subtest.

• Why preferred:

  • Adding a case is one line, not a new function: low friction to grow coverage.

  • Subtests report exactly which case failed and can be run individually with -run.

  • Consistent assertion logic avoids copy-paste divergence.

  • Easy to parallelize per case with t.Parallel().

A value receiver operates on a copy of the struct, while a pointer receiver operates on the original: choose based on whether you must mutate the receiver, the cost of copying, and consistency of the method set.

• Value receiver copies the struct:

  • Each call copies all fields, so mutations don't persist and large structs cost CPU/memory to copy.

  • Safe and simple for small, immutable-style values (e.g. small structs, basic wrappers).

• Pointer receiver shares the original:

  • Lets the method mutate the struct in place and avoids copying large structs.

  • Required if the struct holds a sync.Mutex or other non-copyable field.

• Method set and interface satisfaction: Pointer-receiver methods are only in the method set of *T, so a value may not satisfy an interface that needs them.

• Rule of thumb: be consistent: If any method needs a pointer receiver, use pointer receivers for all methods on that type to avoid a mixed, confusing method set.

The context package carries cancellation signals, deadlines, and request-scoped values across API and goroutine boundaries so work can be stopped cleanly when it's no longer needed.

• Propagating cancellation:

  • A context.Context exposes a Done() channel that closes when cancelled; downstream functions select on it to stop early.

  • Created with context.WithCancel, WithTimeout, or WithDeadline; always defer cancel() to release resources.

• Convention:

  • Pass it as the first parameter, named ctx; never store it in a struct.

  • Cancellation is tree-shaped: cancelling a parent cancels all children.

• Request-scoped values: context.WithValue carries data like request IDs, but use sparingly (not for optional function parameters).

• Why it matters: Lets servers abort downstream DB queries and HTTP calls when a client disconnects or a deadline passes, preventing wasted work and leaks.

Passing by value copies the data while passing a pointer copies only an address: pointers avoid large copies and allow mutation, but can push data to the heap and add indirection, so the choice trades copy cost against allocation and GC pressure.

• Passing by value:

  • Copies the whole struct: cheap for small types and keeps data on the stack, helping cache locality and avoiding GC work.

  • Expensive for large structs because every call duplicates all fields.

• Passing by pointer:

  • Copies only the pointer regardless of struct size, and allows the callee to mutate the original.

  • May cause escape analysis to allocate the value on the heap, adding GC pressure, plus a dereference cost.

• Practical guidance:

  • Small values (a few words): pass by value; large structs or when mutation is needed: pass by pointer.

  • Don't micro-optimize blindly: profile, since stack-allocated values can beat pointers despite the copy.

Functional options pass behavior-configuring functions for a flexible, backward-compatible API; a config struct passes one struct of fields for simplicity. Options shine for large, evolving, mostly-optional configuration; a config struct is simpler and clearer when settings are few and stable.

• Functional Options:

  • Each option is a function like func(*Server) applied in a variadic constructor; callers set only what they need.

  • Pros: easy to add new options without breaking callers, sensible defaults, self-documenting call sites.

  • Cons: more boilerplate and indirection; harder to discover all options at a glance.

• Config struct:

  • A single struct of fields passed to the constructor.

  • Pros: simple, explicit, all fields visible; trivial to read and zero-value friendly.

  • Cons: distinguishing "unset" from zero value is awkward; growing it can feel cluttered.

• Choosing: Few stable settings: config struct. Many optional, evolving settings or a public library API: functional options.

In Go, dependency injection is usually just passing dependencies explicitly (as interface values) into constructors or functions, wired together in main: no framework needed because interfaces and plain functions do the job.

• Depend on interfaces, not concretes: A type declares what it needs as an interface, so any implementation (real or mock) can be supplied.

• Constructor injection: Pass dependencies into a NewX(...) function and store them on the struct; avoids global state.

• Wire it up at the composition root: Construct concrete implementations in main and pass them down; the rest of the code stays decoupled.

• Testability is the payoff:

  • Tests inject fakes/mocks satisfying the same interface, no framework required.

  • For large graphs, code generators like google/wire can automate wiring while staying compile-time and lightweight.

Goroutines are lightweight user-space tasks multiplexed onto a small pool of OS threads by the Go runtime, so they are far cheaper to create, schedule, and stack than OS threads.

• Memory footprint:

  • Goroutine starts with a tiny ~2KB stack that grows/shrinks on demand.

  • An OS thread reserves a large fixed stack (often 1-8MB), so millions of goroutines are feasible where threads aren't.

• Startup and switching cost:

  • Creating a goroutine is a cheap runtime operation; spawning an OS thread is a syscall.

  • Context switches between goroutines happen in user space (no kernel trap), so they're cheaper than thread switches.

• Management:

  • The Go scheduler (G-M-P) multiplexes many goroutines onto few threads and handles blocking transparently.

  • OS threads are scheduled preemptively by the kernel and are heavier to manage directly.