Golang Interview Questions

You have probably found a list of fifty Go questions and no sense of which ones an interviewer will actually reach for. This section groups them by what the interviewer is checking, so the list becomes a study order. Four groups cover nearly everything asked in a screening round.

• Concurrency: what a goroutine costs, how select chooses between ready cases, what happens when you send on a closed channel, how context cancellation propagates, and when a sync.WaitGroup is the wrong tool.
• Types and interfaces: implicit interface satisfaction, why a nil pointer stored in an interface is not a nil interface, pointer versus value receivers, and embedding versus inheritance.
• Memory and data structures: slice length against capacity, what append does when it reallocates, why two slices can share an array, and map iteration order.
• Tooling and runtime: what the race detector can and cannot find, how the garbage collector affects latency, and how you would profile a service that got slower after a release.

Role-specific banks for other languages sit in the question bank hub, but the Go list is unusually concentrated: get concurrency right and you have covered most of the round.

They test whether you reason about blocking, not whether you have memorized the syntax for starting a goroutine.

Take the most common screening question in the language: here is a function that starts several goroutines writing to one unbuffered channel, with a read loop after them. Why does it hang? The answer an interviewer wants is not "add a buffer". It is that an unbuffered send blocks until a receiver is ready, the receiver never starts because the sends are sequential in the same function, and the fix is either a separate goroutine for the reads or a buffered channel sized to the writes. One of those is correct and one hides the bug.

The same pattern repeats across the other favorites:

• A worker pool that never exits, because nobody closes the jobs channel.
• A loop variable captured by goroutines, and what changed about that in recent Go versions.
• A select with a default case that turns a blocking read into a busy loop.

In every case the question behind the question is the same: name what blocks, and name what unblocks it.

Writing correct Go and narrating correct Go are different skills, and interviews only measure the second one.

A concrete case: a platform engineer interviewing for a senior Go role could fix a data race in the editor within a minute. Asked to say what the race detector had actually observed, they went quiet, then guessed. The knowledge was there. The sentence was not, because they had spent two years reading race reports alone and had never once explained one to another person.

What closes that gap:

• Take one buggy snippet and say the diagnosis out loud before touching the keyboard.
• Use the vocabulary deliberately: happens-before, escape analysis, receiver, capacity. Interviewers listen for these words.
• Answer against a timer, since Go screens are short and rambling costs you the follow-up.
• Run the same problem again a day later and see whether the sentence is shorter.

The SubcueAI mock interview runs those rounds as spoken questions and spoken answers, which is the format the gap actually lives in.

It fits in the conversational half and not in the editor.

A Go loop usually has two kinds of round. One is a shared editor where you write and run code. The other is a discussion of your experience: a service you built, a bug you chased, why you chose channels over a mutex. In that second kind, on Zoom, Google Meet, or Microsoft Teams, a live assistant transcribes the interviewer and puts a structure on screen while you are still choosing your first sentence. SubcueAI does this from a native macOS or Windows app with a local floating overlay, and from a browser extension side panel that captures the meeting tab's audio. No bot joins the call, and nothing is injected into the meeting page.

The limits are firm:

• A shared editor round is a craft test. Nothing about an overlay makes you able to reason about capacity growth.
• Screen sharing puts the overlay in the shared frame unless you moved it off first.
• Proctored assessments and locked-down coding platforms are out of scope. The security page names those contexts directly.