Go Developer interview prep

Short answer: An interface names a behavior through method signatures. Any type with the required method set implements it implicitly. A function accepting that interface can work with multiple concrete types, and a method call uses the implementation belonging to the stored dynamic value.

type Speaker interface{ Speak() string }
type Cat struct{}
type Dog struct{}
func (Cat) Speak() string { return "meow" }
func (Dog) Speak() string { return "woof" }

func announce(s Speaker) {
    fmt.Println(s.Speak())
}

func main() {
    announce(Cat{}) // meow
    announce(Dog{}) // woof
}

In depth: The signatures must match; no implements declaration is needed. Interfaces are checked statically at assignment/call sites, while calls through interface values can dispatch dynamically. Prefer small interfaces describing what the consumer needs.

Embedding is a separate tool: it composes one type inside another and can promote its methods. It does not make the outer type a subtype of the embedded type or introduce class-style method overriding. Package-level encapsulation is controlled by exported names, which begin with an uppercase Unicode letter.

Watch out: “Go has no class inheritance” does not mean “Go has no dynamic dispatch.” Interface calls provide it. Embedding alone does not make a method on an inner value dispatch to a same-named outer method.

Sources: Go reference 1, Go reference 2.

Short answer: Return an error for failures callers are expected to handle, such as invalid input, missing files, timeouts, or unavailable dependencies. Reserve panic for programmer errors, violated invariants, or a documented API that intentionally panics.

Examples: A parser returns an error for malformed user input. A MustParse helper may intentionally panic for a fixed developer-controlled value during initialization. The runtime also panics for some invalid operations, such as an out-of-range index.

A panic unwinds deferred calls in the current goroutine. If it reaches that goroutine's top without recovery, the process terminates. Recovery at a deliberate boundary can contain a failure—an HTTP server may recover a handler panic—but it must not pretend the failed operation succeeded or assume shared state is intact.

Do not equate severity with mechanism: An ordinary returned error can still be fatal to an application. A panic does not prove that every piece of process state is corrupt. Choose the API contract and recovery boundary based on what can safely continue; do not add blanket recover to every goroutine or use panic for routine validation.

Further reading: Go documentation · Go documentation

Short answer: A goroutine is a concurrent execution managed by the Go runtime. An OS thread is scheduled by the operating system. Go multiplexes many goroutines over OS threads, and each goroutine has a stack that can grow and shrink.

In depth:

1. Start one with go f(). The caller continues without waiting; add an explicit synchronization point when completion matters.
2. Goroutine stacks start small (historically around 2 KiB in the standard runtime). The initial size and growth policy are implementation details. OS-thread stack sizes depend on the platform and configuration.
3. When a goroutine blocks on a channel or supported network I/O, the runtime can run another goroutine on the available thread. Blocking system calls and cgo can require additional OS threads.
4. Runtime scheduling is generally cheaper than creating and managing a dedicated OS thread per task. Exact costs and safe counts depend on the workload; goroutines still consume memory and retain referenced objects.

done := make(chan struct{})
go func() {
    fmt.Println("work")
    close(done)
}()
<-done // wait for this goroutine's completion

Watch out: Concurrency means tasks can make progress independently; parallelism means they run simultaneously. Goroutines provide concurrency, while available CPUs and GOMAXPROCS constrain parallel Go execution. Returning from main ends the program without waiting for other goroutines.

Sources: Go reference 1, Go reference 2.

Short answer: Mutex allows one critical section at a time. RWMutex permits concurrent readers through RLock, while Lock excludes both readers and other writers. Start with the simpler lock; choose RWMutex when measurement shows that parallel reads help.

How to reason about it: All accesses to the protected invariant must use the same lock. Under RLock, only read the shared data: updating an LRU position or lazily initializing a field is a write. An RWMutex cannot be upgraded from RLock to Lock, and recursive read locking can deadlock when a writer is waiting.

A pending writer prevents new readers from acquiring the lock until that writer has acquired and released it. This avoids one source of writer starvation; it does not promise scheduling fairness or a maximum wait.

Example: A configuration lookup that performs substantial read-only work may benefit from concurrent readers. A tiny counter increment often does not. There is no universal read/write ratio or performance ranking—benchmark representative contention.

Further reading: Go documentation

Short answer: GOMAXPROCS limits how many operating-system threads can execute Go code simultaneously. It does not limit the number of goroutines, blocked syscall threads, or concurrent I/O operations.

Default by version: Before Go 1.25, the default was the logical CPU count available at startup. Go 1.25+ can also consider CPU affinity and, on Linux, cgroup CPU bandwidth limits, and periodically update the default. Compatibility settings associated with older module language versions can retain the old behavior.

The current runtime normally uses the minimum of CPU count, affinity count, and rounded-up cgroup quota, but does not go below two solely because of the quota. This calculation is an implementation detail: do not equate GOMAXPROCS with Kubernetes CPU requests or simply with runtime.NumCPU().

n := runtime.GOMAXPROCS(0) // query without changing it
fmt.Println(n)

Setting the environment variable or calling runtime.GOMAXPROCS(n) with a positive value overrides automatic updates. Go 1.25+ provides runtime.SetDefaultGOMAXPROCS() to restore the runtime default and updates. Check the toolchain, module version, and GODEBUG settings before diagnosing container throttling.

Further reading: Go documentation · Go documentation