yoklainterview sim
ProgressHistory

Go Backend Interview Questions

450 verified Go Backend interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Go ConcurrencyDifficulty 1
func main() {
	go fmt.Println("hello from goroutine")
}

What happens when this program runs?
  • aIt always prints "hello from goroutine" before main exits
  • bIt blocks forever waiting for the goroutine to finish
  • cmain may return before the goroutine runs, so the print may never happen✓
  • dThe compiler rejects go on a call whose result is not used
Explanation:main does not wait for other goroutines. When main returns, the process exits immediately, so a goroutine started just before that can easily never get scheduled. There is no implicit join, and go fmt.Println(...) compiles fine even though the return value is discarded.
Go ConcurrencyDifficulty 1
What is the core semantic difference between an unbuffered channel and a buffered channel in Go?
  • aUnbuffered channels can only carry pointers, buffered channels can carry any type
  • bAn unbuffered send blocks until a receiver is ready; a buffered send blocks only once full✓
  • cBuffered channels never block on send or receive
  • dUnbuffered channels require a select statement, buffered channels do not
Explanation:An unbuffered channel has no capacity, so a send synchronizes directly with a matching receive. A buffered channel lets a fixed number of values sit in the channel before a send blocks, decoupling sender and receiver timing up to that capacity.
Go ConcurrencyDifficulty 2
ch := make(chan int)
close(ch)
v, ok := <-ch
fmt.Println(v, ok)

What does this print?
  • a0 false✓
  • bIt panics because the channel is closed
  • c0 true
  • dIt blocks forever because there is no sender
Explanation:Receiving from a closed channel never blocks and never panics. It immediately yields the zero value of the element type (0 for int) with ok set to false, signaling that the channel is closed and drained.
Go ConcurrencyDifficulty 2
ch := make(chan int, 2)
close(ch)
ch <- 1

What happens when this code runs?
  • aIt silently drops the value 1 since the channel is closed
  • bIt panics with "send on closed channel"✓
  • cIt succeeds because the buffer has room
  • dIt blocks forever waiting for a receiver
Explanation:Sending on a closed channel always panics, regardless of remaining buffer capacity. Buffer space only matters for open channels; once close has been called, any further send is a programming error the runtime reports immediately.
Go ConcurrencyDifficulty 2
var ch chan int
<-ch

What is the behavior of the receive on the second line?
  • aIt panics because ch was never initialized with make
  • bIt returns the zero value immediately, like a closed channel
  • cIt returns an error value describing the nil channel
  • dIt blocks forever, since a nil channel is never ready✓
Explanation:ch is a nil channel (declared but never make'd). Operations on a nil channel block permanently rather than panicking or returning immediately — this is a common cause of goroutines that hang without any error message.
Go ConcurrencyDifficulty 2
ch := make(chan int, 3)
ch <- 1
ch <- 2
ch <- 3
close(ch)
for v := range ch {
	fmt.Println(v)
}

What does this print?
  • aOnly 1, then the loop panics because the channel is closed
  • b1 2 3, and then it loops forever printing 0
  • c1 2 3, and the loop exits once the channel drains✓
  • dNothing, because you cannot range over a closed channel
Explanation:range over a channel receives values until the channel is both closed and empty, then the loop exits normally — no panic, no extra zero values. Since the buffer already holds 1, 2, 3 before close, the loop delivers all three and stops.

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview