Go interview questions

What a strong answer covers

• Explain that `var x int` declares a variable `x` of type `int` and initializes it to its zero value (0 for int).
• Explain that `x := 10` is a short variable declaration, which declares and initializes `x` to 10, inferring its type as `int`.
• State that `var` can be used at package or function level, while `:=` can only be used inside functions.
• Discuss use cases: `var` for package-level variables, explicit zero-value initialization, or when the type is not immediately obvious from the value; `:=` for concise local variable declarations where the type is clear.

Where people lose the point

• ×Incorrectly stating that `:=` can be used at the package level.
• ×Failing to mention the zero-value initialization for `var` declarations.
• ×Confusing type inference with dynamic typing.

What a strong answer covers

• Define an array as a fixed-size sequence of elements of a single type, whose size is part of its type.
• Define a slice as a dynamically-sized, flexible view into an underlying array, consisting of a pointer, length, and capacity.
• Explain that arrays are value types (copied when passed), while slices are reference types (share underlying data).
• Discuss use cases: Arrays for fixed-size collections where size is known at compile time (e.g., matrix math, internal buffer); Slices for most dynamic collections where size can change (e.g., lists of items, function arguments).

Where people lose the point

• ×Incorrectly stating that arrays are dynamic or slices are fixed-size.
• ×Failing to mention that slices are built on top of arrays.
• ×Not explaining the value vs. reference semantics difference.

What a strong answer covers

• Explain that Go functions typically return two values: the result and an `error` type.
• Describe the pattern of checking `if err != nil` immediately after a function call that might return an error.
• Mention that `error` is an interface, and custom errors can be created by implementing its `Error() string` method.
• Provide a simple code example demonstrating a function returning an error and its handling by the caller.

Where people lose the point

• ×Suggesting the use of `try-catch` blocks, which do not exist in Go.
• ×Ignoring errors or not checking for `nil` error values.
• ×Failing to explain that `error` is an interface.

What a strong answer covers

• Define struct embedding as including a struct type directly within another struct without a field name, promoting fields and methods of the embedded type to the outer struct.
• Explain that it provides a way to compose types and reuse behavior, similar to composition over inheritance.
• Highlight the key difference from inheritance: embedding is composition, not a 'is-a' relationship. The embedded type's methods are promoted, but there's no polymorphism based on a class hierarchy.
• Mention that the embedded type's fields and methods can be accessed directly or via the embedded field name (e.g., `outer.Field` or `outer.Inner.Field`).

Where people lose the point

• ×Calling struct embedding 'inheritance' or implying a class hierarchy.
• ×Not explaining that methods of the embedded type are also promoted.
• ×Failing to mention that the embedded type can still be accessed by its type name.

What a strong answer covers

• Define goroutines as lightweight, independently executing functions managed by the Go runtime scheduler.
• Define channels as typed conduits used for communication and synchronization between goroutines, adhering to the 'share memory by communicating' principle.
• Explain that goroutines perform concurrent work, and channels provide a safe, synchronized way for them to exchange data or signal events.
• Provide a simple example: one goroutine sends a message on a channel, and the main goroutine receives it, demonstrating communication.

Where people lose the point

• ×Confusing goroutines with OS threads or implying manual thread management.
• ×Suggesting direct memory sharing between goroutines without synchronization.
• ×Providing an example that doesn't correctly use channels for communication.

What a strong answer covers

• Explain unbuffered channels: they have a capacity of zero, requiring both a sender and a receiver to be ready simultaneously for communication to occur (synchronous).
• Explain buffered channels: they have a specified capacity, allowing a sender to send values up to the buffer size without blocking, even if no receiver is ready (asynchronous up to buffer size).
• Discuss use cases for unbuffered: strict synchronization, hand-off of a single event, ensuring an operation completes before proceeding.
• Discuss use cases for buffered: decoupling sender/receiver, rate limiting, producer-consumer patterns where some backlog is acceptable.

Where people lose the point

• ×Incorrectly stating that unbuffered channels have a default buffer size.
• ×Confusing the blocking behavior of send/receive operations on each type.
• ×Failing to provide clear scenarios for when to use each type.

What a strong answer covers

• Define polymorphism as the ability of different types to be treated as instances of a common type, allowing functions to operate on a variety of data types.
• Explain that Go achieves polymorphism through interfaces, which define a set of methods that a type must implement.
• Describe implicit interface satisfaction: a type satisfies an interface simply by implementing all its methods, without any explicit declaration (e.g., `implements` keyword).
• Illustrate how this allows functions to accept interface types, and any concrete type satisfying that interface can be passed, enabling flexible and decoupled code.

Where people lose the point

• ×Suggesting that Go uses class inheritance for polymorphism.
• ×Implying that an `implements` keyword or explicit declaration is needed for interface satisfaction.
• ×Failing to connect implicit satisfaction to the benefits of flexible code design.

What a strong answer covers

• Explain that a value receiver operates on a copy of the struct, so any modifications within the method do not affect the original struct.
• Explain that a pointer receiver operates on the original struct instance, allowing the method to modify the struct's fields.
• Discuss use cases for value receivers: when the method only reads the struct's state, when the struct is small and copying is inexpensive, or when you want to ensure the original struct remains unchanged.
• Discuss use cases for pointer receivers: when the method needs to modify the struct's state, when the struct is large (to avoid expensive copies), or when the method needs to implement an interface that requires a pointer receiver (e.g., `json.Unmarshaler`).

Where people lose the point

• ×Incorrectly stating that value receivers can modify the original struct.
• ×Failing to consider performance implications for large structs.
• ×Not mentioning the impact on interface satisfaction (some interfaces require pointer receivers).

What a strong answer covers

• Define `defer` as a statement that schedules a function call to be executed just before the surrounding function returns.
• Explain that deferred calls are pushed onto a stack, and executed in Last-In, First-Out (LIFO) order.
• Highlight its primary purpose: ensuring resources are properly cleaned up (e.g., closing files, unlocking mutexes) regardless of how the function exits (normal return, panic).
• Provide a common use case, such as `defer file.Close()` after `os.Open()` or `defer mu.Unlock()` after `mu.Lock()`.

Where people lose the point

• ×Incorrectly stating that `defer` executes immediately or at the beginning of the function.
• ×Failing to explain the LIFO order of multiple deferred calls.
• ×Not providing a practical, resource-management-related use case.

What a strong answer covers

• Explain that an interface value in Go is represented internally as a two-word structure: a type descriptor and a value (data) pointer.
• Define a "nil interface value" as an interface where *both* its type and value components are nil. This is the state of a newly declared interface variable.
• Define an interface holding a nil concrete value as an interface where the type component is non-nil (it holds a concrete type), but its value component is nil (e.g., `var p *MyStruct = nil; var i MyInterface = p`).
• Explain the practical implication: `i == nil` will be true only if *both* components are nil. If the type component is non-nil, even if the value component is nil, `i == nil` will evaluate to false, leading to common bugs.

Where people lose the point

• ×Incorrectly stating that `i == nil` is always true if the underlying value is nil.
• ×Failing to explain the two-word internal representation of an interface.
• ×Not providing a clear example of an interface holding a nil concrete value.

What a strong answer covers

• Define the `select` statement as a control flow construct that allows a goroutine to wait on multiple communication operations (send or receive) on channels.
• Explain that `select` blocks until one of its cases is ready. If multiple cases are ready, `select` chooses one at random to prevent starvation.
• Describe the `default` case: if present, `select` will execute it immediately if no other channel operation is ready, making the `select` non-blocking.
• Discuss common use cases: implementing timeouts, cancellation, multiplexing data from multiple sources, and non-blocking channel operations.

Where people lose the point

• ×Incorrectly stating that `select` prioritizes cases or executes them in order.
• ×Misunderstanding the blocking behavior of `select` without a `default` case.
• ×Failing to explain the purpose and behavior of the `default` case.

What a strong answer covers

• Define the `context` package as a standard library package that provides a way to carry deadlines, cancellation signals, and other request-scoped values across API boundaries and between goroutines.
• Explain the problems it solves: propagating cancellation signals (e.g., HTTP request cancelled by client), setting timeouts for operations, and passing request-specific data (e.g., authentication tokens, trace IDs) down the call chain.
• Describe its typical usage: a `Context` object is passed as the first argument to functions that might need to be cancelled or have a deadline, or that need access to request-scoped values.
• Mention key functions like `context.Background()`, `context.TODO()`, `context.WithCancel()`, `context.WithTimeout()`, and `context.WithValue()`.

Where people lose the point

• ×Suggesting `context` is primarily for general-purpose data passing rather than cancellation/deadlines.
• ×Failing to explain how `context` helps manage the lifecycle of concurrent operations.
• ×Not mentioning that `context` should be passed as the first argument.

What a strong answer covers

• Define a race condition as a situation where multiple goroutines access shared memory concurrently, and at least one of them modifies it, leading to unpredictable results.
• Explain Go's primary approach: "Don't communicate by sharing memory; share memory by communicating" using channels to safely pass data between goroutines.
• Discuss explicit synchronization primitives from the `sync` package: `sync.Mutex` for mutual exclusion (locking shared resources), and `sync.RWMutex` for read/write locking.
• Mention other primitives like `sync.WaitGroup` for waiting for a collection of goroutines to finish, and `sync.Once` for ensuring a function runs only once.

Where people lose the point

• ×Only mentioning mutexes and ignoring channels as Go's idiomatic solution.
• ×Misunderstanding the purpose or usage of `sync.WaitGroup` or `sync.Once`.
• ×Failing to clearly define what a race condition is.

What a strong answer covers

• Define escape analysis as a compile-time optimization in Go that determines whether a variable's lifetime extends beyond the scope of the function it was declared in.
• Explain that if a variable does not 'escape' (its lifetime is confined to the function), it can be allocated on the stack, which is faster and automatically deallocated.
• Explain that if a variable 'escapes' (e.g., its address is taken and returned, or it's stored in a global variable, or passed to a channel), it must be allocated on the heap, which is managed by the garbage collector.
• Discuss the implications: stack allocation is generally preferred for performance, and escape analysis helps the compiler make intelligent decisions, reducing pressure on the garbage collector.

Where people lose the point

• ×Incorrectly stating that all variables created with `new()` or `&` escape to the heap.
• ×Confusing escape analysis with manual memory management.
• ×Failing to connect escape analysis to performance benefits and GC pressure.

What a strong answer covers

• Explain that generics (type parameters) were introduced in Go 1.18 to allow functions and types to operate on a variety of types without sacrificing type safety or requiring code duplication.
• Describe the problems they solve: eliminating the need for `interface{}` (empty interface) with type assertions for generic data structures, reducing code duplication for functions that operate identically on different types, and improving type safety over reflection-based solutions.
• Discuss common use cases: implementing generic data structures (e.g., `List[T]`, `Map[K, V]`), writing generic algorithms (e.g., `Min[T]`, `Filter[T]`), and creating generic utility functions.
• Mention the use of type constraints (interfaces) to specify the operations allowed on type parameters.

Where people lose the point

• ×Incorrectly stating that generics replace interfaces entirely.
• ×Failing to mention the type safety benefits over `interface{}`.
• ×Not discussing the role of type constraints in defining generic behavior.

What a strong answer covers

• Explain that Go's standard `testing` package provides tools for writing unit and integration tests, with test files named `_test.go`.
• Describe unit tests: functions starting with `TestXxx` that take `*testing.T` as an argument, focusing on isolated components, using `t.Errorf` for failures and `t.Run` for subtests.
• Describe integration tests: similar structure but test interactions between multiple components or external services, often requiring setup/teardown (e.g., using `TestMain` or helper functions).
• Discuss best practices: keeping tests fast and independent, using table-driven tests for multiple scenarios, mocking/stubbing dependencies for unit tests, and using `go test -v` for verbose output.

Where people lose the point

• ×Confusing unit tests with integration tests or not differentiating their scope.
• ×Failing to mention the `_test.go` naming convention or the `*testing.T` argument.
• ×Not discussing how to handle external dependencies in unit tests (e.g., mocking).