Go Backend Developer Top 100 Interview Questions

Accept events quickly, validate them, buffer them in memory with strict limits and write them to durable storage in batches. Go's goroutines and channels fit this pipeline well, but the design must be explicit about backpressure and data loss.

flowchart LR
  A["HTTP handlers: validate and accept"] --> B["Bounded channel buffer"]
  B --> C["Batch writers: flush by size or time"]
  C --> D["Durable queue or storage"]
  B -->|Full| E["Reject with 503 and a retry delay"]
  C --> F["Metrics: lag, batch size, failures"]

Design points:

1. Fast acceptance: handlers validate, then try a non-blocking send to a bounded channel; when full, they reject with 503, so clients back off instead of the service running out of memory.
2. Batching: writer goroutines collect events until a batch size or a short time limit, such as 500 events or 100 ms, then write them in one call.
3. Durability choice: acknowledging before the write is fast but loses buffered events on a crash; acknowledging after the write is safer but slower.
4. Retries: writers retry failed batches with backoff, and send persistent failures to a dead-letter store.
5. Graceful shutdown: stop accepting, drain the buffer and flush the final batch before exiting.
6. Horizontal scaling: stateless instances behind a load balancer.

Workers pull jobs from a durable queue, process them with limited concurrency and acknowledge each job only after it succeeds. Failed jobs are retried with backoff, and jobs that keep failing move to a dead-letter queue for investigation.

flowchart TD
  A["Durable job queue"] --> B["Fetcher goroutine"]
  B --> C["Worker pool with N goroutines"]
  C --> D{"Job succeeded?"}
  D -->|Yes| E["Acknowledge"]
  D -->|No, attempts left| F["Requeue with backoff delay"]
  D -->|No, attempts exhausted| G["Dead-letter queue and alert"]

Key decisions:

1. Idempotent jobs: queues usually deliver at least once, so a job may run twice; use idempotency keys or check state before acting.
2. Visibility timeout: longer than the slowest job, or extended while the job runs, so another worker does not pick it up mid-processing.
3. Concurrency per job type, so slow jobs, such as report generation, cannot starve quick ones, such as emails.
4. Context per job with a deadline, so stuck jobs are cancelled.
5. Panic recovery in each worker goroutine, turning panics into failed attempts.
6. Graceful shutdown: stop fetching, finish in-flight jobs within a deadline and leave unfinished ones to be redelivered.

Monitor queue age, job duration, failure rates and dead-letter growth per job type.

The standard library's httputil.ReverseProxy forwards requests to backends and streams responses back. Around it, you add routing, authentication, rate limits, timeouts and observability, which together make a small gateway.

flowchart LR
  A["Client"] --> B["Gateway middleware: auth, rate limit, request ID"]
  B --> C["Router by path or host"]
  C --> D["ReverseProxy to orders backend"]
  C --> E["ReverseProxy to search backend"]
  D --> F["Shared transport with pooled connections"]
  E --> F

Implementation points:

1. One proxy per backend, using httputil.NewSingleHostReverseProxy or a custom Rewrite function that sets the target and forwarding headers.
2. A tuned transport: connection pools, dial and response header timeouts, shared across proxies.
3. Error handling: an ErrorHandler that returns 502 or 504 with a clear body and logs the cause.
4. Header hygiene: remove hop-by-hop headers, strip incoming internal headers that clients should not set and add forwarding information.
5. Middleware for authentication, rate limiting, request IDs and metrics per route.
6. Health-aware routing when there are several backend instances, skipping unhealthy ones.

Streaming: ReverseProxy streams bodies and supports flushing, so large downloads and server-sent events work without buffering everything in memory.

Wrap the API in one client that every part of the service shares, and enforce the provider's limits inside it: a rate limiter, a concurrency cap, timeouts, retries that respect the provider's signals and clear errors for callers.

flowchart LR
  A["Callers across the service"] --> B["Shared API client"]
  B --> C["Token bucket at the allowed rate"]
  C --> D["Concurrency limit"]
  D --> E["HTTP call with timeout"]
  E --> F{"Response"}
  F -->|429 or 503| G["Wait for the suggested delay, then retry"]
  F -->|Success| H["Return typed result"]

Design points:

1. Limit below the quota, such as 90% of the allowed rate, leaving room for clock differences and other clients sharing the same key.
2. Wait or fail: callers pass a context; the limiter waits for a token unless the context expires first.
3. Respect Retry-After and back off with jitter on rate-limit and server errors.
4. Cache responses that do not change often, which reduces calls.
5. Batch requests when the API supports it.
6. Distributed limits: if many instances share one quota, coordinate through a shared store, or divide the quota per instance.
7. Typed errors for rate limiting, so callers can decide to degrade gracefully.

Track calls, rate-limit responses and wait time as metrics.

Combine a map from keys to list elements with a doubly linked list ordered by recency, from container/list. The map finds entries in constant time, and moving an element to the front or removing the back is also constant time.

Operations:

• Get: look up the element; if present, move it to the front and return its value.
• Put: update and move an existing element, or push a new one to the front; if the size exceeds capacity, remove the back element and delete its key from the map.

Design considerations:

1. Generics: LRU[K comparable, V any] gives type safety without type assertions at call sites.
2. Concurrency: this version is not safe for concurrent use; wrap operations in a mutex, or shard the cache by key hash to reduce contention.
3. Capacity by size: for values of very different sizes, track bytes instead of counts.
4. Expiry: add a timestamp per entry if data can become stale.

Split the input among a few worker goroutines, let each count into its own local map and merge the partial maps at the end. Local maps avoid locking on every word; merging once is cheap.

Steps:

1. Send lines to workers through a channel, and close it when done.
2. Each worker counts words into a private map, then sends the map on a results channel when its input ends.
3. A coordinator closes the results channel after all workers finish.
4. Merge the partial maps, then sort by count and word for a stable output.

Why not one shared map with a mutex: every word would take the lock, so workers would mostly wait for each other. Private maps scale with the number of cores.

Considerations for real data:

• Normalize words: lowercase and strip punctuation.
• For files, read with a bufio.Scanner and send batches of lines rather than single lines, which reduces channel overhead.
• For very large vocabularies, merge partial results incrementally to limit memory.

Use a min-heap holding the current smallest element of each slice. Repeatedly pop the smallest element, append it to the output and push the next element from the same slice. With k slices and n elements in total, this takes O(n log k) time.

Using container/heap:

1. Define a slice type of items holding the value, the source slice index and the position in that slice.
2. Implement Len, Less, Swap, Push and Pop for it.
3. Initialize the heap with the first element of every non-empty slice.
4. Pop and push until the heap is empty.

Where it is used:

• Merging sorted results from several database shards or partitions.
• Combining sorted log files or event streams by timestamp.
• External sorting, where sorted chunks on disk are merged.

Variations: for streams, read the next element lazily from each source instead of holding whole slices, which keeps memory proportional to k rather than n. For only two slices, a simple two-pointer merge is faster.

Call the operation in a loop; after each failure, wait for an exponentially growing delay with random jitter, and stop when the operation succeeds, attempts run out or the context is cancelled. Waiting inside a select with ctx.Done() makes the retry loop stop immediately when the caller gives up.

Design points:

1. Exponential delay: base << attempt, capped at a maximum.
2. Jitter: randomize part of each delay, so many clients do not retry at the same moment.
3. Only retry retryable errors: pass a function, or check for error types, so validation errors fail immediately.
4. Wrap the final error with the number of attempts, and keep the last cause inspectable with %w.
5. Return the context error when cancelled, combined with the last operation error, so callers see both.

Where it belongs: in clients for remote calls, and only at one layer of the call chain, to avoid multiplying retries.

Store values with an expiry time in a map protected by a mutex, treat expired entries as missing on reads and remove them periodically so memory does not grow forever. Inject the clock, so expiry can be tested without waiting.

Operations:

• Set: store the value with now + ttl.
• Get: return the value only if it exists and has not expired; expired entries are reported as missing.
• Cleanup: scan and delete expired entries, run by a background goroutine on a ticker that stops with a context.

Design considerations:

1. Lock granularity: a single mutex is simple and usually fast enough; shard by key hash under heavy contention.
2. Memory bounds: expiry alone does not cap size; add a maximum entry count with eviction for untrusted keys.
3. Load coalescing: when a missing key is expensive to load, let one goroutine load it while others wait.
4. Copying values: returning pointers to cached data lets callers modify shared state; store immutable values or return copies.

Read the file with a bufio.Scanner, which returns one line at a time, parse each line strictly, update per-key statistics in a map and print the results sorted by key. Memory stays proportional to the number of distinct keys, not the file size.

Steps:

1. Open the file, and defer file.Close().
2. Create a scanner; raise its buffer limit with scanner.Buffer if lines can exceed the default of 64 KB.
3. Split each line into fields and convert numbers with strconv, counting lines that fail instead of crashing.
4. Accumulate counts, sums and errors per key.
5. Check scanner.Err() after the loop; a read error otherwise looks like a short file.
6. Sort keys for stable output.

Scaling further: for compressed files, wrap the reader with a decompressor; for many files, process them in parallel with a worker pool and merge the maps.

Write each result into a preallocated slice at its input's index, limit concurrency with a semaphore channel and cancel the remaining work on the first error. Writing by index preserves order without sorting, and each goroutine touches only its own slot, so no lock is needed for the results.

Design points:

1. Generic signature: ParallelMap[T, U any](ctx, in []T, limit int, f func(context.Context, T) (U, error)) ([]U, error).
2. Semaphore: acquire a slot before starting each goroutine, release it when the goroutine ends.
3. First error wins: record it once with sync.Once, cancel the context and stop starting new work.
4. Wait for everything before returning, so no goroutine writes to the slice afterwards.
5. Pass the context to f, so in-flight work can stop early after a failure.

Use cases: calling an external service for each item in a list, resizing images or validating records, with a concurrency limit that protects the dependency.

Follow semantic versioning strictly: add features in minor versions, fix bugs in patch versions and change the import path for breaking changes. Go's module system enforces the last rule: a new major version must be imported as a different path, such as /v2.

Adding without breaking:

1. New functions and types are always safe to add.
2. Option structs or functional options let you add configuration without changing function signatures.
3. New methods on interfaces break implementers; add a new interface, and check for it with a type assertion, instead of extending an existing one.
4. Struct fields can be added, but callers using unkeyed struct literals will break; document that keyed literals are expected.

Deprecating:

• Mark old identifiers with a Deprecated: comment explaining the replacement, which tools show to users.
• Keep deprecated code working until the next major version.

Releasing a major version:

• Create the /v2 module path, update internal imports and publish migration notes.
• Consider keeping v1 maintained for security fixes for a while.
• Provide adapters where possible, so users can migrate gradually.

Run tests against example user code in continuous integration to catch accidental breaking changes.

Combine secure defaults in the HTTP server, careful handling of input and secrets, strong authentication and a well-maintained dependency set. Go's standard library is a strong foundation, but secure configuration is still your job.

HTTP layer:

• Set server timeouts, especially ReadHeaderTimeout, and request body limits.
• Serve TLS with modern settings, or terminate it at a trusted proxy.
• Set security headers and strict CORS rules for browser clients.

Input and output:

• Validate every input, decode JSON strictly and use parameterized queries.
• Use html/template for HTML, which escapes output automatically, never text/template.
• Clean file paths from users, and serve files from an os.Root or fs.FS so requests cannot escape the intended directory.

Secrets and cryptography:

1. Use crypto/rand for tokens and keys, never math/rand.
2. Hash passwords with a slow password hashing function from the extended crypto packages.
3. Compare secrets with crypto/subtle.ConstantTimeCompare.
4. Load secrets from the environment or a secret store, and never log them.

Dependencies and builds: run the official vulnerability checker in continuous integration, keep Go and modules updated and build with -trimpath from a clean environment.

cgo lets Go code call C libraries. It is useful when a mature C library has no Go equivalent, but it gives up several of Go's main advantages.

When cgo is reasonable:

1. Required system libraries, such as hardware drivers or platform-specific features.
2. Performance-critical C libraries without a good Go alternative, called in large chunks of work rather than many tiny calls.

How to limit the cost: isolate cgo in one small package behind a Go interface, build with CGO_ENABLED=0 everywhere else and test the boundary carefully, especially memory ownership and pointer-passing rules.

Go cross-compiles natively: set GOOS and GOARCH and build, with no extra toolchain needed for pure Go code. A release pipeline builds each target, embeds version information, produces checksums and signs the artifacts.

Build steps:

1. Targets: one build per pair of GOOS, the operating system, and GOARCH, the processor architecture, such as amd64 and arm64; go tool dist list prints every supported pair.
2. Static builds: CGO_ENABLED=0 for portable binaries.
3. Reproducibility: -trimpath, a pinned Go version and go mod download from verified checksums, so the same commit produces the same binary.
4. Version information: Go embeds module and version control details automatically, readable with go version -m or runtime/debug.ReadBuildInfo; -ldflags "-X main.version=..." can set custom values.

Release artifacts:

• Archives per platform, a checksum file and signatures.
• Container images for server deployments, built for several architectures.
• Release notes generated from commits or changelog entries.

Testing: run tests on each target architecture where possible, since rare issues, such as alignment of 64-bit atomic values on 32-bit platforms, only appear there.

Go has a strong compatibility promise, so upgrades are usually smooth, but behavior can still change in edge cases. Upgrade deliberately: read the release notes, update the toolchain in one place, run all tests and roll out gradually.

1. Read the release notes, looking at changes to the standard library packages you use and new GODEBUG settings.
2. Update the go and toolchain lines in go.mod; the go line also controls language semantics, such as per-iteration loop variables from Go 1.22.
3. Run tests with -race, linters and the vulnerability checker with the new version.
4. Benchmark hot paths, since compiler and runtime changes can shift performance in either direction.
5. Roll out gradually: a canary, then the rest, watching latency, memory and garbage collection metrics.
6. Use GODEBUG to restore old behavior temporarily if a change breaks something, while you fix the code.

Keep current: each Go release is supported until two newer major releases exist, so upgrading every six months or so avoids large jumps and keeps security fixes flowing.

Many Go bugs come from a small set of patterns that compile cleanly but fail at run time or under load. Reviewing for these specifically catches most of them before production.

Checklist:

1. Errors: ignored with _, logged and returned twice, or wrapped with %v where callers need %w.
2. Goroutines: every goroutine has an exit path, owners wait for them and panics are recovered where needed.
3. Context: passed as the first parameter, used in all blocking calls and never stored in structs.
4. Concurrency: shared maps and slices protected, and locks never held during input and output.
5. Resources: response bodies, rows and files closed, and defer not used inside long loops.
6. Nil handling: writes to nil maps, typed nil errors returned through interfaces and nil pointer dereferences.
7. Slices: append results assigned, and shared backing arrays understood.
8. Timeouts: HTTP servers and clients configured, not the zero values.
9. Tests: table-driven cases for edge conditions, and the race detector in continuous integration.

Let tools do the routine work: gofmt, go vet and a standard linter configuration in continuous integration, so human review focuses on design and logic.

Interview tip: naming two or three concrete bugs you caught in review, and the lint rule you added afterwards, is far more convincing than listing principles.

Choose by the workload, the team and the ecosystem the service depends on. Go is a strong default for network services, but it is not the best fit for every project.

Questions that decide it:

1. Which libraries does the service need, and do good Go versions exist?
2. What does the team already know and operate well?
3. Are startup time, memory use and deployment simplicity important?
4. Is the work mostly concurrent input and output, where Go excels, or heavy numeric computing, where specialized ecosystems lead?

Consistency matters too: running many languages raises the cost of tooling, libraries and on-call knowledge.

Tell one project as a story about a service and its trade-offs: what it did, what you built, the hardest problem and the measured outcome. Interviewers want evidence that you understand Go's runtime and concurrency, not a list of packages.

1. Context: what the service did, its traffic and its users.
2. Your role: what you designed or built personally.
3. Design choices: how you structured packages, handled concurrency, managed database access and configured timeouts, and why.
4. A hard problem: a goroutine leak, a latency issue, a data race or a scaling limit, and the profiles, traces or tests that revealed the cause.
5. Quality: tests, the race detector, benchmarks and how deployments were made safe.
6. Results: numbers such as "p99 latency fell from 400 ms to 90 ms" or "memory dropped by 60% after removing per-request allocations".
7. Reflection: what you would change now.

What the interviewer is listening for:

• Comfort with goroutines, channels, contexts and their failure modes.
• Data-driven debugging with profiles and metrics.
• Simple, explicit design choices that fit Go's style.

Interview tip: be ready to sketch the goroutine and channel structure of your service on a whiteboard, since many follow-up questions start there.

Describe the incident in order, from detection to prevention, and highlight the Go-specific evidence you used: goroutine dumps, heap and processor profiles, execution traces and runtime metrics.

1. Detection: the alert or report, and how quickly it fired.
2. Impact: what users experienced and for how long.
3. Mitigation: rollback, restart, traffic shift or feature switch, and why you chose it.
4. Diagnosis: for example, a goroutine profile showing thousands of goroutines blocked on a channel send, or a heap profile pointing to an unbounded map.
5. Root cause and contributing factors: such as a missing timeout or a context that was not passed through.
6. Fix: the code change, plus tests that reproduce the problem.
7. Prevention: new alerts on goroutine count or heap growth, lint rules, review checklist items or load tests.

What the interviewer is listening for:

• Mitigating first and investigating with evidence, not guesses.
• Understanding of how Go programs fail under load.
• Blameless, system-focused language.
• Lasting improvements, verified after the fix.