Go technical interviews assess understanding of the language's core concepts: concurrency, memory management, and idiomatic patterns. This guide covers the 25 most frequently asked questions with detailed answers and code examples. Go values simplicity and readability. Interviewers look for concise answers demonstrating deep understanding rather than overly complex solutions. ## Go Language Fundamentals ### 1. What's the difference between `var` and `:=`? The `var` declaration allows explicit type specification and works at package level. The `:=` operator infers types automatically but only works inside functions. ```go // declaration.go package main // Package level - var required var globalConfig = "production" func main() { // var with explicit type var count int = 10 // var with type inference var name = "Alice" // Short declaration - functions only age := 25 // Multiple declarations var ( host = "localhost" port = 8080 ) } ``` Short declaration `:=` is preferred inside functions for conciseness, while `var` remains necessary for package-level variables. ### 2. How does Go's type system work? Go uses static typing with type inference. The language distinguishes value types (copied on assignment) from reference types (share underlying structure). ```go // types.go package main import "fmt" func main() { // Value types - full copy a := [3]int{1, 2, 3} b := a // Copies the array b[0] = 100 // Doesn't modify a fmt.Println(a) // [1 2 3] // Reference types - share data slice1 := []int{1, 2, 3} slice2 := slice1 // Same underlying array slice2[0] = 100 // Also modifies slice1 fmt.Println(slice1) // [100 2 3] // Maps are also references m1 := map[string]int{"a": 1} m2 := m1 m2["a"] = 100 fmt.Println(m1["a"]) // 100 } ``` Arrays are value types, while slices, maps, and channels are reference types. ### 3. Explain the difference between arrays and slices Arrays have a fixed size defined at compile time. Slices are dynamic views over an underlying array with three components: pointer, length, and capacity. ```go // arrays_slices.go package main import "fmt" func main() { // Array - fixed size, value type arr := [5]int{1, 2, 3, 4, 5} // Slice - view over the array slice := arr[1:4] // [2 3 4] fmt.Printf("len=%d, cap=%d\n", len(slice), cap(slice)) // len=3, cap=4 // Modifications affect original array slice[0] = 20 fmt.Println(arr) // [1 20 3 4 5] // Direct creation with make dynamic := make([]int, 3, 10) // len=3, cap=10 // Append may reallocate dynamic = append(dynamic, 1, 2, 3, 4, 5) } ``` Slices are the preferred type for dynamic collections in Go. ### 4. How does the `defer` statement work? `defer` schedules a function call to execute at the end of the enclosing function. Deferred calls stack and execute in LIFO (Last In, First Out) order. ```go // defer.go package main import ( "fmt" "os" ) func main() { // LIFO order defer fmt.Println("1") defer fmt.Println("2") defer fmt.Println("3") // Prints: 3, 2, 1 } // Typical use case: resource cleanup func readFile(path string) ([]byte, error) { file, err := os.Open(path) if err != nil { return nil, err } defer file.Close() // Always executes // Read file... return os.ReadFile(path) } // Caution: arguments are evaluated immediately func deferArgs() { x := 10 defer fmt.Println(x) // Captures 10 x = 20 // Prints: 10 } ``` `defer` guarantees execution even during panic, making it ideal for resource cleanup. ### 5. What is an interface in Go? An interface defines a set of methods. Any type implementing those methods implicitly satisfies the interface, without explicit declaration. ```go // interfaces.go package main import "fmt" // Interface definition type Writer interface { Write([]byte) (int, error) } // Type that implicitly implements Writer type FileLogger struct { path string } func (f *FileLogger) Write(data []byte) (int, error) { // Write to file fmt.Println("Writing to", f.path) return len(data), nil } // Empty interface - accepts any type func printAny(v interface{}) { fmt.Printf("Type: %T, Value: %v\n", v, v) } // Type assertion func process(w Writer) { // Type check if fl, ok := w.(*FileLogger); ok { fmt.Println("FileLogger with path:", fl.path) } } ``` Implicit interface implementation enables strong decoupling between packages. ## Concurrency and Goroutines ### 6. What is a goroutine and how does it differ from a thread? A goroutine is a lightweight thread managed by the Go runtime. It uses a few KB of stack (compared to several MB for an OS thread) and the Go scheduler multiplexes thousands of goroutines onto a few system threads. ```go // goroutines.go package main import ( "fmt" "sync" "time" ) func main() { var wg sync.WaitGroup // Launch 1000 goroutines for i := 0; i < 1000; i++ { wg.Add(1) go func(id int) { defer wg.Done() time.Sleep(100 * time.Millisecond) fmt.Printf("Goroutine %d finished\n", id) }(i) // Pass i by value } wg.Wait() fmt.Println("All goroutines completed") } ``` Always pass loop variables by value to goroutines. Otherwise, all goroutines may capture the same final value. ### 7. Explain how channels work Channels enable communication and synchronization between goroutines. They can be buffered (with capacity) or unbuffered (synchronous). ```go // channels.go package main import "fmt" func main() { // Unbuffered channel - blocks until received ch := make(chan int) go func() { ch <- 42 // Blocks until read }() value := <-ch // Receives value fmt.Println(value) // Buffered channel - doesn't block until full buffered := make(chan string, 2) buffered <- "first" buffered <- "second" // buffered <- "third" // Would block fmt.Println(<-buffered) // "first" fmt.Println(<-buffered) // "second" } ``` Unbuffered channels guarantee synchronization, while buffered channels allow temporal decoupling. ### 8. How do you use `select` with multiple channels? `select` waits on multiple channel operations simultaneously. The first ready operation executes, with random choice on ties. ```go // select.go package main import ( "fmt" "time" ) func main() { ch1 := make(chan string) ch2 := make(chan string) go func() { time.Sleep(100 * time.Millisecond) ch1 <- "from ch1" }() go func() { time.Sleep(200 * time.Millisecond) ch2 <- "from ch2" }() // Wait with timeout for i := 0; i < 2; i++ { select { case msg := <-ch1: fmt.Println(msg) case msg := <-ch2: fmt.Println(msg) case <-time.After(500 * time.Millisecond): fmt.Println("Timeout") } } // Non-blocking select with default select { case msg := <-ch1: fmt.Println(msg) default: fmt.Println("No message available") } } ``` `select` is the fundamental tool for elegantly managing concurrency in Go. ### 9. How do you prevent race conditions? Race conditions occur when multiple goroutines access shared data without synchronization. Go offers several protection mechanisms. ```go // race_conditions.go package main import ( "fmt" "sync" "sync/atomic" ) // Solution 1: Mutex type SafeCounter struct { mu sync.Mutex count int } func (c *SafeCounter) Increment() { c.mu.Lock() defer c.mu.Unlock() c.count++ } // Solution 2: RWMutex for read-heavy workloads type Cache struct { mu sync.RWMutex data map[string]string } func (c *Cache) Get(key string) string { c.mu.RLock() // Multiple readers allowed defer c.mu.RUnlock() return c.data[key] } func (c *Cache) Set(key, value string) { c.mu.Lock() // Single writer defer c.mu.Unlock() c.data[key] = value } // Solution 3: atomic for simple counters var atomicCounter int64 func incrementAtomic() { atomic.AddInt64(&atomicCounter, 1) } func main() { // Detection: go run -race main.go counter := SafeCounter{} var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func() { defer wg.Done() counter.Increment() }() } wg.Wait() fmt.Println("Count:", counter.count) } ``` The `-race` compiler flag detects race conditions at runtime. ### 10. Explain the worker pool pattern The worker pool pattern limits concurrency by creating a fixed number of goroutines that process tasks from a queue. ```go // worker_pool.go package main import ( "fmt" "sync" "time" ) func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) { defer wg.Done() for job := range jobs { fmt.Printf("Worker %d processing job %d\n", id, job) time.Sleep(100 * time.Millisecond) // Simulate work results <- job * 2 } } func main() { const numJobs = 10 const numWorkers = 3 jobs := make(chan int, numJobs) results := make(chan int, numJobs) var wg sync.WaitGroup // Start workers for w := 1; w <= numWorkers; w++ { wg.Add(1) go worker(w, jobs, results, &wg) } // Send jobs for j := 1; j <= numJobs; j++ { jobs <- j } close(jobs) // Wait and close results go func() { wg.Wait() close(results) }() // Collect results for result := range results { fmt.Println("Result:", result) } } ``` This pattern prevents memory and CPU overhead from creating too many goroutines. ## Error Handling and Panic/Recover ### 11. How do you handle errors in Go? Go uses explicit return values for errors, without exceptions. By convention, error is the last returned parameter. ```go // errors.go package main import ( "errors" "fmt" ) // Sentinel errors for comparison var ( ErrNotFound = errors.New("resource not found") ErrUnauthorized = errors.New("access unauthorized") ) // Custom error type type ValidationError struct { Field string Message string } func (e *ValidationError) Error() string { return fmt.Sprintf("validation %s: %s", e.Field, e.Message) } func validateAge(age int) error { if age < 0 { return &ValidationError{ Field: "age", Message: "must be positive", } } return nil } func main() { // Basic check if err := validateAge(-5); err != nil { // Type assertion for custom error var valErr *ValidationError if errors.As(err, &valErr) { fmt.Printf("Field: %s\n", valErr.Field) } } // Sentinel error comparison err := findUser("unknown") if errors.Is(err, ErrNotFound) { fmt.Println("User not found") } } func findUser(id string) error { // Error wrapping with context return fmt.Errorf("findUser %s: %w", id, ErrNotFound) } ``` Wrapping with `%w` chains errors while preserving the ability to test for the original error. ### 12. When should you use panic and recover? `panic` interrupts normal execution and unwinds the stack. `recover` captures the panic in a `defer` and allows execution to resume. ```go // panic_recover.go package main import "fmt" func safeOperation() (err error) { defer func() { if r := recover(); r != nil { err = fmt.Errorf("recovered from panic: %v", r) } }() riskyOperation() return nil } func riskyOperation() { // Simulates an operation that can panic panic("something went wrong") } // Legitimate use case: initialization validation func MustCompileRegex(pattern string) *Regexp { r, err := regexp.Compile(pattern) if err != nil { panic(err) // Programming error } return r } func main() { err := safeOperation() if err != nil { fmt.Println("Recovered error:", err) } fmt.Println("Program continues") } ``` Use panic only for programming errors (violated invariants). For expected errors (missing file, network issues), always return an error. ## Structs, Methods, and Embedding ### 13. What's the difference between value and pointer receivers? A value receiver receives a copy of the struct, while a pointer receiver receives a reference and can modify the original. ```go // receivers.go package main import "fmt" type Counter struct { value int } // Value receiver - works on copy func (c Counter) GetValue() int { return c.value } // Pointer receiver - modifies original func (c *Counter) Increment() { c.value++ } // Pointer receiver for large structs (avoids copy) type LargeStruct struct { data [1000]int } func (l *LargeStruct) Process() { // Avoids copying 8000 bytes } func main() { c := Counter{value: 0} c.Increment() // Go automatically converts fmt.Println(c.GetValue()) // 1 // Careful with interfaces var _ fmt.Stringer = &c // OK if method on *Counter } ``` Rule: if one method uses a pointer receiver, all methods on that type should use pointer receivers for consistency. ### 14. How does embedding work in Go? Embedding includes one type within another, inheriting its methods and fields. This is not classical inheritance but composition. ```go // embedding.go package main import "fmt" type Logger struct { prefix string } func (l *Logger) Log(msg string) { fmt.Printf("[%s] %s\n", l.prefix, msg) } // Embedding Logger type Service struct { *Logger // Pointer embedding name string } func NewService(name string) *Service { return &Service{ Logger: &Logger{prefix: name}, name: name, } } func main() { svc := NewService("API") // Promoted method - direct access svc.Log("Starting") // Explicit access also works svc.Logger.Log("Explicit") // Promoted field fmt.Println(svc.prefix) // "API" } ``` Embedding enables flexible compositions while avoiding the rigidity of inheritance. ### 15. How do you implement the singleton pattern in Go? The `sync` package offers `sync.Once` to guarantee single execution of initialization, even with concurrent goroutines. ```go // singleton.go package main import ( "fmt" "sync" ) type Database struct { connectionString string } var ( instance *Database once sync.Once ) func GetDatabase() *Database { once.Do(func() { fmt.Println("Single initialization") instance = &Database{ connectionString: "postgres://...", } }) return instance } func main() { // Concurrent calls - single initialization var wg sync.WaitGroup for i := 0; i < 10; i++ { wg.Add(1) go func() { defer wg.Done() db := GetDatabase() fmt.Printf("Instance: %p\n", db) }() } wg.Wait() } ``` `sync.Once` is thread-safe and more elegant than using a mutex with double-check locking. ## Context and Cancellation ### 16. What is the context package used for? The `context` package manages deadlines, cancellation signals, and request-scoped values across the call tree. ```go // context.go package main import ( "context" "fmt" "time" ) func main() { // Context with timeout ctx, cancel := context.WithTimeout( context.Background(), 2*time.Second, ) defer cancel() // Always call cancel result := make(chan string, 1) go func() { // Simulate long operation time.Sleep(3 * time.Second) result <- "completed" }() select { case res := <-result: fmt.Println(res) case <-ctx.Done(): fmt.Println("Timeout:", ctx.Err()) } } // Propagation through functions func fetchData(ctx context.Context, url string) ([]byte, error) { // Early check if ctx.Err() != nil { return nil, ctx.Err() } req, err := http.NewRequestWithContext(ctx, "GET", url, nil) if err != nil { return nil, err } // HTTP client respects context resp, err := http.DefaultClient.Do(req) // ... } ``` Any potentially long-running function should accept a `context.Context` as its first parameter. ### 17. How do you handle graceful program shutdown? System signals like SIGINT and SIGTERM can be captured to enable clean shutdown. ```go // graceful_shutdown.go package main import ( "context" "fmt" "os" "os/signal" "syscall" "time" ) func main() { // Context cancelled on signal ctx, stop := signal.NotifyContext( context.Background(), syscall.SIGINT, syscall.SIGTERM, ) defer stop() // Start server server := startServer() // Wait for signal <-ctx.Done() fmt.Println("\nShutting down...") // Timeout for graceful shutdown shutdownCtx, cancel := context.WithTimeout( context.Background(), 5*time.Second, ) defer cancel() if err := server.Shutdown(shutdownCtx); err != nil { fmt.Println("Shutdown error:", err) } fmt.Println("Shutdown complete") } ``` This pattern ensures active connections finish properly before shutdown. ## Testing and Benchmarks ### 18. How do you write tests in Go? The built-in `testing` package provides basic functionality. Tests reside in `*_test.go` files. ```go // calculator_test.go package calculator import "testing" func TestAdd(t *testing.T) { result := Add(2, 3) if result != 5 { t.Errorf("Add(2, 3) = %d; want 5", result) } } // Table-driven tests func TestAddTableDriven(t *testing.T) { tests := []struct { name string a, b int expected int }{ {"positive", 2, 3, 5}, {"negative", -1, -1, -2}, {"mixed", -1, 5, 4}, {"zero", 0, 0, 0}, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { result := Add(tt.a, tt.b) if result != tt.expected { t.Errorf("Add(%d, %d) = %d; want %d", tt.a, tt.b, result, tt.expected) } }) } } ``` Table-driven tests are the idiomatic pattern in Go for testing multiple cases. ### 19. How do you write benchmarks? Benchmarks use `testing.B` and run with `go test -bench`. ```go // benchmark_test.go package main import ( "strings" "testing" ) func BenchmarkStringConcat(b *testing.B) { for i := 0; i < b.N; i++ { var s string for j := 0; j < 100; j++ { s += "a" } } } func BenchmarkStringBuilder(b *testing.B) { for i := 0; i < b.N; i++ { var sb strings.Builder for j := 0; j < 100; j++ { sb.WriteString("a") } _ = sb.String() } } // Typical results: // BenchmarkStringConcat-8 50000 28000 ns/op // BenchmarkStringBuilder-8 1000000 1200 ns/op ``` Benchmarks reveal performance differences between implementations. ## Generics (Go 1.18+) ### 20. How do you use generics in Go? Go 1.18 introduced type parameters, enabling generic code while maintaining type safety. ```go // generics.go package main import "fmt" // Generic function func Map[T, U any](slice []T, fn func(T) U) []U { result := make([]U, len(slice)) for i, v := range slice { result[i] = fn(v) } return result } // Custom type constraint type Number interface { int | int64 | float64 } func Sum[T Number](values []T) T { var sum T for _, v := range values { sum += v } return sum } // Generic type type Stack[T any] struct { items []T } func (s *Stack[T]) Push(item T) { s.items = append(s.items, item) } func (s *Stack[T]) Pop() (T, bool) { if len(s.items) == 0 { var zero T return zero, false } item := s.items[len(s.items)-1] s.items = s.items[:len(s.items)-1] return item, true } func main() { // Usage doubled := Map([]int{1, 2, 3}, func(n int) int { return n * 2 }) fmt.Println(doubled) // [2 4 6] fmt.Println(Sum([]int{1, 2, 3, 4, 5})) // 15 stack := &Stack[string]{} stack.Push("hello") stack.Push("world") val, _ := stack.Pop() fmt.Println(val) // "world" } ``` Generics eliminate the need for duplicate code or using `interface{}`. ## Modules and Dependencies ### 21. How does the Go module system work? Go modules manage dependencies with semantic versioning. The `go.mod` file defines the module and its dependencies. ```go // go.mod example module github.com/user/myproject go 1.21 require ( github.com/gin-gonic/gin v1.9.1 github.com/lib/pq v1.10.9 ) // Essential commands: // go mod init github.com/user/project // go mod tidy - clean dependencies // go get package@v1.2.3 - add/update // go mod vendor - copy locally ``` ```bash # Updating dependencies go get -u ./... # All dependencies go get -u=patch ./... # Patches only ``` The `go.sum` file contains cryptographic checksums to ensure dependency integrity. ### 22. How should a Go project be structured? The standard structure follows community conventions without imposing strict rules. ``` myproject/ ├── cmd/ │ └── api/ │ └── main.go # Entry point ├── internal/ # Private to module │ ├── handler/ │ ├── service/ │ └── repository/ ├── pkg/ # Reusable external code ├── go.mod ├── go.sum └── README.md ``` The `internal` folder is special: its contents cannot be imported by other modules. ## Advanced Questions ### 23. How does the garbage collector work in Go? Go uses a concurrent, tri-color mark-and-sweep garbage collector optimized for low latency. ```go // gc_optimization.go package main import "runtime" func main() { // GC configuration // GOGC=100 (default) - triggers GC when heap doubles // Force GC runtime.GC() // Memory statistics var stats runtime.MemStats runtime.ReadMemStats(&stats) println("Alloc:", stats.Alloc) println("NumGC:", stats.NumGC) println("PauseTotalNs:", stats.PauseTotalNs) } // Optimization techniques // 1. Reuse allocations with sync.Pool // 2. Pre-allocate slices with make([]T, 0, cap) // 3. Avoid repeated string/[]byte conversions // 4. Use pointers for large structs ``` The environment variable `GODEBUG=gctrace=1` displays GC traces. ### 24. Explain the Go scheduler The Go scheduler uses an M:N model mapping N goroutines onto M system threads, with three entities: G (goroutine), M (thread), P (logical processor). ```go // scheduler.go package main import ( "fmt" "runtime" ) func main() { // Number of logical processors (P) fmt.Println("GOMAXPROCS:", runtime.GOMAXPROCS(0)) // Number of active goroutines fmt.Println("NumGoroutine:", runtime.NumGoroutine()) // Yield processor to other goroutines runtime.Gosched() // M:P:G model // - G: goroutine (lightweight stack ~2KB) // - M: OS thread (machine) // - P: logical processor (execution context) // // Each P has a local queue of Gs // Work stealing when queue is empty } ``` The scheduler is preemptive since Go 1.14, preventing a goroutine from monopolizing a P. ### 25. How do you optimize performance in Go? Optimization starts with profiling to identify bottlenecks. ```go // profiling.go package main import ( "os" "runtime/pprof" ) func main() { // CPU profiling f, _ := os.Create("cpu.prof") pprof.StartCPUProfile(f) defer pprof.StopCPUProfile() // Code to profile... // Memory profiling mf, _ := os.Create("mem.prof") defer mf.Close() pprof.WriteHeapProfile(mf) } // Analysis: go tool pprof cpu.prof // Common optimization techniques: // 1. Avoid allocations in hot loops // 2. Use sync.Pool for reusable objects // 3. Prefer []byte over string for mutations // 4. Use bufio for I/O // 5. Batch database operations ``` Measure before optimizing. Profiling often reveals surprises about the real bottlenecks. ## Conclusion These 25 questions cover the fundamental concepts tested in Go interviews: **Preparation Checklist:** - ✅ Mastery of goroutines and channels - ✅ Understanding implicit interfaces - ✅ Idiomatic error handling - ✅ Proper context usage - ✅ Concurrency patterns (mutex, worker pool) - ✅ Testing and benchmarking - ✅ Knowledge of Go 1.18+ generics The key to success in Go interviews: demonstrate understanding of trade-offs between simplicity and performance, and know when to use each concurrency pattern.