Problem Solving and Structured Thinking Questions

Focuses on the general capacity to approach an unfamiliar or ambiguous problem in a disciplined way, independent of the underlying domain. Core skills include clarifying the actual problem and its constraints before acting, decomposing it into smaller subproblems, recognizing patterns from prior experience, choosing among competing approaches, developing and testing a solution incrementally, weighing trade offs such as cost, risk, effort and correctness, reasoning about edge cases and failure modes, and communicating the thought process clearly to others. In technical roles this often shows up as algorithmic reasoning (selecting data structures, estimating time and space complexity) and systematic debugging. In non-technical roles it shows up as issue-tree style decomposition, hypothesis-driven analysis, and structured decision frameworks under ambiguity. The topic is about the reasoning process itself, not any single domain's toolkit.

EasyTechnical

69 practiced

Explain the difference between deterministic and probabilistic algorithms and give SRE-relevant examples where probabilistic data structures (like Bloom filters, HyperLogLog) are preferred. Discuss error modes, memory tradeoffs, and how you would monitor and test correctness in production.

MediumSystem Design

97 practiced

Design an alerting system for a large SRE organization that reduces pager fatigue by incorporating alert grouping, deduplication, suppression via SLO-based error budgets, and automated escalation. Describe the components, data flow, how alerts are deduplicated and grouped, how SLO suppression works, and how the system scales to ~100k alerts/day.

Sample Answer

Requirements:- Ingest ~100k alerts/day with low latency- Reduce pager fatigue via grouping, dedup, SLO-based suppression/error-budget-aware routing, automated escalation/notification- Provide observability, audit trail, configurable policies per-service

High-level architecture:- Alert Producers → Ingest Layer (Kafka) → Normalizer & Enricher → Dedup/Grouping Engine → SLO Engine → Routing & Suppression → Incident Orchestrator → Notification Channels & On-call Schedule DB → Dashboard / Audit Logs

Components & responsibilities:- Ingest (Kafka): durable, partitioned buffer to handle spikes.- Normalizer/Enricher: unify schemas, add metadata (service, priority, runbook, SLO id).- Deduplication: time-windowed canonicalization (hash on signature fields: error type + stack + service + resource). Use Redis/Bigtable TTL store for seen signatures; collapse duplicates into one active alert with a counter and last-seen timestamp.- Grouping: multi-key grouping (service, region, fault-domain, deployment) via rules; create parent incidents that reference child alerts. Use rules engine (e.g., Rego) to define grouping heuristics and thresholds (e.g., >X distinct hosts in Y minutes).- SLO Engine: maintains per-service SLOs and real-time error budget burn rates (ingest metrics from metric store). When error budget is exhausted or burning rapidly, SLO Engine signals suppression or lower-severity routing. If budget is healthy, alerts go to on-call immediately. - Suppression policy: automatic suppression only for non-actionable alerts (informational or ones tied to known progressive degradations). Suppression is temporary, recorded, and reversible. Alert counts still logged for postmortem.- Routing & Suppression: combines dedup/grouping and SLO decisions to decide destination: page immediate, create ticket, post to channel, or suppress. Tag rationale in metadata.- Incident Orchestrator: state machine managing lifecycle, automated escalation (escalate if ack timeout), runbook execution (automated playbooks), and paging escalation chains. Stores history in DB.- Notification adapters: PagerDuty/Slack/Email/SMS with rate limits and batching.

Data flow & dedup/group example:1) Multiple hosts emit identical OOM errors → Normalizer computes signature -> Dedup store shows existing signature -> Increment counter, update enrichment, attach to existing incident.2) Different errors in same deployment causing increased error rate -> Grouping rules detect correlated noise and create parent incident "deployment X high error rate" aggregating multiple alert types.

Scaling to 100k/day:- Use partitioned Kafka + horizontally scalable stateless normalizers.- Dedup store: Redis Cluster or Bigtable with TTLs for signatures; sharded by service hash.- Grouping engine as stream processor (Flink/Beam) to do windowed aggregations.- Backpressure & rate-limits: ingest admission control and sampling for low-value noisy sources.- Metrics and tracing for observability; autoscale components.

Failure modes & trade-offs:- Over-zealous suppression may hide problems → default conservative policies, visibility channel for suppressed alerts, audit logs, and manual override.- Dedup window tuning: too short misses correlation, too long hides evolving faults. Make configurable per-service.- Storage cost vs retention: keep aggregated summaries long-term, raw alerts shorter.

Why this reduces pager fatigue:- Collapse duplicates, group correlated alerts, avoid paging during controlled error-budget burns, and escalates only unresolved actionable incidents. Clear audit trail and tunable policies ensure reliability and post-incident learning.

MediumTechnical

56 practiced

Describe a structured approach to debug a memory leak in a long-running service. Explain how you would reproduce the leak locally, what tools you would use to find the leak (heap profilers, core dumps, GC metrics), how you would narrow down the suspect code, and how you would validate the fix in staging and production.

Sample Answer

Start with a hypothesis-driven, reproducible process: detect → reproduce → isolate → fix → validate.

1) Detect & gather signals- Alerts/metrics: RSS, heap_used, GC pause, fd count, CPU, OOM events (Prometheus/Grafana).- Correlate with deploys, traffic spikes, or config changes.

2) Reproduce locally- Create a deterministic load test that mimics production traffic (wrk, vegeta, k6) and use same config, heap limits, and versions.- If leak is slow, accelerate by increasing load or decreasing GC thresholds.Example:

bash

k6 run -e TARGET=http://localhost:8080 script.js

3) Tools to capture memory state- For JVM: jmap -dump:live,file=heap.hprof PID; jhat or Eclipse MAT to analyze dominators.- For Go: runtime/pprof; HTTP /debug/pprof/heap endpoint; collect with:

bash

go tool pprof -http=:8081 binary heap.prof

- For native/C++: gcore to capture core, then use lldb/gdb + heap profiler (valgrind --tool=memcheck or massif) or jemalloc/TCMalloc stats.- Containerized: docker exec + nsenter, or use crictl; ensure you capture cgroup metrics and limit-aware RSS.

4) Narrow down suspect code- Compare heap snapshots over time; diff HPROF/pprof outputs to see growth by allocation stack, type, or allocation site.- Look for: - Large retaining dominators or increasing populations of a type - Long-lived object graphs (caches, static maps, goroutine stacks) - File/socket/connection leaks (fd growth)- Add targeted logging/metrics and feature flags to disable suspected paths. Use binary search: disable half of features to see if leak persists.

5) Fix & regression-proof- Implement fix (weak refs, explicit close, cache eviction, object pooling, minimize retention).- Add unit/integration tests that assert memory bounds under load (CI soak tests).- Add alerts (rate of heap growth, unusual GC frequency) and expose diagnostic endpoints.

6) Validate in staging and production- Staging: run long-duration soak under realistic load + automated heap snapshots and compare to baseline.- Gradual rollout: canary with increased observability and roll-back plan.- Production: monitor memory slope, GC metrics, fd count, latency; capture post-deploy heap snapshot if anomaly reappears. Use retrospective heap diffs to confirm fix.

Example specific commands:

bash

# JVM
jmap -dump:live,file=heap.hprof $PID
# Go
curl -sS localhost:6060/debug/pprof/heap > heap.prof
go tool pprof -text ./binary heap.prof

Key validation criteria: memory usage stabilizes under steady-state load, GC behavior normalizes, no fd/goroutine leaks, and SLOs remain met.

MediumTechnical

65 practiced

A metric frequently 'flaps' between OK and Alert due to natural fluctuations. Outline a methodical approach to reduce flapping: include smoothing techniques, hysteresis, alert windowing, anomaly detection, and how to evaluate the trade-off between sensitivity and noise reduction.

Sample Answer

Framework:1) Clarify objective and constraints — acceptable alert latency, MTTR targets, SLOs/error budget, and how costly false positives vs false negatives are.

Proposed step-by-step approach:- Smoothing: apply short-term rolling aggregates (e.g., 1–5m moving average or EWMA with a tunable α) to reduce high-frequency noise while preserving trend. Use both raw and smoothed signals for diagnostics.- Hysteresis: implement asymmetric thresholds (enter-alert threshold higher than exit-alert threshold) so metric must recover past a lower threshold for the alert to clear. This prevents rapid flip-flops around a single boundary.- Alert windowing (time-based debouncing): require the smoothed metric to exceed the enter threshold continuously for T_enter (e.g., 2–5 minutes) before firing; require continuous recovery for T_exit before clearing.- Anomaly detection: complement thresholding with statistical models (z-score, rolling percentile, seasonal decomposition, or lightweight ML) to detect true deviations that thresholds miss—use anomaly score to raise alert confidence rather than binary triggers.- Multi-signal correlation: require correlated indicators (e.g., latency + error rate) or use weighted voting to reduce alerts caused by single noisy metric.

Evaluation and trade-offs:- Define metrics: alert precision, recall, mean time to detect (MTTD), mean time to acknowledge (MTTA), and alert fatigue (alerts per on-call per week).- Run A/B or shadow testing: simulate changes in parallel with current alerts, compare false positive/negative rates and detection latency.- Tune parameters: smoothing window, EWMA α, hysteresis gap, and window durations to move along the sensitivity-noise Pareto. If SLOs demand fast detection, accept smaller smoothing and shorter windows; if noise dominates, increase smoothing/hysteresis and rely on correlated signals or anomaly scoring for rare but important events.

Implementation considerations:- Expose knobs in config and use gradual rollout.- Log raw vs smoothed values for post-incident analysis.- Provide on-call guidance and visualization to explain why alerts are suppressed.

Expected outcome: fewer spurious alerts, preserved detection of real incidents, measurable reduction in noise with monitored impact on detection latency.

MediumTechnical

63 practiced

You must design a sliding-window rate limiter that supports 100k concurrent users and 10k requests/sec total. Describe appropriate data structures and algorithms, options to implement in-process vs Redis (or equivalent), memory and CPU trade-offs, and how to keep windows accurate with minimal locking and acceptable tail latencies.

Sample Answer

Requirements & constraints:- 100k concurrent users, 10k req/s total, per-user limits (e.g., 100 req/min) with sliding-window accuracy, low tail latency, minimal locking, high availability.

Approach summary:Use a time-bucketed sliding window (fixed-size circular buffer of small sub-windows) per key + atomic counters. This approximates true sliding window with high accuracy and low overhead.

Data structures & algorithm:- Per user: an array of N buckets covering W window (e.g., W=60s, N=6 → 10s buckets) storing count and bucketTimestamp.- On request: compute current bucket index, if timestamp stale reset bucket, atomically increment bucket; compute sum across buckets to decide allow/deny.- Maintain compact per-user struct: N * 8 bytes + metadata ≈ small footprint.

In-process vs Redis:- In-process (single instance or sharded) - Pros: ultra-low latency, no network hops, cheap CPU increments. - Cons: state fragmented across instances → need sticky routing or consistent hashing; lower global visibility; memory per instance. - Use for bursty low-latency checks with sticky sessions (k8s service with consistent hashing / ingress).- Redis (centralized or clustered) - Pros: single source of truth, supports atomic ops (EVAL/Lua), TTL-based eviction, easy to scale via clustering. - Cons: network latency, higher p99; higher CPU for many small keys. - Implementation: store per-key hash with fields for each bucket or a single sorted set/time-series; use Lua script to atomically roll, sum, and increment to avoid multi-round trips.

Memory & CPU trade-offs:- Finer buckets (larger N) → better accuracy, larger memory and CPU to sum more buckets.- Coarser buckets → less memory/CPU, more approximation.- For 100k users × N=6 × 8B ≈ ~4.8MB + overhead → Redis memory modest; in-process multiplied by number of instances.- CPU: per request work = one bucket increment + summation of N buckets. Offload expensive sums by caching sliding sums and updating incrementally.

Keeping windows accurate with minimal locking & low tail latency:- Use atomic ops: in-process use lock-free increments or per-key mutex; Redis use Lua to ensure atomic read-modify-write in one round-trip.- Minimize locking by: - Using per-key fine-grained locks (sharded lock table) if in-process. - Avoid global locks; compute approximate sums by maintaining a running total per key updated with each bucket increment (subtract old bucket when it expires) to make checks O(1).- Tail latency: - In Redis: co-locate application and Redis in same AZ, use pipelining, and Lua scripts to reduce RTTs. - For high p99, implement local token-bucket cache: fast accept decisions served locally for low-rate cases, with background sync to Redis for consistency (allow small false-positives that are corrected). - Use circuit-breaker: if Redis slow, fall back to conservative in-process limiter.

Operational considerations:- Eviction: set TTL on per-key entries to reclaim idle users.- Metrics & alerts: expose allowed/denied counts, queueing, Redis latency, memory pressure.- Testing: load-test with realistic traffic, measure p50/p95/p99 latencies.- Scaling: shard keys across Redis cluster; use consistent hashing for in-process sharding.

Recommendation:For this scale (10k req/s, 100k keys), prefer Redis cluster with Lua-based bucketed sliding-window script for correctness and simplicity; add an in-process small LRU cache for hot keys to reduce p99 and network load, plus fallback conservative limiter for resilience. Tunable N (e.g., 6–12) balances accuracy vs cost.

Unlock Full Question Bank

Get access to hundreds of Problem Solving and Structured Thinking interview questions and detailed answers.

Join thousands of developers preparing for their dream job.