Error Handling and Code Quality Questions

Focuses on writing production quality code and scripts that are defensive, maintainable, and fail gracefully. Covers anticipating and handling failures such as exceptions, missing files, network errors, and process exit codes; using language specific constructs for error control for example try except blocks in Python or set minus e patterns in shell scripts; validating inputs; producing clear error messages and logs; and avoiding common pitfalls that lead to silent failures. Also includes code quality best practices such as readable naming and code structure, using standard libraries instead of reinventing functionality, writing testable code and unit tests, and designing for maintainability and observability.

HardTechnical

103 practiced

You are hiring SREs to improve code quality. Design a 60-minute interview exercise focused on error handling and maintainable code for a mid-senior candidate. Include the prompt, constraints, expected deliverables, and a scoring rubric that tests correctness, defensive design, testability, and clarity of error messages. Explain how you would grade borderline solutions.

Sample Answer

Interview exercise (60 minutes) — Goal: assess an SRE candidate’s ability to write maintainable, defensive code with clear error handling and testability.

Prompt (5 min): You’re given a small service that reads JSON configuration files describing scheduled jobs, validates them, and returns a normalized internal representation. Implement a function parse_job_config(json_str) that:- Parses JSON containing fields: name (string), schedule (cron string), retries (optional int), destinations (list of {type, url}).- Validates types, required fields, and schedule format (simple pattern: 5 space-separated fields).- Normalizes missing retries to 3, expands destination URLs (e.g., ensure http:// prefix).- Raises well-typed exceptions for client vs system errors.

Constraints:- 40 minutes coding, 15 minutes for writing unit tests and brief README/comments, 5 minutes for explanation.- Use the language of your choice (Python preferred). No external libs except test frameworks.

Expected deliverables:- parse_job_config implementation with inline comments.- Small suite of unit tests covering success, validation failures, malformed JSON, and edge cases.- README or header comment describing error types, contract, and usage.

Scoring rubric (100 points):- Correctness (35): passes valid inputs, normalizes defaults, enforces schedule pattern, handles destinations (0-35).- Defensive design (25): clear separation of validation vs parsing, immutable outputs or clear mutability policy, explicit exception types (client vs transient/system) (0-25).- Testability & tests (20): unit tests cover happy path, invalid inputs, boundary values; tests are deterministic and readable (0-20).- Clarity of error messages (10): errors include actionable message, field context, and suggested fix when possible (0-10).- Code clarity & maintainability (10): readable, small functions, docstrings, clear naming (0-10).

Grading borderline solutions:- If correctness is incomplete but defensive design and tests are strong, award partial correctness and comment on missing validations; candidate likely understands trade-offs — add 50% of missed correctness if tests show awareness.- If code works but errors are vague or exceptions are generic, deduct from error-message and defensive-design buckets; ask candidate to describe runtime behavior to see intent.- For incomplete tests: if unit tests demonstrate thoughtfulness (edge cases listed but not implemented), give partial testability credit and probe during debrief.- Use a calibration checklist: must get >=20/35 correctness and >=12/25 defensive to pass; otherwise fail. In borderline cases, use debrief answers to resolve intent and adjust scores up to ±10 points based on candidate rationale and trade-offs.

HardTechnical

145 practiced

As the SRE lead you discover a service has exhausted its error budget mid-quarter, blocking features. Create an operational plan: immediate mitigations to reduce customer impact, engineering work to repair reliability, stakeholder communication, prioritization of work against features, and metrics to track recovery. Include how to structure weekly checkpoints and cross-team responsibilities.

Sample Answer

Situation: Mid-quarter our service has exhausted its error budget, blocking new features and risking user experience.

Immediate mitigations (first 0–48 hrs):- Freeze non-essential deployments and feature flags affecting the service.- Activate service-level rollback plan for any recent risky releases.- Apply quick mitigations: increase autoscaling thresholds, lower non-critical background job concurrency, enable circuit breakers and graceful degraded mode for non-essential flows.- Raise incident bridge and routing for on-call SRE + product/eng reps for 24–72 hrs.

Engineering reliability work (short→medium term):- Triage top error types from logs/traces; fix highest-volume root causes first.- Implement bulk fixes: input validation, retry/backoff, idempotency, and resource throttling.- Add targeted rate-limiting and caching to reduce load.- Plan architectural fixes (queue partitioning, sharding, DB indexes) as sprint-backed epics.

Stakeholder communication:- Send an initial 1-paragraph incident bulletin: impact, mitigation, immediate next steps, and expected timeline.- Daily concise updates to execs and affected PMs until error rate returns below SLO.- Post-mortem with owner, timeline, root causes, action items, and ETA for feature unblock.

Prioritization vs features:- Re-scope roadmap: only critical/security/compliance features allowed until error budget recovers.- Use RICE-like matrix but force reliability work to high priority until error budget replenished.- Negotiate feature gating: PMs must justify any new work; SRE approves deployments.

Metrics to track recovery:- Error rate % (SLO window), latency P95/P99, successful requests/sec, queue lengths, CPU/memory saturation, deploy frequency.- Track error budget burn-down and projected days to recovery.

Weekly checkpoints & cross-team responsibilities:- Weekly reliability sync (30–45 min): SRE lead, core eng owners, PMs, infra — review metrics, blocked features, progress on top 3 reliability epics, and open action items.- Assign clear owners with SLAs for each action item; use a shared tracker (Jira + dashboard).- Escalation path: if no measurable progress in 2 weeks, elevate backlog grooming and reassign resources.- Celebrate milestones when error budget returns and resume regular cadence with lessons implemented.

This plan balances immediate customer protection, focused engineering repair, transparent stakeholder comms, and a disciplined prioritization to restore the error budget quickly and sustainably.

MediumTechnical

79 practiced

Design alerting rules that minimize noisy alerts for error logs while still catching real reliability regressions. Explain grouping strategies, using error rate normalized by traffic (error ratio), minimum sample sizes, and combining static thresholds with anomaly detection. Provide a PromQL-like pseudo expression to alert when error ratio exceeds 1% over 5 minutes with a minimum of 1000 requests.

Sample Answer

Start with the goal: detect real reliability regressions while avoiding noisy alerts from low-volume or transient spikes. Key principles: normalize errors by traffic, require minimum sample sizes, group alerts to reduce noise, and combine simple static thresholds with anomaly detection to catch both obvious and subtle regressions.

Grouping strategies- Primary grouping key: service (job/service_name). Secondary keys: cluster/region, HTTP route or feature flag, and error type (5xx/timeout). - Keep cardinality low: only group by fields you can reasonably on-call for. Don’t group by user_id, request_id, or highly dynamic labels. - Use alertmanager grouping/aggregation so one incident (service+region) produces a single page, not dozens of alerts.

Error ratio and minimum sample size- Use error_ratio = errors / total_requests (normalized). Ratios avoid false positives during traffic surges or drops. - Require a minimum sample size (e.g., at least 1000 requests over the window) so a single error in a tiny sample doesn’t page. For low-traffic routes, route alerts to a different channel (ticket or weekly report).

Combine static thresholds with anomaly detection- Static thresholds catch clear regressions (e.g., error_ratio > 1%). - Anomaly detection catches relative regressions (error_ratio suddenly 3x baseline) even if below absolute threshold. Use a baseline window (last 1–6 hours or same time yesterday) and trigger if current_ratio / baseline_avg > factor (e.g., 2–3) and statistically significant (z-score or increase over stddev). - Use multi-window logic: require condition sustained for shortdedicated wait-for (e.g., 5m) and confirm with a longer window (e.g., persists 15m) to reduce flapping.

PromQL-like pseudo expression (static threshold + min sample)

# Alert when error ratio > 1% over 5m AND at least 1000 requests in that 5m
expr = (
  increase(http_errors_total{job="api"}[5m])
  /
  increase(http_requests_total{job="api"}[5m])
) > 0.01
and
increase(http_requests_total{job="api"}[5m]) >= 1000

Example anomaly extension (relative increase vs baseline)

current = increase(http_errors_total{job="api"}[5m]) / increase(http_requests_total{job="api"}[5m])
baseline = avg_over_time(increase(http_errors_total{job="api"}[5m]) / increase(http_requests_total{job="api"}[5m])[1h:5m])
# Alert if current > 2 * baseline and traffic >= 1000
current > 2 * baseline and increase(http_requests_total{job="api"}[5m]) >= 1000

Operational recommendations- Use a severity tier: page-level for high-impact services, non-paging tickets for low-impact or low-traffic routes. - Add runbooks linking to dashboards (error ratio trend, top endpoints, recent deploys). - Test rules in non-paging mode (notifications to Slack channel) for a few weeks before paging. - Continuously tune thresholds and baseline windows based on observed noise and incident history.

This approach balances precision (min samples + normalization) with sensitivity (anomaly detection + multi-window confirmation), reducing noise while still surfacing real regressions.

EasyTechnical

74 practiced

Design a small Python helper function format_error_log(exc: Exception, context: dict) -> dict that returns a structured log record suitable for ingestion into a logging pipeline. Keys should include timestamp, level, service, correlation_id, error_type, message, and a short_stack. Use only standard library modules. Describe how you would limit sensitive data and ensure logs are parsable.

Sample Answer

Approach: build a small deterministic dict with only JSON-serializable primitives, extract a short stack, normalize timestamp, pull service/correlation_id from context (or generate), and redact sensitive values by allowlisting keys and applying regex-based redaction for common secrets.

python

import datetime
import traceback
import uuid
import re

SENSITIVE_KEYS = {"password", "token", "secret", "authorization", "api_key"}
SENSITIVE_VALUE_RE = re.compile(r"(?i)(password|pass|pwd|secret|token|apikey|api_key|bearer)[\s:=]*[\S]+")

def _redact_value(key: str, val):
    if key and key.lower() in SENSITIVE_KEYS:
        return "<redacted>"
    if isinstance(val, str) and SENSITIVE_VALUE_RE.search(val):
        return SENSITIVE_VALUE_RE.sub("<redacted>", val)
    return val

def format_error_log(exc: Exception, context: dict) -> dict:
    # timestamp in ISO 8601 UTC
    ts = datetime.datetime.utcnow().replace(tzinfo=datetime.timezone.utc).isoformat()
    # short stack: last 3 frames
    tb = traceback.TracebackException.from_exception(exc)
    stack_lines = list(tb.format() )
    short_stack = "".join(stack_lines[-3:]).strip() if stack_lines else ""
    # basic fields
    record = {
        "timestamp": ts,
        "level": context.get("level", "error"),
        "service": context.get("service", "unknown"),
        "correlation_id": context.get("correlation_id") or str(uuid.uuid4()),
        "error_type": type(exc).__name__,
        "message": str(exc),
        "short_stack": short_stack,
    }
    # attach sanitized context (only primitives, small set)
    safe_ctx = {}
    for k, v in (context or {}).items():
        if k in {"service", "correlation_id", "level"}:
            continue
        safe_ctx[k] = _redact_value(k, v) if isinstance(v, (str, int, float, bool, type(None))) else "<non-serializable>"
    if safe_ctx:
        record["context"] = safe_ctx
    return record

Key points:- Uses only stdlib (datetime, traceback, uuid, re).- Parsable: all values are primitives (strings, numbers); ISO8601 timestamp.- Sensitive data: key allowlist + regex-based redaction; non-serializable values replaced to avoid pipeline failures.- short_stack limited to last 3 frames to reduce noise.Complexity: O(m + n) where m = context size, n = stack size. Edge cases: huge context (truncate), non-serializable objects, or extremely long messages — handle by truncation if needed. Alternative: use structured JSON schema and stricter allowlist for context keys.

EasyTechnical

91 practiced

As an SRE, you must standardize error log messages for services. Propose a structured JSON log schema for exceptions and provide three example log entries for: a client validation error, a downstream timeout, and an internal null pointer exception. Explain which fields to include (for example timestamp, level, service, env, request_id, user_id, error_type, message, stacktrace) and when to include stacktrace versus sampling stacktraces to reduce noise.

Sample Answer

Proposed JSON error-log schema (minimal required + optional):

json

{
  "timestamp": "ISO8601",
  "level": "ERROR|WARN|INFO",
  "service": "string",
  "env": "prod|staging|dev",
  "request_id": "uuid",
  "span_id": "hex (optional)",
  "user_id": "string|null",
  "error_type": "ValidationError|TimeoutError|NullPointerException|...",
  "message": "human-readable summary",
  "http": { "method": "GET", "path": "/v1/x", "status": 400 },
  "duration_ms": 123,
  "downstream": { "service": "name", "endpoint": "url", "status": 504 },
  "stacktrace": "string (optional)",
  "tags": { "...": "..." },
  "sample_rate": 0.01
}

Three example entries:

json

{"timestamp":"2025-11-22T14:05:12Z","level":"ERROR","service":"orders","env":"prod","request_id":"a1b2","user_id":"u-42","error_type":"ValidationError","message":"invalid order: missing field 'items'","http":{"method":"POST","path":"/orders","status":400},"stacktrace":null}

json

{"timestamp":"2025-11-22T14:06:20Z","level":"ERROR","service":"payments","env":"prod","request_id":"c3d4","user_id":"u-99","error_type":"TimeoutError","message":"downstream-payments timed out after 3000ms","downstream":{"service":"downstream-payments","endpoint":"/charge","status":504},"duration_ms":3000,"stacktrace":null,"sample_rate":0.1}

json

{"timestamp":"2025-11-22T14:07:01Z","level":"ERROR","service":"catalog","env":"prod","request_id":"e5f6","user_id":null,"error_type":"NullPointerException","message":"unexpected null when reading product.price","stacktrace":"com.example.Catalog.getPrice(Catalog.java:87)\n...","sample_rate":1.0}

Which fields and why:- timestamp, level, service, env: routing/alerting and filtering.- request_id/span_id: trace correlation for incident investigation.- user_id: impact scope and auditing (nullable).- error_type/message: quick classification and human summary.- http/downstream/duration_ms: context for latency/failure causes.- tags/sample_rate: attach metadata and indicate sampling.

Stacktrace policy:- Include full stacktrace for high-severity/internal exceptions and for all errors in non-prod.- For noisy or frequent errors (validation, client errors), omit stacktrace and log only message + error_type.- Use deterministic sampling (e.g., 1% or 10% with sample_rate field) for medium-severity downstream/timeouts to capture patterns without noise.- Always preserve request_id/span_id so sampled traces can be retrieved later.

Unlock Full Question Bank

Get access to hundreds of Error Handling and Code Quality interview questions and detailed answers.

Join thousands of developers preparing for their dream job.