Golang engineer behavioural interview questions

As asked

Tell me about a time you investigated a production incident in a Go service. What symptoms did you observe, what tools did you use to diagnose it, and what did you find?

Sample answer outline

A strong answer follows STAR and names specific Go tools: pprof, trace, expvar, Prometheus metrics, or log analysis. The candidate should describe the initial symptom (high latency, OOM, goroutine count spike), the diagnostic steps (collecting a profile, reading a flame graph, checking goroutine stacks), the root cause (goroutine leak, GC pressure, lock contention), and the fix with its measured impact.

Expect these follow-ups

• How did you verify the fix actually resolved the issue rather than masking it?
• What observability would you add to prevent this class of incident in the future?

As asked

Describe a time you significantly improved the performance of a Go service. How did you measure the baseline, what did you find in profiling, what changes did you make, and how did you verify the improvement?

Sample answer outline

A strong answer uses before and after benchmarks or production metrics and names the specific optimization (reducing allocations, switching from JSON to protobuf, using sync.Pool, eliminating a blocking call in a hot path). The candidate should show they did not guess: they profiled first, fixed the right bottleneck, measured again, and shipped with monitoring to confirm the improvement held under real load.

Expect these follow-ups

• How did you ensure the optimization did not change the observable behavior of the service?
• Was there a correctness tradeoff involved in the optimization?

As asked

Tell me about a concurrency bug you introduced in Go code. What was the symptom, how did you reproduce it, and what did the fix look like?

Sample answer outline

A strong answer describes a real race condition (data race, deadlock, or goroutine leak), explains why it was hard to reproduce (non-deterministic), and describes using the race detector or goleak to find it. The fix should be principled (adding a mutex, using a channel for ownership transfer, or restructuring goroutine lifetimes) rather than adding a sleep.

Expect these follow-ups

• How have you changed your code review habits to catch concurrency issues earlier?
• What does your team do to ensure the race detector runs in CI?

As asked

Tell me about a time you had to choose between two incompatible Go API designs. What were the options, what were the tradeoffs, and how did you make the decision?

Sample answer outline

A strong answer names concrete Go idioms (functional options vs config struct, error vs panic, returning interface vs concrete type) and explains the context that drove the decision (team size, external vs internal API, backward compatibility requirements). The candidate should show they considered caller ergonomics and future maintainability, not just personal preference.

Expect these follow-ups

• Looking back, was that the right call? What would you change?
• How do you handle breaking changes in a Go package that external teams depend on?

As asked

Describe a time when you helped a teammate understand a Go-specific concept they were struggling with, such as interfaces, goroutine lifetimes, or the memory model. How did you explain it and what was the outcome?

Sample answer outline

A strong answer shows the ability to explain technical concepts with concrete examples rather than abstractions. The candidate should describe diagnosing the gap in understanding (not just giving the answer), using a playground example or diagram, and checking that the person could apply the concept independently afterward.

Expect these follow-ups

• How do you handle a code review comment where you and your teammate fundamentally disagree on the Go idiomatic approach?
• What resources do you point Go beginners toward?

As asked

Describe a time a change you shipped to a Go service caused a regression in production. What happened, how did you respond, and what process changes came out of it?

Sample answer outline

A strong answer is honest about the mistake, describes a clear mitigation timeline (detect, rollback, communicate), and focuses on the system improvements (better test coverage, feature flags, canary deploys) rather than blaming teammates or tooling. The candidate should show ownership and what they personally changed in their process.

Expect these follow-ups

• How do you decide whether to rollback versus hotfix when a regression is found?
• What monitoring would have caught this regression earlier?

As asked

Tell me about a time your Go service was blocked waiting on a change from another team. How did you handle the dependency, and how did you keep making progress?

Sample answer outline

A strong answer shows practical unblocking strategies: a mock or stub of the dependent API, a feature flag to ship the integration incrementally, or escalating with clear business impact data. The candidate should show they balanced urgency with not creating technical debt and that they kept communication clear with the other team about timelines.

Expect these follow-ups

• How do you design a Go service to make it easy to swap out a real dependency for a mock in both tests and staging?
• What contract testing approach would prevent this kind of integration surprise in the future?

As asked

Tell me about a time you refactored a large or messy Go codebase. How did you plan the work, keep the service stable during refactoring, and validate that behavior did not change?

Sample answer outline

A strong answer describes a strangler fig or branch-by-abstraction approach: adding an interface layer over the old code, migrating call sites incrementally, running old and new paths in parallel with comparison tests, then deleting the old code. The candidate should mention using characterization tests to capture existing behavior before changing it and keeping diffs small for reviewability.

Expect these follow-ups

• How do you prioritize what to refactor when everything needs attention and the team has feature deadlines?
• What is your heuristic for when a piece of Go code is worth rewriting versus incrementally improving?

As asked

Tell me about a Go code review where you strongly disagreed with the feedback or approval, specifically around Go idioms such as error handling patterns, interface design, goroutine lifetime, or use of generics. How did you make your case and what was the outcome?

Sample answer outline

A strong answer shows the candidate can separate technical disagreement from ego. They should describe presenting their reasoning with evidence (benchmarks, spec references, real examples) rather than opinion, being willing to concede when the other argument was sound, and escalating appropriately when the disagreement blocked a critical change. The outcome shows they learned something from the exchange.

Expect these follow-ups

• How do your team's code review norms handle style disagreements to keep them from becoming time sinks?
• What Go linting and formatting tools does your current team use to eliminate subjective review comments?

As asked

Tell me about a time you made a deliberate decision to take on technical debt in a Go service under deadline pressure. What Go-specific shortcuts did you take (skipping error wrapping, ignoring escape analysis, deferring proper context propagation), how did you document and communicate the debt, and did you eventually pay it back?

Sample answer outline

A strong answer shows awareness that technical debt is sometimes the right call when the cost of delay exceeds the cost of the debt. The candidate should describe the deliberate decision (not just sloppiness), how they documented the debt (TODOs with context, a ticket, a design note), how they communicated it to stakeholders, and whether they followed through on paying it back. Honesty about cases where it was not paid back is valued.

Expect these follow-ups

• How do you prioritize paying down technical debt against new feature work?
• What is a piece of technical debt in your current codebase that you wish you had paid back already?

As asked

Your Go service starts with 200 MB of heap and grows to 2 GB over 12 hours under normal load, then OOMs. The GC is running but memory is not being reclaimed. Walk me through how you would diagnose this.

Sample answer outline

A strong answer starts by ruling out GC tuning (GOGC too high delaying collection) and then takes heap profiles at intervals to compare what is growing. The candidate should look at the heap profile's top allocators, check for goroutine leaks holding references, inspect for caches or maps that grow without bound, and check if the issue is a retain of large objects (like request bodies stored in error messages). The fix depends on the root cause found.

Expect these follow-ups

• How would you differentiate between a leak caused by a growing goroutine count versus a growing heap with stable goroutines?
• What GOGC value would you try first and why?

As asked

Your Go service sets a 2-second context deadline on calls to a downstream HTTP service. The call consistently takes 30 seconds and your context deadline is not being respected. What do you check and how do you fix it?

Sample answer outline

A strong answer starts by verifying that the http.Request is built with http.NewRequestWithContext so the context deadline is attached from the start, rather than building a request and calling .WithContext as an afterthought (both work, but the former is idiomatic and clearer). The candidate should check that the http.Client.Timeout field is not set to a longer value that overrides the per-request context, and confirm the downstream is not just slow to close the connection by distinguishing between net.Dialer.Timeout, ResponseHeaderTimeout, and the request context deadline. They should add explicit transport-level timeouts (ResponseHeaderTimeout, ReadHeaderTimeout) as defense in depth so no single setting can be accidentally bypassed.

Expect these follow-ups

• How do you add read and write deadlines at the TCP connection level in Go?
• How do you test that your context cancellation correctly interrupts an in-flight HTTP call?

As asked

At runtime, your Go service panics with 'nil pointer dereference' inside a method call on an interface. The interface variable is not nil. How do you explain this and how do you prevent it?

Sample answer outline

The candidate should explain that the interface has a non-nil type pointer but a nil data pointer, so the interface comparison is non-nil but the underlying concrete value is nil. Calling a method that dereferences the receiver panics. The fix is to check whether the concrete value is nil before assigning it to an interface, or to use a guard check in the method with a nil receiver. The candidate should know this is the classic 'typed nil' gotcha.

Expect these follow-ups

• Write a minimal Go example that demonstrates this exact bug.
• What linter or static analysis tool catches this pattern?

As asked

Your service's Prometheus goroutine count metric climbs from 100 to 50,000 under sustained load and never comes back down, but there is no obvious panic. How do you investigate and what are the most likely causes?

Sample answer outline

A strong answer takes a goroutine profile (/debug/pprof/goroutine) and reads the stack traces to find what the goroutines are waiting on. Common causes are: goroutines blocked on channel reads where no sender will ever arrive, goroutines waiting for a mutex that is never released, or goroutines spawned per-request without a bound. The fix depends on the root cause: close the channel at end of request lifetime, use a worker pool with a fixed bound, or ensure the context is cancelled to unblock goroutines.

Expect these follow-ups

• How would you add a test using goleak to catch this class of leak in your test suite?
• At what goroutine count does memory usage become a concern?

As asked

You maintain an internal Go package used by 15 other teams. You need to make a change that breaks the existing API. How do you plan and execute this migration without blocking all the other teams?

Sample answer outline

A strong answer describes a versioning strategy (v2 module path under Go modules), or an adapter pattern where the old function delegates to the new one with a deprecation comment. The candidate should describe using go list ./... or gopls to find all call sites, running a codemod to automate migration, coordinating a migration window with dependent teams, and not removing the old API until all consumers have migrated. They may mention using api.md or godoc deprecation markers.

Expect these follow-ups

• How do Go modules and semantic versioning affect your approach to this kind of migration?
• What is the Hyrum's Law concern here, and how do you address it?

As asked

Your Go service calls five downstream services. One of them starts responding in 10 seconds instead of 100ms. Shortly after, your entire service stops responding to all requests, including ones that do not call that service. Why does this happen and how do you fix it?

Sample answer outline

The candidate should identify resource exhaustion: every request goroutine or connection pool slot is tied up waiting for the slow service, leaving no resources for unrelated requests. The fix has two parts: an immediate circuit breaker or per-call context deadline to stop goroutines from blocking indefinitely, and a connection pool bounded per downstream so one service cannot consume all connections. The candidate should mention bulkhead patterns (separate goroutine pools per downstream) and shed-load via a circuit breaker library like gobreaker.

Expect these follow-ups

• What is a bulkhead pattern and how would you implement one in Go?
• How do you test cascade failure behavior in a Go service without taking down a real downstream?

As asked

Your Go service suddenly stops processing requests, CPU is at 0%, no panics in the logs. When you kill the process you see 'all goroutines are asleep - deadlock' in the output. Walk me through how you diagnose and prevent this.

Sample answer outline

The Go runtime detects a deadlock when all goroutines are blocked and prints the stacks. In a real service, a partial deadlock may occur where only the goroutines handling requests are stuck while background goroutines keep the runtime alive (so the runtime does not detect it automatically). The fix involves reading the goroutine stacks from pprof, identifying which mutexes or channels are involved, and tracing the lock acquisition order to find the cycle. The prevention is consistent lock ordering and using -race with deadlock testing.

Expect these follow-ups

• How do you write a test that reliably triggers a deadlock to verify your fix?
• What is the timeout pattern for acquiring a mutex to avoid deadlocks in practice?

As asked

A Go library your service depends on has a critical bug (a goroutine leak under high load). The maintainer has not responded and there is no release. What are your options and how do you choose between them?

Sample answer outline

A strong answer enumerates the options in order of preference: fork the module under a different path with the fix and replace in go.mod, use the replace directive in go.mod to point at a local patched copy, or implement a workaround in application code that avoids triggering the bug. The candidate should weigh the maintenance burden of a fork against the risk of the original bug, and mention checking if a patch exists in a PR that can be cherry-picked.

Expect these follow-ups

• How does the go.mod replace directive work and what are its limitations?
• How do you keep a fork up to date when the upstream library continues to receive security fixes?