Interview questions by language
Goroutines, channels, interfaces, error handling, and the simplicity philosophy.
What it really tests
A Go interview rewards a specific mindset: simplicity, explicitness, and concurrency done with goroutines and channels rather than threads and locks. The language deliberately omits features other languages take for granted (no inheritance, no exceptions, until recently no generics), so interviewers check that you embrace the Go way instead of fighting it. The most important early question is almost always about concurrency, because Go's whole identity is 'do not communicate by sharing memory; share memory by communicating.'
The second theme is the type system's two distinctive choices: structural interfaces and explicit error handling. Go interfaces are satisfied implicitly, so a type implements an interface just by having the methods, which enables loose coupling and easy testing. And errors are ordinary values returned alongside results, checked with the if err != nil idiom, rather than thrown. A candidate who can explain why Go made these choices, and the tradeoffs (verbosity for explicitness), is showing real understanding.
Senior Go interviews dig into the runtime: how the scheduler multiplexes thousands of goroutines onto a few OS threads (the G-M-P model), how channels and select coordinate them, the rules around buffered vs unbuffered channels, and how to avoid the classic data race and goroutine-leak bugs. Knowing the sync package (WaitGroup, Mutex, Once) and when to prefer it over channels rounds out the picture.
Go is the language of choice for cloud-native, infrastructure, and high-throughput backend teams across the US and EU (Kubernetes, Docker, and most modern platform tooling are Go); expect heavy concurrency and interface questions in DevOps, SRE, and platform loops.
The map
Lightweight concurrency, buffered vs unbuffered channels, select, and the 'share by communicating' philosophy. The defining topic of Go interviews.
Implicit satisfaction, the empty interface, and how small interfaces enable decoupling and testing. No explicit 'implements' keyword.
Errors as values, the if err != nil idiom, wrapping with %w, and why Go avoids exceptions. panic/recover is for truly exceptional cases.
The G-M-P scheduler, the garbage collector, value vs pointer semantics, and slices' backing-array sharing gotcha.
Question bank
The questions that come up most often, each with a sample answer you can adapt into your own words. Read them out loud until the explanation feels natural.
A goroutine is a lightweight, runtime-managed concurrent function started with the go keyword. It begins with a tiny stack (a few KB) that grows as needed, so you can run hundreds of thousands of them, whereas OS threads cost megabytes each. The Go scheduler multiplexes many goroutines onto a small pool of OS threads, so goroutines are far cheaper to create and switch.
An unbuffered channel is synchronous: a send blocks until a receiver is ready, so it acts as a rendezvous point that synchronises two goroutines. A buffered channel holds up to its capacity without a receiver; sends block only when the buffer is full and receives block only when it is empty. Use unbuffered for handoff/synchronisation and buffered to smooth bursty producers.
Functions return errors as ordinary values, conventionally the last return value, and callers check with if err != nil. This makes the error path explicit and local rather than hidden in a stack of throws. Errors can be wrapped with fmt.Errorf and %w to add context while preserving the chain, then inspected with errors.Is and errors.As. panic/recover exists but is reserved for truly unrecoverable situations.
Interfaces are satisfied implicitly: any type that has the required method set implements the interface without declaring so. This decouples packages, since a consumer can define the small interface it needs and any provider satisfies it. The empty interface (interface{} or any) accepts any value, used when you genuinely need to hold an unknown type, typically narrowed with a type assertion or switch.
A data race occurs when two goroutines access the same variable concurrently and at least one writes, without synchronisation, producing undefined behaviour. You prevent it by communicating over channels or guarding the variable with a sync.Mutex. Go ships a race detector: running tests or the program with the -race flag instruments memory access and reports races at runtime, which is the standard way to find them.
select waits on multiple channel operations and proceeds with whichever is ready, choosing randomly if several are. It is how you coordinate several channels, implement timeouts (with time.After), and add cancellation (with a context's Done channel). A default case makes the select non-blocking. It is the channel equivalent of a switch.
An array has a fixed length that is part of its type ([3]int and [4]int are different types) and is copied by value. A slice is a lightweight view (pointer, length, capacity) over a backing array and is what you use in practice. The gotcha is that slices sharing a backing array can alias each other, and append may or may not allocate a new array depending on capacity.
A goroutine leaks when it blocks forever on a channel that never receives or sends, so it is never garbage collected. You avoid it by ensuring every goroutine has a guaranteed exit path: pass a context.Context and select on ctx.Done(), close channels when done, and use sync.WaitGroup to know when workers finish. The rule is that whoever starts a goroutine is responsible for its termination.
Avoid these
The plan
An external resource we recommend. Educative is not affiliated with us and we earn nothing from this link.
Apply it to a role
Keep exploring
Language fluency gets you through the screen. Pair it with the coding interview patterns, rehearse the behavioral round with worked STAR answers, and when the offer comes, check it is competitive with the salary comparison tool.