Error Handling and Defensive Programming Questions

Direct answer
context.Context carries a deadline and a cancellation signal through a call chain; an HTTP client that respects it will abort the in-flight request the instant the context is canceled or its deadline passes, instead of blocking until the OS-level socket timeout. Wrapping the returned error with %w preserves the original error so a caller can still test for it, while adding human-readable context about what operation failed.

Structured elaboration

• %w (added in Go 1.13) creates a wrapped error whose Unwrap() method returns the original error, unlike %v or %s which just stringify it into a new, opaque error.
• errors.Is(err, target) walks the Unwrap() chain checking for exact sentinel-error matches (errors.Is(err, context.DeadlineExceeded)).
• errors.As(err, &target) walks the same chain looking for the first error whose type matches, letting the caller extract a typed error (e.g., a custom *HTTPStatusError) even though it's several wraps deep.

Worked example

func FetchWithContext(ctx context.Context, url string) (body []byte, err error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, fmt.Errorf("fetch %s: build request: %w", url, err)
    }
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, fmt.Errorf("fetch %s: %w", url, err)
    }
    defer resp.Body.Close()
    if resp.StatusCode >= 400 {
        return nil, fmt.Errorf("fetch %s: %w", url, &HTTPStatusError{Code: resp.StatusCode})
    }
    body, err = io.ReadAll(resp.Body)
    if err != nil {
        return nil, fmt.Errorf("fetch %s: read body: %w", url, err)
    }
    return body, nil
}

// Caller:
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
_, err := FetchWithContext(ctx, "https://example.com")
if errors.Is(err, context.DeadlineExceeded) {
    // specifically a timeout: safe to retry with backoff
}
var statusErr *HTTPStatusError
if errors.As(err, &statusErr) && statusErr.Code == 429 {
    // specifically rate-limited: back off longer
}

A caller that only had a plain err.Error() string could not reliably distinguish a timeout from a 429 without fragile string matching; errors.Is/errors.As make that distinction robust even after two layers of %w wrapping.

Trade-offs and pitfalls
Wrapping with %w at every single call site can produce noisy, redundant messages ("fetch: fetch: fetch: connection refused") if every layer adds the same prefix; add context only when a layer knows something the layer above doesn't (which URL, which retry attempt). A common bug is passing context.Background() deep in a call chain instead of threading the caller's ctx through, which silently defeats the whole timeout/cancellation mechanism: go vet and code review are the practical defenses, since the compiler won't catch it.

Direct answer
A strong STAR answer to 'a time you found and fixed a silently-failing bug' names the concrete detection method (how you noticed something was wrong despite no error being raised), the specific fix (not just 'I added error handling' but what kind and why), and, critically, the systemic change that prevents the SAME class of silent failure from recurring, not just this one instance.

Structured elaboration

• Situation: set up the context concisely (what system, what was the user-visible or business-visible symptom that eventually surfaced, even though no exception or alert had fired).
• Task: what you were specifically responsible for or chose to investigate, and why it mattered.
• Action: the concrete detective work (how did you trace a symptom back to a swallowed exception with no log trail), the specific code change (not vague: which exception types you now catch explicitly, what you log, whether you re-raise or recover), and the systemic prevention (a new test, a new metric, a broader sweep for the same anti-pattern elsewhere in the codebase).
• Convincing others to accept the defensive change: name the actual pushback you got (a reviewer worried the extra validation would add latency, or that raising instead of swallowing would be 'too disruptive' to existing callers) and how you addressed it concretely, whether by showing the cost of NOT fixing it (the weeks of undetected bad data) outweighed the marginal slowdown, by scoping the change narrowly so the velocity cost was small, or by walking a skeptical reviewer through the actual failure mode together; 'I added the check and nobody objected' is a much weaker story than genuinely winning over a skeptical teammate.
• Result: quantify where possible (how long the bug had been silently occurring before detection, what changed after the fix, e.g. 'the equivalent class of bug now surfaces within minutes via the new metric, versus the weeks it took to notice this one').
• What you learned: a genuine, specific lesson (not a platitude), ideally one that changed how you approach code review or design going forward (e.g., 'I now specifically look for bare except blocks in review, having learned how expensive they are to debug after the fact').

Worked example (a filled skeleton, illustrating the level of specificity expected)
"S: A weekly reporting pipeline was quietly producing undercounted totals for about three weeks before a stakeholder noticed the numbers looked off. T: I was asked to investigate why the totals seemed low. A: I traced it to a try/except: pass block that had been silently swallowing a schema-validation error on about 8% of incoming records; a reviewer initially pushed back that failing loudly instead of swallowing would risk new alert noise, so I scoped the fix to log-and-continue with a metric rather than a hard failure, which addressed the concern while still surfacing the problem; I fixed the immediate bug (the schema had drifted and the validation was too strict), added a metric tracking the record-rejection rate so a spike would be visible on a dashboard going forward, and grepped the rest of the codebase for the same bare-except pattern, finding and fixing four more instances. R: the specific bug was corrected and backfilled; the new metric caught a SIMILAR issue two months later within an hour, versus the three weeks it took to notice this one. L: I learned that a swallowed exception's cost isn't the bug itself, it's the TIME TO DETECTION, and that a metric is a much more reliable detection mechanism than hoping someone notices a downstream symptom."

Trade-offs and pitfalls
The most common weakness in a real candidate's answer to this question is stopping at 'I fixed the bug' without describing the SYSTEMIC prevention step (the new metric, the codebase-wide sweep); an interviewer specifically listens for that second layer, since it's what distinguishes someone who fixes symptoms from someone who addresses root causes and prevents recurrence.

Direct answer
Detect and prevent intermittent memory growth in a long-running Java service with a combination of code-level discipline (try-with-resources for every closeable, careful use of static/long-lived collections that can accidentally retain references) and JVM-level tooling (heap dumps via jmap, analysis via jvisualvm or a dedicated heap analyzer, GC log analysis) to identify exactly what's being retained and why.

Structured elaboration

• try-with-resources: as covered in the resource-cleanup survivors, ensures a Closeable/AutoCloseable resource is released on every exit path, but this specifically prevents LEAKED RESOURCE HANDLES (file descriptors, connections), not necessarily plain memory retention through ordinary object references, which is a different (though related) class of leak.
• Reference types and accidental retention: a static collection (a cache, a listener list) that's added to but never pruned is the classic Java memory-leak pattern; WeakReference/WeakHashMap can help for genuinely cache-like use cases where an entry should be reclaimable once nothing else references its key, but reaching for weak references as a blanket fix without understanding WHY the strong reference was retained in the first place often just delays the same underlying design problem.
• Leak-detection libraries: tools that track allocation-vs-deallocation patterns at a finer grain than manual heap-dump comparison (useful for catching a leak early, in a test environment, before it ever reaches production scale).
• Capturing and analyzing heap dumps with jmap/jvisualvm: jmap -dump:live,format=b,file=heap.bin <pid> captures a heap snapshot; jvisualvm (or a similar analyzer) opens it and shows the RETENTION GRAPH for the largest object groups, specifically 'what is holding a reference to this object, preventing GC from collecting it', which is the actual answer you need, not just 'this object exists in the dump'.
• Correct resource management example: try (Connection conn = dataSource.getConnection(); PreparedStatement stmt = conn.prepareStatement(sql)) { ... } guarantees both are closed on every exit path, including an exception thrown by the statement execution itself.

Worked example
Two heap dumps taken 24 hours apart (under otherwise-similar load) are diffed; the diff shows a specific HashMap growing from 10,000 to 4 million entries, all instances of a SessionContext class; the retention graph traces this map back to a static field on a SessionManager class that adds an entry per user session but has no corresponding removal logic on session end, which is the root cause; the fix adds explicit removal on session termination (and, as a defensive backstop, converts the map to use WeakReference values so an unexpectedly-missed removal path degrades to 'eventually reclaimable' rather than 'permanently leaked').

Trade-offs and pitfalls
Taking a heap dump on a live production instance can itself cause a noticeable pause (stop-the-world for the dump duration, proportional to heap size), so this diagnostic step has a real production cost and should typically be done on a single canary/isolated instance rather than the whole fleet simultaneously, or scheduled during a lower-traffic window when the brief pause is least disruptive.

Direct answer
An end-to-end observability plan captures structured error events with enough context (service, correlation id, stack, severity, user impact) to aggregate, deduplicate, and alert on spikes automatically, and correlates logs, metrics, and traces so an operator can build evidence of actual CAUSATION (this specific downstream call caused this specific failure) rather than merely noticing two things happened around the same time.

Structured elaboration

• Capturing structured error events: every error carries a consistent schema (see the structured-error-logging survivor) so downstream tooling can aggregate across services without per-service custom parsing.
• Aggregation, deduplication, sampling: at fleet scale, the SAME underlying bug can generate millions of nearly-identical error events; group by a fingerprint (error type + top stack frame, not the full message which may include variable data) so the dashboard shows 'this ONE bug fired 40,000 times' rather than 40,000 indistinguishable rows, and sample full detail (keep every Nth full trace, or sample proportional to rarity) to bound storage cost while preserving enough detail to debug.
• Correlating traces, logs, and metrics: a metric shows THAT error rate spiked; a trace shows the exact call path and timing for one specific failing request; a log line shows the exact exception and context; tying all three together via a shared trace/correlation id lets you go from 'error rate spiked at 2:14pm' (metric) to 'here are 10 example full traces from that window' (traces) to 'here's the exact exception in each' (logs), which is what actually distinguishes causation from mere correlation: if every sampled trace from the spike window shows the SAME downstream call timing out right before the error, that's evidence of causation a metric spike alone can't provide.
• Avoiding alert fatigue: alert on the AGGREGATED, deduplicated signal (a new error fingerprint appearing, or an existing one's rate crossing a threshold) rather than per-occurrence, and tie alert severity to measured user impact (how many users/requests affected), not just raw error count.

Worked example
A sudden spike in PaymentGatewayTimeout errors: the metric dashboard shows the error-rate spike starting at 2:14pm; the dedup/aggregation layer confirms it's ONE fingerprint (not many different bugs), affecting roughly 3% of checkout requests; pulling 10 sampled full traces from that window shows every one of them has an unusually slow (4s+) call to the SAME downstream payment provider endpoint immediately before the timeout, which is the concrete evidence connecting the SYMPTOM (elevated error rate) to a specific ROOT CAUSE (the payment provider), rather than a coincidental correlation with, say, a deploy that happened around the same time but touched unrelated code.

Trade-offs and pitfalls
Sampling trades completeness for cost: if you sample too aggressively, the rare-but-severe error that only fires 3 times a day might never get a full trace captured, exactly when you'd most want the detail; bias sampling toward capturing at least SOME full detail for every distinct error fingerprint (not just a flat percentage of all events), so rare errors aren't systematically under-sampled relative to common ones.

Direct answer
Combine circuit breakers (stop calling a specific failing dependency) with bulkheads (isolate resources per dependency or per client so one slow/failing one can't starve the others) by giving each downstream dependency its own dedicated thread pool or connection pool with its own circuit breaker, so a single misbehaving dependency can exhaust only ITS OWN bulkhead, not the shared resource pool every other request also needs.

Structured elaboration

• Where to place bulkheads: at the boundary between your service and each distinct downstream dependency (a separate thread pool or connection pool per dependency, sized to that dependency's expected concurrency), and optionally per-client if a single noisy client can otherwise starve capacity meant for everyone else.
• Per-client or per-route limits: cap how many concurrent in-flight requests any one client or route can occupy within the shared pool, so one route's traffic spike degrades only that route, not the whole service.
• Emergency fallback behavior: when a bulkhead is exhausted (its pool is full) or its breaker is open, fail fast with a specific 'this dependency is unavailable' response rather than queueing indefinitely and blocking the calling thread, which would let the starvation propagate upstream anyway.
• Metrics to monitor: per-bulkhead pool utilization (how close to exhausted), per-bulkhead breaker state, and per-bulkhead rejection rate, so an operator can see WHICH dependency is the problem, not just 'the service is degraded'.
• Preventing healthy requests from starving: because each dependency has its OWN pool, a request that only touches a healthy dependency never competes for threads/connections with requests stuck waiting on the unhealthy one; without bulkheads, a single shared thread pool means slow calls to a failing dependency can consume every available thread, starving requests that don't even touch that dependency.

Worked example
A service calls three downstream dependencies (a payment provider, a recommendation service, an inventory service) from a single shared thread pool of 100 threads. The recommendation service starts hanging (not failing outright, just slow); within seconds, all 100 threads are blocked waiting on recommendation calls, and checkout requests that need only payment and inventory (both healthy) can't get a thread either, so the whole service appears down. With bulkheads (30 threads dedicated to each dependency, 10 spare), the recommendation service's slowness exhausts only its own 30-thread pool; payment and inventory continue serving normally with their own untouched pools, and the recommendation-specific circuit breaker trips to fail fast once its own pool starts showing sustained failures/timeouts.

Trade-offs and pitfalls
Bulkheads trade away pooled efficiency: a shared pool can flex capacity to whichever dependency needs it most at a given moment, while a partitioned pool leaves capacity idle in one bulkhead even while another is starved, so sizing each bulkhead correctly (based on measured per-dependency traffic and latency, not a guess) matters a lot. Too many fine-grained bulkheads (one per individual API endpoint rather than per genuinely-distinct dependency) fragments capacity so much that normal traffic variance alone causes false-positive exhaustion; partition at the level of genuinely independent failure domains, not arbitrarily.