Go Developer interview question
Why are concurrent map writes unsafe in Go?
Regular Go maps are not safe for concurrent writes. Concurrent mutation can trigger a runtime panic; protect a map with sync.Mutex or sync.RWMutex, partition ownership, or use sync.Map only when its access pattern fits.
Direct answer
What a strong answer covers
How it works
The built-in map is not synchronised. The runtime detects some concurrent writes and aborts the program with a fatal error rather than a recoverable panic, and unsynchronised access that escapes detection can corrupt the internal buckets. A read concurrent with a write is also a data race, so the rule covers every access pattern, not only write-write.
Example
A cache updated by many goroutines can use a mutex around read-modify-write; never rely on a map read being harmless when another goroutine may write. Run the race detector in CI so a missing lock is reported by go test -race before it becomes a production crash.
Common mistakes
- Believing that reads are safe as long as only one goroutine writes.
- Reaching for sync.Map by default instead of a mutex around an ordinary map.
- Copying a map to pass it to another goroutine while still mutating the original.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.