Question 1

What problem was Go designed to solve, and what are its core design values?

Accepted Answer

Go was created at Google to fix slow builds, unwieldy dependency management, and the difficulty of reasoning about large concurrent codebases in languages like C++. Its core values are simplicity, fast compilation, built-in concurrency, and automatic memory management.

Question 2

How does Go differ from Java, Python, and Node.js for building backend services?

Accepted Answer

Go compiles to a single static binary with no VM or interpreter to ship (unlike the JVM or Node's V8), and it schedules many goroutines across OS threads instead of relying on a single-threaded event loop or heavyweight OS threads. It also makes error handling explicit through returned values rather than exceptions.

Question 3

What's the difference between a Go package and a Go module?

Accepted Answer

A package is a directory of .go files compiled together that share a namespace, declared with `package foo`. A module is a versioned collection of one or more packages defined by a go.mod file, and is the unit Go's dependency management works with.

Question 4

What do go.mod and go.sum do?

Accepted Answer

go.mod declares the module's own path, the Go version it targets, and the versions of its dependencies. go.sum records cryptographic checksums for every module version in the build, so builds are reproducible and dependencies can't be silently tampered with.

Question 5

When should you use `var` instead of `:=` in Go?

Accepted Answer

Use `:=` for concise local declarations where the initial value makes the type obvious; use `var` when declaring at package scope, when you need an explicit type that differs from what would be inferred, or when you want the variable to start at its zero value without an explicit initializer.

Question 6

What is `iota` and how is it used to define constants?

Accepted Answer

`iota` is a predeclared identifier that resets to 0 at the start of each `const` block and increments by one for every subsequent constant specification in that block, making it the idiomatic way to define enumerated constants.

Question 7

Why does Go give every type a zero value, and what are some examples?

Accepted Answer

Go initializes every declared variable to a well-defined zero value instead of leaving it uninitialized, eliminating a whole class of undefined-behavior bugs. Examples: 0 for numeric types, "" for strings, false for bool, and nil for pointers, slices, maps, channels, functions, and interfaces.

Question 8

What is a pointer in Go, and why doesn't Go allow pointer arithmetic?

Accepted Answer

A pointer holds the memory address of a value, declared as `*T` and obtained with `&`. Go deliberately omits pointer arithmetic (unlike C) because letting code compute arbitrary offsets would undermine memory safety and make it far harder for the garbage collector to track and move references.

Question 9

When should a function take `*T` instead of `T`?

Accepted Answer

Take `*T` when the function needs to mutate the caller's value, when `T` is large enough that copying it is wasteful, or when `nil` needs to be a meaningful "absent" state. Otherwise, pass `T` by value — it's simpler and avoids accidental aliasing.

Question 10

What is struct embedding, and how is it different from typical composition?

Accepted Answer

Embedding places one struct or interface inside another without giving it a field name; the outer struct then promotes the embedded type's fields and methods into its own method set. It's still composition under the hood — Go has no inheritance — but the promotion gives call-site syntax that looks like subtyping.

Question 11

How do you decide between a value receiver and a pointer receiver for a method?

Accepted Answer

Use a pointer receiver when the method needs to mutate the receiver or the type is large or expensive to copy; use a value receiver for small, read-only types where copying is cheap.

Question 12

Why is it recommended to keep receiver types consistent across all methods of a struct?

Accepted Answer

Mixing value and pointer receivers on the same type is legal but risky: since `T`'s method set excludes pointer-receiver methods, a type with even one pointer-receiver method should generally use pointer receivers everywhere so `*T` reliably satisfies the interfaces you expect and callers don't hit inconsistent mutation semantics.

Question 13

What are type parameters and constraints in Go generics?

Accepted Answer

Type parameters, introduced in Go 1.18, let a function or type be written once and used with multiple types, declared in square brackets like `func Max[T constraints.Ordered](a, b T) T`. A constraint is an interface that restricts which types can be substituted, specifying either required methods or an allowed set of underlying types.

Question 14

When should you avoid reaching for generics in Go?

Accepted Answer

Avoid generics when a plain interface with a couple of methods already expresses the abstraction clearly, when there's realistically only one concrete type in use, or when the generic version reads harder than a small amount of duplicated code — Go's own proverb is that a little copying is better than a little dependency.

Question 15

In what order do multiple `defer` statements run, and when are their arguments evaluated?

Accepted Answer

Deferred calls run in LIFO (last-in, first-out) order when the surrounding function returns, but the arguments to a deferred call are evaluated immediately when the `defer` statement executes — not later when the call actually runs.

Question 16

What's the risk of using `defer` inside a long-running loop to close per-iteration resources?

Accepted Answer

A deferred call doesn't run until the enclosing function returns, so deferring a `Close()` inside a loop that runs many iterations keeps every one of those resources open until the function finally exits — which can exhaust file descriptors, database connections, or memory.

Question 17

When is it appropriate to `panic` in Go instead of returning an error?

Accepted Answer

Panic is reserved for programmer errors and truly unrecoverable situations — an invariant that should never be violated, or a fatal failure during package initialization — while ordinary, expected failures like invalid input or a failed network call should be returned as a normal `error` value.

Question 18

Why doesn't `recover()` catch a panic happening in a different goroutine?

Accepted Answer

`recover` only stops a panic unwinding the same goroutine's call stack where the deferred function calling it lives. Each goroutine has its own independent stack and defer chain, so a panic in one goroutine that isn't recovered there crashes the entire program, no matter what defers exist elsewhere.

Question 19

When does `init()` run, and why can overusing it be an anti-pattern?

Accepted Answer

Each package's `init()` functions run automatically after that package's top-level variables are initialized and before `main()` runs, with imported packages' `init`s running first. Overusing `init()` for business logic makes control flow implicit and hard to test, since it runs unconditionally the moment the package is imported.

Question 20

What's the difference between a type assertion, a type switch, and a type conversion in Go?

Accepted Answer

A type conversion (`T(x)`) changes a value's static type between compatible concrete types and is checked entirely at compile time. A type assertion (`x.(T)`) extracts the concrete value stored inside an interface at runtime, and a type switch (`switch v := x.(type)`) branches over several possible concrete types an interface might hold.

Preparing for a Go interview?