Go Programming Interview Questions

Go is compiled -- `go build` produces a single, statically-linked native executable with no external runtime dependency required on the target machine, which makes deployment simple (copy one binary) compared to languages requiring a separate installed runtime/interpreter.

`:=` (short variable declaration) declares and infers the type from the assigned value in one step, only usable inside a function body; `var name Type = value` explicitly declares the type (or lets it be inferred) and is usable at package level too -- `:=` is the more common shorthand inside functions.

count := 5          // short declaration
var count int = 5   // explicit var

Go deliberately omits exception-based error handling in favor of returning an explicit `error` value as an additional return value from any function that can fail -- callers must explicitly check `if err != nil` rather than errors silently propagating up an invisible exception path.

`gofmt` automatically reformats Go source code to the language's one canonical style -- Go treats formatting as essentially non-negotiable and tool-enforced, eliminating the code-style debates and inconsistency common in languages with multiple accepted formatting conventions.

Go's designers deliberately chose to enforce this strictly to prevent dead code and accidental leftover imports/variables from accumulating silently -- forcing developers to either use or explicitly remove them keeps the codebase clean by construction, at the cost of occasionally being annoying during quick prototyping.

Common mistake: Leaving an unused variable or import in Go code and expecting it to just be a warning, when it actually fails compilation.

Every type has a well-defined default 'zero value' (0 for numbers, "" for strings, `false` for booleans, `nil` for pointers/slices/maps/interfaces) -- a variable declared with `var x int` is never left as truly uninitialized/garbage memory, it's immediately usable as 0, which eliminates a whole class of uninitialized-variable bugs common in some other languages.

In Go, every variable's type is fixed at compile time and checked by the compiler before the program ever runs -- a type mismatch is caught immediately as a compile error, rather than potentially surfacing only at runtime the way it would in a dynamically-typed language.

Capitalization determines visibility -- an identifier starting with an uppercase letter (`ProcessOrder`) is exported and accessible from other packages; a lowercase-starting identifier (`processOrder`) is package-private, only accessible within the same package. No separate `public`/`private` keyword exists.

`const` declares a compile-time constant value that can never be reassigned and (for numeric/string constants) is evaluated at compile time -- unlike `var`, which declares a normal, mutable runtime variable, even if you never actually reassign it.

Go deliberately omits many features other languages have (classical inheritance, exceptions, generics were notably absent for years, operator overloading) in favor of a small, easy-to-learn core language -- a deliberate design tradeoff favoring readability and consistency across a large codebase/team over expressive power for any individual piece of code.

A Go function can declare more than one return type (`func divide(a, b int) (int, error)`), most commonly used to return both a result and an error value together -- the idiomatic pattern is `result, err := divide(a, b); if err != nil { ... }`.

func divide(a, b int) (int, error) {
  if b == 0 {
    return 0, errors.New("division by zero")
  }
  return a / b, nil
}

An array has a fixed size baked into its type (`[5]int`); a slice is a flexible, resizable view over an underlying array, with its own length and capacity that can grow -- slices are what's actually used in idiomatic Go code for nearly all list-like data, with arrays used only rarely for fixed-size cases.

Length is how many elements the slice currently contains; capacity is how many elements the underlying array CAN hold before a new, larger array must be allocated -- appending beyond current capacity triggers Go to allocate a new, larger underlying array and copy the existing elements over.

Two slices can share the same underlying array if one was created by slicing another (`s2 := s1[1:3]`) -- modifying an element through one slice can be visible through the other, since they point at the same backing storage, until an append operation forces a new, separately-allocated array.

Common mistake: Assuming two slices derived from the same underlying array are fully independent, then being surprised when mutating one affects the other.

A map is Go's built-in hash-table-backed key-value collection -- reading a nonexistent key returns the value type's zero value (not an error/exception), so `m["missing"]` on a `map[string]int` returns `0`, not a crash. The two-value form (`v, ok := m["key"]`) is used to distinguish 'key missing' from 'key present with a zero value.'

v, ok := m["missing"]
if !ok {
  fmt.Println("key not found")
}

Go deliberately randomizes map iteration order specifically to prevent developers from accidentally relying on an order that was never actually guaranteed -- code that needs a specific order must sort keys explicitly rather than depending on incidental map iteration behavior.

A variadic parameter lets the function accept any number of arguments of that type, collected into a slice inside the function -- to pass an EXISTING slice's elements as variadic arguments, you must spread it explicitly with `...` (`sum(myNums...)`), rather than passing the slice directly.

A closure is a function value that references variables from outside its own body -- Go closures capture those variables BY REFERENCE, meaning if the enclosing variable changes after the closure is created, the closure sees the updated value, not a snapshot from creation time.

Every argument is copied when passed -- for a large struct, this means copying its entire contents, which can be a real performance cost; passing a POINTER to the struct instead avoids the copy and also lets the function actually mutate the caller's original struct if needed.

`defer` schedules a function call to run right before the enclosing function returns, regardless of how it returns (normal return or panic) -- extremely commonly used for guaranteed cleanup, like `defer file.Close()` immediately after successfully opening a file.

f, err := os.Open(path)
if err != nil {
  return err
}
defer f.Close()

A struct is a composite type grouping named fields together -- Go has no classes at all; behavior is attached to structs via separately-defined methods (functions with a receiver), and there's no inheritance, only composition (embedding one struct inside another).

A value receiver (`func (u User) Greet()`) operates on a COPY of the struct, so it can't modify the original; a pointer receiver (`func (u *User) SetName(name string)`) operates on the original struct via its address, letting the method actually mutate the caller's struct.

Common mistake: Using a value receiver for a method meant to mutate the struct, silently modifying only a local copy that the caller never sees.

Go uses structural (implicit) interface satisfaction -- any type that happens to implement all the methods an interface requires automatically satisfies that interface, with no explicit `implements` keyword or declaration needed -- a type can satisfy an interface without even knowing that interface exists.

Since it requires zero methods, EVERY type automatically satisfies it -- it's Go's way of representing 'a value of any type,' historically used before generics for things like a generic container, though modern Go generics now offer a more type-safe alternative for many such cases.

`if err != nil { return err }` (or wrapped with more context) repeated after every fallible call -- it looks repetitive because errors are explicit, ordinary values checked at each step, a deliberate design choice trading conciseness for making every possible failure point visible directly in the code's control flow.

`%w` wraps the original error inside a new one while preserving a reference to it, letting callers later use `errors.Is`/`errors.As` to check whether a specific underlying error occurred, even through several layers of wrapping -- preserves diagnostic context without losing the ability to programmatically inspect the root cause.

A returned `error` represents an expected, recoverable failure mode that calling code is meant to handle; `panic` represents an unrecoverable programmer error or truly exceptional condition, unwinding the call stack -- idiomatic Go reserves `panic` for genuinely exceptional situations, not routine error handling, which should use returned errors instead.

Common mistake: Using panic for routine, expected error conditions instead of returning an error value, going against Go's idiomatic error-handling convention.

`recover()` stops a panicking goroutine's unwinding and returns the value passed to `panic` -- it only has an effect when called directly inside a `deferred` function; calling it anywhere else does nothing.

Embedding a struct (or interface) inside another struct with no field name promotes its fields and methods to be accessible directly on the outer struct -- a form of composition that achieves some of what inheritance provides in other languages, without an actual is-a inheritance relationship or method-overriding polymorphism.

Small interfaces are easier for many different concrete types to satisfy naturally, and easier to mock/fake in tests -- Go's standard library convention favors small, composable interfaces ('accept interfaces, return structs') over large ones that force implementers to provide many methods they may not all need.

A goroutine is a lightweight, Go-runtime-managed concurrent function execution -- much cheaper to create than an OS thread (goroutines start with a small, growable stack and the Go runtime multiplexes many goroutines onto a smaller number of actual OS threads), so a program can comfortably run thousands of goroutines.

go doSomething()  // starts a new goroutine

A typed conduit for goroutines to send and receive values safely, providing built-in synchronization -- the idiomatic Go concurrency philosophy is often summarized as 'don't communicate by sharing memory; share memory by communicating,' with channels being the primary mechanism for that communication.

ch := make(chan int)
go func() { ch <- 42 }()
value := <-ch

An unbuffered channel (`make(chan int)`) blocks the sender until a receiver is ready to receive (synchronous handoff); a buffered channel (`make(chan int, 5)`) lets the sender proceed without blocking until the buffer is full, decoupling the timing of sends and receives somewhat.

The sending goroutine blocks forever, waiting for a receiver that never comes -- if this is the ONLY thing keeping the program running, Go's runtime can detect this specific 'all goroutines are asleep, deadlock' situation and crash the program with a deadlock error rather than hanging silently forever.

Common mistake: Sending on an unbuffered channel with no corresponding receiver ready, causing the goroutine (and potentially the whole program) to deadlock.

It lets a goroutine wait for a collection of OTHER goroutines to finish before proceeding -- `Add(n)` registers how many to wait for, each goroutine calls `Done()` when finished, and `Wait()` blocks until the count reaches zero, a common pattern for 'launch N concurrent tasks, then wait for all of them.'

var wg sync.WaitGroup
for _, url := range urls {
  wg.Add(1)
  go func(u string) {
    defer wg.Done()
    fetch(u)
  }(url)
}
wg.Wait()

A race condition occurs when multiple goroutines access shared memory concurrently, with at least one write, without proper synchronization -- Go's built-in `-race` flag (`go test -race`, `go run -race`) instruments the program to detect and report actual data races encountered during execution.

In older Go versions, the loop variable was reused across iterations (one shared variable), so a closure capturing it by reference could see the FINAL value once the loop finished, not the value at the time the goroutine was launched -- Go 1.22 changed loop variable semantics to give each iteration its own variable, fixing this specific footgun, but it remains an important thing to understand for reading older code.

It lets a goroutine wait on multiple channel operations simultaneously, proceeding with whichever one becomes ready first -- useful for patterns like waiting on either a result channel or a timeout/cancellation channel, whichever happens first.

It carries cancellation signals, deadlines, and request-scoped values across API boundaries and between goroutines -- e.g. a canceled HTTP request's context propagates down through every downstream operation started on its behalf, letting them stop work early instead of continuing pointlessly after the client has already disconnected.

Goroutines are cheap but not free -- excessive, unbounded goroutine creation (e.g. one per item in an unbounded input stream) can still exhaust memory or overwhelm downstream resources (like a database connection pool); a worker-pool pattern with a bounded number of goroutines is often more appropriate than unlimited concurrent goroutines.

A module defines a project's root import path and tracks its external dependencies and their exact versions -- `go.mod` is the manifest file (similar in role to `package.json`), and `go.sum` records cryptographic checksums of dependencies for reproducible, verifiable builds.

Go's built-in testing framework auto-discovers any function matching that naming pattern in a file ending `_test.go` as a test case -- no separate test framework installation is required; `go test` runs them directly using the standard library's `testing` package.

func TestAdd(t *testing.T) {
  if Add(2, 3) != 5 {
    t.Errorf("expected 5")
  }
}

Defining a slice/table of input-and-expected-output test cases, then looping over them within a single test function -- a Go-idiomatic way to cover many similar cases without duplicating near-identical test function bodies for each one.

`go vet` performs additional static analysis beyond basic type checking, catching suspicious constructs that compile fine but are very likely bugs (like a `Printf` format string that doesn't match its arguments) -- a complementary safety net the compiler itself doesn't provide.

A `main` package with a `func main()`, commonly placed under a `cmd/<binary-name>/main.go` path for projects with multiple executables, or directly at the repo root for a single-binary project -- `package main` is what tells `go build` this package produces a runnable executable rather than an importable library.

The `net/http` package provides a genuinely capable, production-usable HTTP server and client out of the box -- many Go web services are built directly on it (or a thin routing layer over it) rather than requiring a large external framework, reflecting Go's broader philosophy of a capable standard library reducing dependency needs.

It measures a function's performance (time per operation) directly using the standard toolchain (`go test -bench=.`), without needing an external benchmarking library -- consistent with Go's philosophy of batteries-included tooling for common development needs.

Go's cultural norm (and a capable standard library) tends to favor fewer, more deliberate dependencies -- each added dependency is a piece of code you don't control that could introduce a vulnerability, a breaking change, or added attack surface, so many idiomatic Go projects lean on the standard library and a small number of well-vetted packages rather than many small ones.

It adds any missing dependencies actually used in the code and removes unused ones from `go.mod`/`go.sum` -- keeps the module's declared dependencies accurate and minimal, catching the case where a dependency was removed from code but its entry was never cleaned up.

Go's compiler was specifically designed for speed, and Go's package dependency model avoids some of the compilation-time costs (like C++'s header-inclusion model) that slow down large builds in other languages -- fast, reliable builds directly translate to faster CI feedback loops and a better day-to-day developer experience on large projects.