The interviewer says: "Code a rate limiter in Go."

You know the theory. You've read the blog posts. But under interview pressure, your goroutines leak, your mutex deadlocks, and your tests race.

Most candidates fail Go concurrency questions not because they don't understand the concept — but because they've never built it themselves.

Your interview prep in 3 steps

• Pick a pattern. You get a Go interface — implement it in your editor.
• Run the tests. Your code hits concurrent load, race conditions, edge cases.
• See what broke and why. Fix it. Run again until all cases pass.

By the time you walk into the interview, you've already built every pattern they can ask about.

The patterns interviewers actually ask

• Rate Limiter — "How would you protect an API from abuse?"
• Read-through Cache — "Design a caching layer with TTL and eviction"
• Circuit Breaker — "How do you handle failing dependencies?"
• Request Batching — "Optimize N database calls into one"
• Scatter-Gather — "Query 5 services in parallel, return fastest"
• Single-flight — "Deduplicate concurrent requests for the same key"

Each pattern: real Go interface, concurrent test suite, edge cases you won't think of on your own.

Frequently Asked Questions