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.