Go Interview Questions for Real Production Judgment

Go interview questions should reveal whether a candidate can explain why a worker stays alive after its caller leaves, or why individually safe updates still break a capacity limit. Use these scenarios for mid-level and senior backend interviews.

TL;DR: Choose a consistent subset of these ten questions, ask for a concrete failure mechanism, then probe how the candidate would verify a repair. Use the reference answers as evidence guides and record missing evidence separately from weak evidence.

---

How to use these Go interview questions

These are fictional scenarios. Agree on the role requirements first. Prioritize lifecycle and shared state for mid-level roles; add partial failure and diagnosis for senior roles.

• Keep the core consistent. Ask candidates for the same role the same core scenarios and allow comparable time for follow-ups.
• Separate Go knowledge. Ask which Go mechanism makes the proposed design work, then which broader backend contract it protects.
• Capture evidence. Write down the interleaving, exit condition or measurement the candidate describes before assigning a rating.

Tip: Let candidates clarify whether partial data is acceptable before proposing a solution.

The broader backend developer question bank covers API and storage design. Use this bank for Go-specific reasoning; use the system design questions for a separate architecture discussion.

---

Go interview questions on goroutine ownership

1. A handler returns early while a worker sends a result. What can leak?

Reference answer: The worker can remain blocked on a send after its receiver leaves. Trace every blocking point and give request-owned work an exit path. Use select to let a blocked send observe context cancellation, propagate cancellation into the work itself, and arrange a completion signal so the owner can observe shutdown. A larger buffer only postpones the problem when production can exceed it.

• Follow-up: What if the worker is stuck inside an operation that ignores cancellation?
• Scoring evidence: Weak — Assumes returning from the handler stops its goroutines. Adequate — Identifies the blocked send and a cancellation path. Strong — Also accounts for non-cooperative work and proves worker completion.

2. Goroutine counts keep rising after traffic subsides. How do you investigate?

Reference answer: Compare goroutine profiles under comparable load and group repeated blocking stacks. Correlate those stacks with request paths, downstream latency and shutdown behavior. Growing counts are a symptom, not proof of one cause: legitimate long-lived workers also exist. Identify which owner should have ended each suspect worker, then reproduce the missing exit condition.

• Follow-up: What observation would distinguish a blocked result sender from a healthy idle worker pool?
• Scoring evidence: Weak — Declares a leak from one count or only restarts the process. Adequate — Inspects repeated blocked stacks and correlates them with traffic. Strong — Identifies ownership, reproduces the exit failure and checks recovery after load.

Key takeaway: Require an owner, an exit condition and a way to observe completion.

---

Cancellation and deadlines across request boundaries

3. An incoming request is canceled. How should downstream calls learn about it?

Reference answer: Pass the request context through the call chain to context-aware HTTP and database operations. Use context.WithTimeout to derive a child budget when a dependency needs a tighter timeout, and call its cancel function on every exit. Cancellation is cooperative: creating a context alone does not interrupt code that never observes it. Replacing the parent with a background context severs request cancellation.

• Follow-up: How would you prove the downstream operation actually stopped?
• Scoring evidence: Weak — Creates an unrelated background context for each call. Adequate — Propagates the request context and cleans up derived contexts. Strong — Verifies downstream cooperation and observes completion rather than just a canceled flag.

4. A downstream service should stop work when its caller times out. What crosses the network?

Reference answer: A Go context is not automatically serialized into another service. Bind it to the outgoing HTTP request; cancellation controls that client exchange. The receiving handler has its own request context. If the protocol carries an explicit deadline, validate and cap the remaining budget at the receiver. The server must pass its context to its own dependencies; remote cancellation is not a distributed rollback.

• Follow-up: What if the remote service committed a write before the connection closed?
• Scoring evidence: Weak — Claims the same context object travels across services. Adequate — Connects the outgoing request and receiving handler to cancellation. Strong — Separates transport cancellation, budget propagation and already-committed effects.

Key takeaway: Ask where cancellation is observed and what a completed side effect means.

---

Channels, mutexes and data-race reasoning

5. Several goroutines update one cache. Would you choose a channel or a mutex?

Reference answer: Start with ownership and the invariant. A mutex can protect a shared map when all reads and writes use the same discipline. A single owner receiving commands through a channel can serialize access, but adds queueing and shutdown decisions. Sending a pointer does not prevent its sender from mutating the pointed-to object afterward. Choose the design whose access rules your team can explain.

• Follow-up: What happens if a caller keeps a pointer to a cached value and edits it?
• Scoring evidence: Weak — Says channels make all shared data safe. Adequate — Proposes consistent locking or exclusive ownership. Strong — Traces aliases and includes reads, mutation and shutdown in the invariant.

6. A capacity check and reservation use separate locks. Can the service oversubscribe?

Reference answer: Yes: two callers can both see spare capacity before either reserves it. Protect the check and update as one decision under the same lock, or give one owner that whole decision. Race freedom for individual accesses does not establish a business invariant. Explain the interleaving and test that accepted reservations never exceed the configured capacity.

• Follow-up: Would an atomic increment alone preserve the check-and-reserve rule?
• Scoring evidence: Weak — Treats individually locked accesses as sufficient. Adequate — Shows the interleaving and protects the whole decision. Strong — Defines the invariant and handles rejection or rollback without another gap.

Key takeaway: Check the entire access rule.

---

Error wrapping and partial-failure decisions

7. A repository wraps an error. How should the caller decide whether to retry?

Reference answer: Preserve a cause with error wrapping when callers are meant to inspect it. Use errors.Is for identity and errors.As for type matching through the chain rather than message text. Classification is only the first step: retry only when the operation is safe to repeat and the remaining budget permits it. Do not expose an underlying error as part of the contract accidentally.

• Follow-up: What changes when a timeout leaves the write outcome unknown?
• Scoring evidence: Weak — Matches strings or retries every error. Adequate — Uses structured classification and checks repeatability. Strong — Separates diagnostic context, public error contract and ambiguous write outcomes.

8. One branch of a concurrent response fails. Do you cancel the other branches?

Reference answer: First establish whether the response requires every result. For a required branch failure, cancel unnecessary siblings and wait for their completion. For an optional branch, return partial data only under an explicit response contract that identifies what is missing. Neither cancellation nor an early error undoes completed side effects. Keep each branch outcome observable for diagnosis.

• Follow-up: How would you prevent incomplete data from appearing to be a complete success?
• Scoring evidence: Weak — Always fails everything or silently drops the error. Adequate — Distinguishes required and optional results and signals incompleteness. Strong — Also handles sibling completion, committed effects and diagnostic evidence.

Key takeaway: Agree what success means before deciding how failures should propagate.

---

Testing concurrent behavior and production symptoms

9. A cancellation test passes only after adding a sleep. How would you rewrite it?

Reference answer: Coordinate the relevant states explicitly: signal when the worker reaches the blocking point, cancel, then await its completion signal. Use a bounded timeout to fail a hung test, not a sleep to guess scheduling. Run the race detector on exercised concurrent paths; a clean result cannot prove unexecuted paths race-free. Check the returned outcome as well as worker termination.

• Follow-up: How will the test fail if the cancellation branch is removed?
• Scoring evidence: Weak — Only increases the sleep duration. Adequate — Uses readiness and completion signals with a failure timeout. Strong — Demonstrates sensitivity to the missing exit path and states race-detector limits.

10. Latency rises while CPU stays low. What evidence do you collect first?

Reference answer: Start with request and dependency timing, then choose evidence for the suspected wait. Goroutine profiles show blocked stacks; block and mutex profiles help investigate synchronization contention when collected appropriately. A CPU profile alone can miss time spent waiting. Compare before and during the symptom, connect the waiting stack to an owner, and validate a targeted change under comparable load.

• Follow-up: What would make you investigate a downstream connection pool instead of a mutex?
• Scoring evidence: Weak — Adds CPU capacity without investigating waits. Adequate — Collects waiting-stack and dependency evidence. Strong — Chooses a profile for the hypothesis and checks the proposed fix against comparable load.

Key takeaway: A strong diagnosis names the evidence that would disprove it.

---

Calibrate scores before the interview

These editorial anchors are illustrative, not validated performance predictors or automated hiring decisions. Set the required level by competency before interviewing.

• Weak evidence: The answer leaves the demonstrated failure possible, even after the follow-up.
• Adequate evidence: The candidate explains the mechanism and proposes a coherent repair under stated assumptions.
• Strong evidence: The candidate handles the boundary case, states a verification method and explains its limits.
• Missing evidence: You did not ask the probe or ran out of time. Record that separately rather than assigning the weakest rating.

Tip: “Add a buffer” is insufficient unless it covers every possible send or includes an exit path.

For senior roles, probe ownership, repeatability and recovery evidence. For mid-level roles, a bounded solution with explicit assumptions may meet your bar. Compare notes using our candidate scoring guide.

---

Technical references for interviewers

Check the relevant reference when calibrating an answer. These sources document Go behavior; the interview rubric is editorial guidance.

• Lifecycle and cancellation: The Go project's Pipelines and cancellation (2014) and Context (2014).
• HTTP cancellation and locks: The official HTTP request context reference and synchronization package reference, checked October 2026.
• Failure inspection: The Go project's Working with Errors in Go 1.13 (2019).
• Investigation limits: The official Data Race Detector and Diagnostics guides, checked October 2026.

Key takeaway: Finding no race in a test run and establishing a correct business invariant are different claims. Ask candidates which claim their proposed check can actually support.

---

Prepare your next Go interview

An interview preparation app for hiring managers can organize your agreed prompts and answers. Use a structured interview tool to support preparation, and keep the hiring judgment with your panel.

You can load all 10 questions from Go Production Judgment through the Import section: choose that set in the Sample Interview Data card. Sign in to your organization with a role that can update and publish questions; ask an organization admin if your role lacks either permission.

• Select your core. Choose the scenarios that match the actual role before the first candidate interview.
• Review the answers. Adapt the reference guidance to your service constraints and agreed bar.
• Plan the probes. Keep the follow-ups consistent and preserve missing evidence in your notes.

Tip: Practice with another interviewer first and agree which assumptions are acceptable.