What Go tool detects data races and how do you invoke it?
This tests Go's built-in race detector. A strong answer names the -race flag, notes it instruments memory accesses to catch concurrent unsynchronized reads/writes, and shows go test -race. A red flag is confusing it with static analysis or external tools.
WHAT THIS TESTS: This question probes whether you know Go ships a dynamic race detector integrated directly into the toolchain, not just whether you can write concurrent code. Interviewers want to see you understand runtime instrumentation, know the exact CLI invocation, and recognize the performance and usability implications of using it in practice.
A GOOD ANSWER COVERS: First, name the -race flag and state it is built into the go command. Second, explain that it instruments memory accesses at compile time to detect when two goroutines access the same variable concurrently and at least one access is a write. Third, give the exact test invocation: go test -race mypkg. Fourth, mention that the race build tag is defined when -race is used, so tests can be excluded if they are too slow or intentionally racy under detection. Fifth, note the GORACE environment variable for tuning behavior such as log_path, halt_on_error, or strip_path_prefix.
COMMON WRONG ANSWERS: Confusing the race detector with static analysis tools like go vet. Claiming you need a third-party library or external sanitizer. Forgetting that -race applies to run, build, and install as well as test. Saying you would add manual mutexes everywhere without first reproducing the race with the detector. Ignoring the runtime cost, which is typically 5x to 10x slower execution and 10x memory usage, making it unsuitable for production always-on use.
LIKELY FOLLOW-UPS: How does the race detector work under the hood? What is the performance penalty and when would you run it? How do you handle a race report once you get one? Can you use -race in production? How would you exclude a test that is too slow under the race detector? What is the difference between a data race and a race condition?
ONE CONCRETE EXAMPLE: Suppose you have a package with a shared counter incremented by multiple goroutines without synchronization. You would run go test -race ./... to execute the package tests. If the detector finds a race, it prints a WARNING: DATA RACE message with stack traces for both the read and write goroutines plus their creation stacks. You would then protect the counter with sync/atomic or a sync.Mutex, rerun go test -race, and verify the warning disappears.
Read the original → go.dev
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.