Golang online test for a backend role — what topics actually show up?
I have a Golang technical assessment coming up in 10 days for a backend engineering position. The recruiter said it's a 90-minute online test covering Go fundamentals and some concurrency. I've been writing Go for about 18 months in my current job but mostly building REST APIs — I haven't touched channels or goroutines heavily in production.
From people I've talked to, these assessments tend to hit goroutines, channels, select statements, error handling patterns, and interface composition pretty hard. The stuff I'm weakest on is probably the concurrency model — specifically race conditions and how to use sync primitives correctly. I can write working concurrent code but I'd struggle to debug a subtle race condition under test pressure.
I've been doing about 90 minutes of practice daily for the past week, focusing on small programs that use goroutines and channels together. My plan for the next 10 days is to work through the Tour of Go sections I've skipped, do LeetCode problems in Go for the algorithmic piece, and read through the Go concurrency patterns doc.
Is there anything that typically shows up on these tests that wouldn't be obvious from the standard docs? Like are there common gotchas with slice behavior or map iteration order that assessments specifically target? I'd rather not get surprised by something I'd know in a different context.
Slice and map gotchas are absolutely fair game. Expect at least one question about what happens when you pass a slice to a function and modify it, and the map iteration order question shows up frequently because the randomness is intentional and some people don't know that.
18 months of production Go is more useful than you think. The assessments I've seen aren't trying to trick you — they're filtering for people who've never actually written Go seriously. Your real-world API experience covers like 60% of it.
Context package is worth reviewing if you haven't. A lot of Go backend assessments include a cancellation or timeout scenario and they want to see context.WithTimeout or context.WithCancel used correctly with goroutines.
The defer statement behavior in loops trips a lot of people up — especially closure capture of loop variables. If you write a goroutine inside a for loop and capture the loop var incorrectly it's a classic race condition pattern that's easy to miss under time pressure.
I was in almost the exact same spot last year, about two years of Go writing REST APIs and basically zero real concurrency experience. What I did was carve out 40 minutes every morning before work and one longer session on Sunday, and honestly that was enough. Mornings were for the small stuff you'll definitely get asked, slices vs arrays, how maps behave, nil interface gotchas, defer order, error wrapping. That stuff shows up way more than people expect and it's easy to drill in short bursts. Sundays I saved for concurrency because it needs actual focus, channels, select with timeouts, sync.WaitGroup, and the classic worker pool pattern. If you only learn one concurrency thing cold, make it the worker pool. It showed up on mine in two different forms.
One thing that saved me: I stopped trying to "study" on my lunch break and just wrote tiny programs instead, like 20 lines that fan out work to goroutines and collect results. Reading about channels didn't stick for me, writing them did. Also practice with a timer at least twice before the real thing, because 90 minutes goes fast when you're second guessing yourself. Ten days is plenty if you're consistent. You've already got the fundamentals from your day job, you're really just patching the concurrency gap.
Just passed a similar test last month so I can actually help here. The thing that surprised me most wasn't the concurrency stuff — it was how deep they went on go/questions/structs and methods, like embedding, method sets, and when pointer vs value receivers matter. I'd been writing Go for over a year and thought I knew this cold, but I'd never really had to explain *why* certain things work the way they do under the hood.
Channels and goroutines are obviously fair game, but don't neglect the basics assuming you've got them. Spend a few hours on receiver types and interface satisfaction — that's what tripped up most people I talked to after. Once that clicked for me the rest of the test felt way more manageable.
Honestly the best thing I did when prepping for my Go assessment wasn't drilling the right answers — it was figuring out why the wrong ones are wrong. Like, I'd see a question about interfaces and I'd think I got it, but then I'd miss it and just move on. Stopped doing that. Instead I'd sit with the wrong answer and trace exactly where my mental model broke. For structs and methods specifically, check out go/questions/structs and methods — I found it way more useful to work through those questions that way than to just read the docs again.
For your actual test, concurrency will show up more than you'd expect even for a REST API background. Goroutines and channels are obvious, but the stuff that trips people up is the subtler behavior — what happens with goroutine leaks, how select works with multiple cases, when you actually need a mutex versus a channel. If you've been writing Go for 18 months you probably have good intuitions, but it's worth stress-testing them by doing questions where you have to explain the failure mode, not just pick the right pattern.