Go Interview Questions

"A goroutine is a function running concurrently, managed by the Go runtime rather than the operating system. It starts with a tiny stack, a few kilobytes, that the runtime grows and shrinks, whereas an OS thread usually reserves a much bigger fixed stack. The runtime schedules many goroutines onto a small pool of OS threads, so switching between them is cheap and doesn't need the kernel. That's why spinning up ten thousand goroutines for ten thousand connections is normal in Go. The trade-off is you get less control: there's no goroutine ID and no way to kill one from outside. If I want a goroutine to stop, I design it to listen for cancellation, usually a context or a done channel. And when main returns, the program exits and every other goroutine just stops, finished or not."

"Go uses three pieces. G is a goroutine, M is an OS thread, and P is a logical processor that holds a local queue of runnable goroutines. To run Go code, an M has to hold a P, and the number of Ps is GOMAXPROCS, which defaults to the number of CPUs the process can use, so that's how many goroutines truly run in parallel. When a P's queue runs dry, it steals work from another P, and there's a global queue as a fallback. If a goroutine makes a blocking system call, its thread blocks, so the runtime hands that P to another thread and the rest keep running. Network I/O is smarter: the goroutine is parked on the netpoller and no thread is tied up. And since the runtime can preempt goroutines asynchronously, a tight loop no longer starves everyone else."

"The channel is unbuffered and there's only one receive. The first goroutine to finish hands over its result, and every other goroutine blocks forever on its send, because nobody will ever read. The garbage collector can't free a blocked goroutine, so each call leaks len(urls) minus one goroutines, plus whatever they hold on to. The simplest fix is to buffer the channel to len(urls), so every send succeeds and the goroutines exit. The better fix also stops wasted work: pass a context, cancel it once I have my answer, and have each sender select between sending and ctx.Done. To catch this class of bug, I watch the goroutine count as a metric, and in tests I check that no goroutines are left behind after the function returns."

"First I'd check how long until it runs out of memory and line up a rolling restart as a safety net, but before restarting any instance I'd grab a goroutine profile from the pprof endpoint, because a restart wipes the evidence. In that dump I look at which stacks have thousands of goroutines. A leak is nearly always thousands parked in the same place: a channel send nobody reads, a select with no ctx.Done case, or an outbound HTTP call with no timeout waiting on a slow dependency. I'd also check whether it lines up with a deploy or a dependency slowing down. Then the fix matches the cause: a context with a deadline, a buffered channel, or closing response bodies. Afterwards I'd add a test that checks no goroutines are left over, and an alert on the goroutine count trend."

"An unbuffered channel has no storage, so a send blocks until another goroutine receives. That makes it a handoff and a sync point: when my send returns, I know the receiver has the value. A buffered channel has a queue of a fixed size. Sends go straight in until it's full, and receives only block when it's empty, so producer and consumer are decoupled for a while. I start with unbuffered unless I have a reason. Good reasons are a known number of results, like one slot per goroutine so none of them ever block, or smoothing short bursts. What I avoid is bumping the buffer to make a hang go away. If the consumer is slower than the producer, a buffer only delays the moment it fills up."

"select is like a switch for channel operations. It blocks until one of its cases can go ahead, and if several are ready at the same moment it picks one at random, so no case is always favoured. For a timeout, I add a second case that fires later: time.After for a quick one-off, or better, ctx.Done so the caller controls the deadline and cancellation arrives through the same path. For a non-blocking send, I add a default case. If the channel can't take the value right now, default runs instead of waiting, which is handy for something like dropping metrics events when a buffer is full rather than slowing the request. One thing I watch is using default inside a loop with nothing else to block on, because that spins a CPU at full speed."

"The rule I follow is that the side that sends owns the channel and is the only one allowed to close it. Closing is a message that says no more values are coming, and a receiver can't know that. If there are several senders, I have them finish under a WaitGroup and a separate goroutine closes the channel after Wait. Then the edge cases. Sending on a closed channel panics, and so does closing it twice. Receiving from a closed channel never blocks: you get any values still in the buffer, then the zero value with ok set to false, which is also what ends a for range loop. A nil channel is different: sends and receives block forever and closing it panics. That sounds useless, but in a select, setting a channel to nil switches that case off."

"I'd have two channels, one for jobs and one for results. I start N workers; each one ranges over the jobs channel, handles a job and sends the result on. A WaitGroup counts the workers. I feed the jobs from a separate goroutine and close the jobs channel when they're all sent, which is what makes each worker's range loop end. The trickiest part is closing results: I can't close it while workers might still send, so another goroutine waits on the WaitGroup and then closes it. Meanwhile the main goroutine ranges over results and collects them. The order of the results isn't the order of the jobs, so if order matters I'd carry an index in the job. In a real service I'd also pass a context so the whole pool stops if the caller gives up."

"I use channels when data is moving between goroutines: a pipeline, handing work to a pool, or signalling that something finished. I use a Mutex when several goroutines just need safe access to one piece of shared state, like an in-memory cache or a map of sessions. Building that with a channel means a goroutine that owns the map and a request-reply protocol, which is more code and usually slower. If reads far outnumber writes, an RWMutex lets readers go together, and for a single counter or flag I'd use sync/atomic. The habits that matter: lock, do the minimum, unlock, usually with defer. Never hold a lock while doing I/O or sending on a channel. And never copy a struct that holds a Mutex; go vet flags that for me."

"A WaitGroup is a counter. I call Add before I start each goroutine, the goroutine calls Done when it finishes, usually with defer so it still runs on an early return, and Wait blocks until the counter reaches zero. The most common mistake is calling Add inside the goroutine. The goroutine might not have been scheduled yet when the parent reaches Wait, the counter is still zero, and Wait returns straight away while work is still running. So Add always happens in the parent, before the go statement. The second mistake is passing a WaitGroup to a function by value. Done then decrements a copy, and the real Wait hangs forever. I pass a pointer or capture it in a closure. Newer Go versions also have wg.Go, which does the Add and Done for me. And if I also need the first error back, I reach for errgroup instead."

"sync.Once has one method, Do. However many goroutines call Do at the same time, the function inside runs exactly once, and every other caller blocks until that first run has finished, so they all see the result. I use it for lazy, shared setup: creating a client the first time it's needed, compiling a set of templates, or loading config in a package that shouldn't do work at import time. The catch is that Once counts the call as done even if the function failed or panicked, so there's no retry. If setup can fail, I store the error alongside the value so every caller sees it, and the newer helpers sync.OnceValue and OnceValues make that pattern short. Also, calling Do on the same Once from inside its own function deadlocks."

"A context carries a cancel signal and maybe a deadline down a call chain. I derive children with WithCancel, WithTimeout or WithDeadline, and cancelling a parent cancels every child, so when an HTTP client disconnects, the database query and the downstream calls all get told to stop. Cancellation is cooperative, though: nothing is killed. My code has to notice. In a loop I select on ctx.Done, return ctx.Err, which tells me whether it was cancelled or timed out, and I pass ctx into every call that can block. When I create a context with a cancel function I always defer cancel, even if it'll time out anyway, because that frees its resources early. Context is the first parameter, not a struct field, and WithValue is only for request-scoped things like a trace ID, never optional arguments."

"I'd use errgroup from the golang.org/x/sync module. WithContext gives me a group and a derived context. I start each fetch with g.Go, passing that context into the fetch. The first goroutine that returns an error cancels the context, so the others see it and give up early, as long as fetch respects the context. Wait blocks until every goroutine has returned and gives me the first error. For results, I size a slice up front and each goroutine writes only to its own index. Different indexes are different memory, so there's no race and no lock. If the list could be long, I call SetLimit so I don't open a thousand connections at once. The only thing to remember is that a goroutine ignoring ctx keeps running to the end, so cancellation is only as good as the code under it."

"An interface in Go is just a set of method signatures. Any type that has those methods satisfies it automatically. There's no implements keyword, so the type doesn't even need to know the interface exists. That changes how you design. Instead of a big interface declared next to the implementation, the consumer defines a small one with only the methods it needs. If my function only reads bytes, it takes an io.Reader, and it works with files, network connections, buffers and anything else, including test fakes, without those types changing. The usual advice is to accept interfaces and return concrete structs, so callers get the full type. If I want the compiler to confirm a type satisfies an interface, I add a line like var _ io.Writer = (*MyWriter)(nil), which fails to compile if it doesn't."

"An interface value is really a pair: the concrete type and the value. It's only equal to nil when both halves are empty. In this function, the variable is a nil pointer of type star MyErr. When it's returned as an error, the interface gets the type star MyErr and a nil value. The type half isn't empty, so the error isn't nil, and the caller thinks something failed. If they then call Error on it, it might even work, because a method with a pointer receiver can run on a nil pointer, which makes it more confusing. The fix is simple: in the success path, return nil directly, not a typed variable that happens to be nil. I also keep error-returning functions declared as returning error, never a concrete error type."

"Embedding means putting a type inside a struct without a field name. Its fields and methods are promoted, so if Server embeds Logger, I can call s.Log directly, and Server satisfies any interface Logger's methods satisfy. It looks like inheritance but it's composition. When I call s.Log, Go really calls s.Logger.Log, and inside that method the receiver is the Logger, not the Server. So if Logger.Log calls another Logger method that Server also defines, it gets Logger's version, not Server's. There's no virtual dispatch. The outer type can define a method with the same name to shadow the inner one, and if two embedded types at the same depth have the same method, that's only a compile error when you actually call it. I use embedding to reuse behaviour, and interfaces when I need polymorphism."

"A value receiver gets a copy, so changes inside the method are lost. I use a pointer receiver when the method has to modify the struct, when the struct is big enough that copying it on every call is wasteful, or when it contains something that mustn't be copied, like a Mutex. Small immutable types, like a time value or a point, work fine with value receivers. For consistency, if one method needs a pointer I make them all pointers. The interface part is about method sets. The pointer type has every method, value and pointer ones. The value type only has the value-receiver methods. So if Save has a pointer receiver, a Store value doesn't satisfy an interface with Save, but a pointer to Store does. That's the classic does-not-implement error, and the fix is usually to pass the address."

"I use generics when the logic is identical and only the type changes: a set, a cache, a helper that filters or maps a slice, or summing numbers. Before generics you either copied the function per type or used any and lost type safety. A constraint is an interface that says which types are allowed. In this Number constraint, the tilde means any type whose underlying type is int, int64 or float64, so my own type Celsius based on float64 works too. Because every type in the set supports plus, the compiler lets me use it. For map keys I'd use comparable. Filter uses any, since it only moves values around. Where I don't use generics is when each type behaves differently. That's what interfaces are for, and forcing generics there just makes the code harder to read."

"An array has a fixed size that's part of its type, so an array of three ints and an array of four ints are different types. Arrays are values: assign one or pass it to a function and every element is copied. A slice is what we use almost all the time. It's a small header with three things: a pointer into a backing array, a length, which is how many elements I can see, and a capacity, which is how far the backing array goes. When I pass a slice to a function, only that header is copied, so the function can change the elements and I'll see it. But if the function appends and the slice has to grow, it may get a new array, and my copy of the header won't know. That's why append returns a slice you must use."

"It prints 5 5. The slice a has length 3 but capacity 10. The first append has room, so it writes 4 into index 3 of the same backing array and b is a view of length 4 over that array. The second append also starts from a, still length 3, so it writes 5 into the same index 3. Now b and c share that slot, and b quietly changed. Append only allocates when the capacity is used up. Then it makes a bigger array, roughly doubling for small slices and growing by a smaller factor for large ones, copies the elements, and returns a slice on the new array. Old slices keep pointing at the old one. To stop this, I cap the slice with a full slice expression so the next append must copy, or I clone it first."

"Maps aren't safe for concurrent use. Many goroutines reading at once is fine, but as soon as one writes while another reads or writes, it's a data race. Go's runtime checks for this cheaply and, when it catches it, crashes the whole program with a fatal error about concurrent map writes. That's not a normal panic, so recover can't save you. Even when it isn't caught, the map can be corrupted. The usual fix is a struct holding the map and a Mutex, or an RWMutex if reads dominate. sync.Map exists, but it's tuned for specific patterns: keys written once and read many times, like a cache that only grows, or goroutines working on separate keys. For general use it loses type safety and can be slower, so a plain map with a lock is my default. The race detector catches this in tests."

"In Go an error is just a value, returned last and checked right after the call. When I pass one up, I add context about what I was doing, like load user 42, so the final log line reads as a story. I wrap with fmt.Errorf using the w verb, which keeps the original error inside. If I used the v verb instead, it would flatten it to text and callers could no longer inspect it. Higher up, errors.Is walks the chain looking for a specific value, a sentinel error like ErrNotFound, which is how I'd turn it into an HTTP 404. errors.As walks the chain looking for a type, and fills in a variable so I can read fields, like the path on a fs.PathError. I handle each error once: either log it or return it, not both."

"defer schedules a call to run when the surrounding function returns, whether it returns normally or by panicking. Several defers run last in, first out. The detail people miss is that the arguments are evaluated at the defer line, not at the end, so defer fmt.Println(i) prints the value i had then. A deferred closure, though, sees the latest values, and can even change named results. A panic stops normal flow and unwinds the stack, running the defers on the way. If nothing recovers it, the program crashes, and that's true for a panic in any goroutine, not just main. recover only stops a panic when called directly inside a deferred function in that same goroutine. I panic for bugs, like an impossible state, and return errors for everything that can reasonably go wrong, like bad input or a failed call."

"I'd agree with the goal. One bad request shouldn't kill the process for everyone. But recover in every function is the wrong tool. A panic means something is broken, like a nil pointer or an index out of range, and if every function swallows it, we carry on with half-updated state and the bug stays hidden. So I'd suggest recovery at the boundaries. The standard HTTP server already recovers a panic in a handler and logs it, but it doesn't cover goroutines the handler starts, so every goroutine we launch for background work needs its own deferred recover that logs the stack and bumps a metric. Then panics are visible and we fix them. I'd also mention some failures, like concurrent map writes, are fatal errors that recover can't catch at all, so the real fix is still the bug."

"The Go way is a table-driven test. I declare a slice of anonymous structs, each with a name, the input, the expected value and whether I expect an error. Then I loop and call t.Run with the case name, so each one shows as its own subtest, I can run a single one with the run flag, and adding a case is one line. My failure message shows the input and what I got, so nobody has to open the code to understand it. For a benchmark, I write a function starting with Benchmark that takes a testing.B and calls the code b.N times. The framework raises N until the timing is stable, and newer Go versions offer b.Loop, which is harder to get wrong. I run it with go test -bench and add -benchmem to see allocations per operation, which is usually where the real win is."

"The race detector is built into the toolchain. I add the race flag to go test, go run or go build, and the compiler instruments every memory access. At run time it watches for two goroutines touching the same memory where at least one is writing and nothing, like a lock or a channel, orders them. When it finds one it prints both stack traces, the write and the other access, which usually points straight at the bug. The reports are real races, so I treat every one as a bug. The big limit is that it only sees what actually happens in that run. If a test never exercises the concurrent path, it reports nothing. So I run tests with race in CI, and I write tests that really hit code from several goroutines. It also slows things down a lot, so it's not something I leave on in production."

"Go doesn't let me choose stack or heap. The compiler runs escape analysis: if it can prove a value doesn't outlive the function, it stays on the stack, which is basically free. If I return a pointer to it, store it somewhere long-lived, or a goroutine closure captures it, it escapes to the heap. I can see those decisions with the m flag in gcflags. The collector is a concurrent mark and sweep. It runs mostly alongside my code, with short stop-the-world pauses and a write barrier while marking. It doesn't move objects and isn't generational. GOGC controls pacing: with the default, the heap can roughly double over the live data before the next cycle. GOMEMLIMIT adds a soft cap, useful in containers. In practice GC cost tracks allocation rate, so I profile allocations and cut them where they're hot."

"At my last company an internal queue consumer would sometimes stop processing, with no errors, and a restart fixed it. Next time it hung I pulled a goroutine dump from the pprof endpoint instead of restarting. Most goroutines were waiting on the same Mutex, and one worker held that lock while it was blocked sending on an unbuffered channel. The goroutine that read from that channel needed the same lock before it could receive, so each was waiting on the other. It only happened when a batch finished at the same moment a config reload ran, which is why it was rare. The fix was to copy what we needed under the lock, release it, and then send. I added a test that ran both paths together in a loop, and a team rule: never block on a channel while holding a lock."

"In a previous role we had an API whose slowest requests were getting worse as traffic grew, and CPU was high for how little it did. I took a CPU profile and an allocation profile from the pprof endpoint under real load. Two things stood out. A regular expression was being compiled inside the request handler on every call, and we were building responses by appending to slices that started empty and grew many times. I moved the regex compile to package level so it happened once, and preallocated the slices since we knew the size. I wrote benchmarks for the handler first, so I could show allocations per request dropping sharply, not just say it felt faster. After release, tail latency came down by about half and the service needed fewer instances. I kept the benchmarks in the repo so a regression would show up."

"In my final-year project I built a service that checked the health of a few hundred websites every minute and alerted when one went down. Go fit well. Each check was a goroutine with a context timeout, so hundreds of checks ran at once without any thread pool tuning. The standard library had the HTTP client, JSON and testing I needed, so there were very few dependencies. And deploying was just copying one static binary into a small container. What I missed at first was the error handling: writing if err != nil so often felt noisy until I started adding real context to each error, and then the logs got much more useful. I also missed some of the collection helpers other languages have, though generics and the slices package have covered most of that since."