Skip to main content
HireInterviewAIHireInterviewAI
ProductAI & MLProctoringPricingBlogDevelopers
Log inBook a Demo
  1. Home
  3. Blog
  5. How to test Go concurrency knowledge in an interview

Concept Guide

How to test Go concurrency knowledge in an interview

How to test Go concurrency knowledge with real interview probes — goroutines, channels, context, and the data race — and tell mastery apart from confident bluffing.

HireInterviewAI Team·June 21, 2026·5 min read
An interviewer testing a candidate's Go concurrency knowledge with goroutine and channel probes
On this page
  • Why Go concurrency deserves its own probe
  • The five concepts to probe (and how)
  • 1. Goroutine lifecycle and leaks
  • 2. Channels: buffered, unbuffered, and closing
  • 3. The context package and cancellation
  • 4. Synchronization: mutexes vs channels vs WaitGroups
  • 5. The data race
  • What a depth report for Go concurrency looks like
  • Mastery vs bluffing: the pattern

On this page

  • Why Go concurrency deserves its own probe
  • The five concepts to probe (and how)
  • 1. Goroutine lifecycle and leaks
  • 2. Channels: buffered, unbuffered, and closing
  • 3. The context package and cancellation
  • 4. Synchronization: mutexes vs channels vs WaitGroups
  • 5. The data race
  • What a depth report for Go concurrency looks like
  • Mastery vs bluffing: the pattern
HireInterviewAI Team

Written by

HireInterviewAI Team

AI Interview Research

The HireInterviewAI team builds adaptive AI technical interviews that probe candidates concept by concept and report exactly which topics they understand at depth.

hireinterviewai.com

HireInterviewAI

See what HireInterviewAI's per-concept interviews reveal

Stop hiring on a single fuzzy score. Run a live, adaptive AI technical interview that probes each concept to its ceiling and reports exactly which topics a candidate understands at depth.

See what HireInterviewAI's per-concept interviews revealExplore the developer API

Related reading

  • Role Guide

    How to interview a backend developer: a concept-by-concept guide

    How to interview a backend developer using a concept-by-concept framework — APIs, databases, concurrency, system design, and reliability — to find true depth, not vibes.

    Read
  • Security

    How to prevent cheating in technical interviews (remote era)

    To prevent cheating in technical interviews, you need proctoring plus live adaptive depth probing — static coding tests leak, but a true-ceiling probe is far harder to fake.

    Read
  • Hiring

    How an automated first round technical interview actually works

    An automated first round technical interview removes calendar drag and interviewer variance, and reports per-concept depth so engineers only spend live time on real candidates.

    Read
HireInterviewAIHireInterviewAI

AI-powered technical interviews that help engineering teams hire smarter, faster, and without bias.

Product

  • Features
  • Pricing
  • Security
  • Changelog

Company

  • About
  • Blog
  • Careers
  • Contact

Resources

  • Documentation
  • API Reference
  • Guides
  • Status

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • GDPR

© 2026 HireInterviewAI, Inc. All rights reserved.

Built for engineers who deserve better interviews

Key takeaways
  • Go concurrency is the easiest area to bluff and one of the most expensive to get wrong in production — so test it deliberately, not with one toy question.
  • Probe five things: goroutine lifecycle, channels, the context package, synchronization primitives, and the data race. Each has a clean "knows it" vs "memorized it" tell.
  • Mastery shows up as reasoning about failure modes — leaks, deadlocks, cancellation — not reciting that "channels are for communication."
  • Adaptive, per-concept probing reveals exactly where a candidate's real ceiling is instead of a single misleading score.

To test Go concurrency knowledge well, you have to get past the surface vocabulary — "goroutines are lightweight threads," "don't communicate by sharing memory" — that any candidate can recite, and probe whether they can reason about what actually goes wrong: leaks, deadlocks, races, and cancellation. This guide gives you the specific probes for five concepts and, for each, the difference between someone who knows it and someone who's bluffing confidently.

Why Go concurrency deserves its own probe

Concurrency is where Go is most powerful and most dangerous. A candidate who writes clean sequential Go can still ship a goroutine leak that takes a service down at 3 a.m., or a data race that corrupts state only under load. These bugs don't show up in a code review of the happy path — they show up in production. That makes concurrency a high-signal area to test: the gap between "looks fine" and "actually understands" is exactly the gap that costs you incidents.

It's also the easiest area to bluff. The vocabulary is memorable and the canonical examples are everywhere. So the test can't be "do you know what a goroutine is." It has to be "what happens when this one leaks, and how would you know?"

The five concepts to probe (and how)

1. Goroutine lifecycle and leaks

Probe: "You start a goroutine that reads from a channel in a loop. The function that started it returns. What happens to the goroutine?"

  • Mastery: Explains that the goroutine keeps running — Go won't garbage-collect a blocked goroutine — so if nothing closes the channel or signals it to stop, it leaks. Talks about how leaks accumulate, how you'd detect them (runtime.NumGoroutine, pprof), and how a context or a done-channel fixes it.
  • Bluffing: Says the goroutine "ends when the function ends" or "gets cleaned up automatically." This is the single most common and most revealing miss.

2. Channels: buffered, unbuffered, and closing

Probe: "When would you use an unbuffered channel versus a buffered one? What happens if you send on a closed channel? If you close it twice?"

  • Mastery: Unbuffered = synchronization handshake (send blocks until received); buffered = decoupling producer/consumer up to capacity. Knows sending on a closed channel panics, closing twice panics, and that the sender should close, never the receiver. Can explain for range over a channel and the comma-ok receive.
  • Bluffing: Treats buffered channels as "just faster," can't say who should close a channel, and doesn't know the panic conditions.

3. The context package and cancellation

Probe: "You have a request that fans out to three downstream calls. The client disconnects. How do you make sure the downstream work stops?"

  • Mastery: Threads context.Context through, derives a cancellable or timeout context, and has each goroutine select on ctx.Done(). Explains that context cancellation is cooperative — it signals, it doesn't kill — so every goroutine must check it.
  • Bluffing: Reaches for a global flag, a time.Sleep, or claims canceling the parent "automatically stops everything" without the goroutines checking Done().

4. Synchronization: mutexes vs channels vs WaitGroups

Probe: "You need 50 goroutines to update a shared counter and the main function to wait for all of them. Walk me through it."

  • Mastery: sync.WaitGroup to wait, and either a sync.Mutex / atomic around the counter or a channel funneling updates to one owner. Knows wg.Add must happen before the goroutine starts, and defer wg.Done() inside. Can articulate when a mutex is simpler than a channel.
  • Bluffing: Forgets the counter needs protection at all (the classic race), or calls wg.Add(1) inside the goroutine where it races the wg.Wait.

5. The data race

Probe: "Two goroutines increment the same int variable without a lock. Is that a bug? How would you prove it?"

  • Mastery: Yes — it's a data race; i++ is read-modify-write, not atomic. Knows the result is undefined, not just "off by a few," and immediately mentions running with the -race detector. Can explain why the race detector is a runtime, not compile-time, tool.
  • Bluffing: Says it's "probably fine for an int" or "only a problem with big data." Doesn't know -race exists.

What a depth report for Go concurrency looks like

Tested this way, a candidate doesn't get one concurrency score — they get a profile that tells you exactly what to trust and what to verify in onboarding:

Concept depth report

Go concurrency · Backend candidate

Goroutine lifecycle & leaks8/10
Channels & closing semantics7/10
Context & cancellation5/10
Mutexes / WaitGroups6/10
Data races & the -race detector3/10

This candidate reasons well about goroutine lifecycles and channels but has a real gap on the data race and cancellation — exactly the kind of thing that ships a subtle production bug. That's a hire-with-a-known-gap, not a guess. A single "concurrency: 6/10" would have hidden both the strength and the risk. (Here's why one number is useless.)

Mastery vs bluffing: the pattern

Across all five concepts, the tell is the same. Bluffers describe what things are ("a channel is a typed conduit"). People who actually know Go concurrency describe what goes wrong and how they'd catch it — leaks, deadlocks, races, and the tools (pprof, -race, NumGoroutine) that surface them. Failure-mode reasoning is the signal. Vocabulary is noise.

That's also why a fixed question can't carry the test: a strong candidate clears your first probe instantly, and you learn nothing about their ceiling. You have to keep raising difficulty — which is precisely what an adaptive interview does automatically, finding each candidate's real boundary on each concept instead of stopping at the first correct answer.

HireInterviewAI probes concepts like these adaptively across 11 domains — including Go — and reports the per-concept depth above instead of a pass/fail. See the features, read the guide to interviewing a backend developer, or see how an automated first round puts this report in your engineers' hands.

Frequently asked questions

What is the single best question to test Go concurrency?
The goroutine-leak question — "the function that started a blocked goroutine returns; what happens to the goroutine?" It instantly separates people who understand that Go won't reclaim a blocked goroutine from those who assume automatic cleanup, and it opens naturally into context and cancellation follow-ups.
How do you tell mastery from memorized answers?
Push past definitions to failure modes. Bluffers describe what a channel or goroutine is; people who know Go concurrency describe leaks, deadlocks, and races, and name the tools that catch them (-race, pprof, runtime.NumGoroutine). Reasoning about what breaks is the reliable tell.
Should I test concurrency with a live coding task or a discussion?
Both. A short live task — fix a leak or a race — shows whether they can implement; the spoken follow-ups ("why does this break, how would you detect it?") show whether they understand. Combining a code editor with voice is what makes the answer hard to fake.
How many concepts should a concurrency screen cover?
At least the five here — goroutine lifecycle, channels, context, synchronization, and the data race. Each is a distinct failure surface in production, and a candidate can be strong on some and dangerous on others, which is exactly what a per-concept report makes visible.

Test what breaks, not what they can recite — and report it per concept so you know exactly what you're hiring. See how HireInterviewAI does it, or check pricing.