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.

MediumTechnical

75 practiced

Instrument a function to log structured context (user_id, request_id, latency_ms, status) before and after calling an external service in Python. Provide example code using a logger that emits JSON-compatible dictionaries and explain how these logs enable troubleshooting without leaking PII.

Sample Answer

Approach: wrap the external call so we emit structured logs before and after, measure latency, and sanitize any PII. Use a logger that accepts dicts (converted to JSON by handler) and ensure we do not log raw user data — only pseudonymized IDs or hashes and non-sensitive metadata.

python

import time
import hashlib
import logging
import json
import requests

# Simple JSON-emitting logger
logger = logging.getLogger("svc")
handler = logging.StreamHandler()
handler.setFormatter(logging.Formatter('%(message)s'))
logger.addHandler(handler)
logger.setLevel(logging.INFO)

def pseudonymize(value: str) -> str:
    """Non-reversible hash to avoid logging raw PII."""
    return hashlib.sha256(value.encode()).hexdigest()[:16]

def call_external_service(user_id: str, request_id: str, url: str, payload: dict):
    ctx = {
        "user_id": pseudonymize(user_id),   # pseudonymized
        "request_id": request_id,
        "service": "external-service-x",
        "endpoint": url
    }

    # Log before call
    logger.info(json.dumps({**ctx, "event": "external_call_start", "timestamp": time.time()}))

    start = time.time()
    try:
        resp = requests.post(url, json=payload, timeout=5)
        latency_ms = int((time.time() - start) * 1000)
        result = {"status": resp.status_code, "latency_ms": latency_ms}
        logger.info(json.dumps({**ctx, "event": "external_call_end", **result, "timestamp": time.time()}))
        resp.raise_for_status()
        return resp.json()
    except Exception as e:
        latency_ms = int((time.time() - start) * 1000)
        logger.error(json.dumps({
            **ctx,
            "event": "external_call_error",
            "error_type": type(e).__name__,
            "message": str(e)[:200],  # truncate to avoid long payloads
            "latency_ms": latency_ms,
            "timestamp": time.time()
        }))
        raise

Why this helps troubleshooting and avoids PII leaks:- Structured logs (JSON) make it easy to filter by request_id, user_id hash, status, or latency in log aggregators.- Pre/post events show request lifecycle and timings to identify slow or failing external calls.- Pseudonymization (hashing user_id) preserves the ability to correlate activity without exposing raw PII.- We avoid logging request/response bodies or sensitive headers; truncate messages and log only non-sensitive error types and short messages.- Correlating request_id across services enables tracing; latency_ms and status pinpoint performance or error patterns for alerting and incident investigation.

EasyBehavioral

99 practiced

Tell me about a time you refactored or fixed code that was failing silently (e.g., swallowed exceptions, empty catch blocks). Use the STAR structure (Situation, Task, Action, Result). Include how you detected the issue, the change you made to prevent recurrence, and what you learned.

HardTechnical

94 practiced

You run a nightly batch job that processes millions of records and occasionally crashes mid-run. Design a resume/restart mechanism so that on restart the job continues from the last consistent checkpoint without duplicating side effects. Discuss checkpoint granularity, idempotency, transactional updates, and trade-offs between throughput and checkpoint frequency.

Sample Answer

Requirements & goals:- On crash, resume processing without duplicating side effects (no double-writes, emails, etc.).- Minimal lost work, acceptable throughput.- Simple operational visibility and restart safety.

Design outline:1. Work partitioning & ordering- Split input into ordered chunks (e.g., file offsets, DB primary-key ranges, or fixed-size batches of N records). Deterministic ordering ensures repeatable progress.

2. Checkpointing- Maintain a durable checkpoint record (small DB table or distributed log) storing the last successfully committed chunk id/offset and metadata (timestamp, checksum).- Checkpoint granularity: chunk-level (e.g., 1k–100k records) is typical. Smaller = faster recovery, more overhead; larger = higher throughput, more rework on crash.- Choose chunk size based on processing latency SLA and acceptable rework.

3. Processing model & idempotency- Each record processing must be idempotent or use transactional semantics: - Option A: Make operations idempotent (upserts, idempotency keys, dedup tables). Include a unique operation-id = chunk_id + record_index persisted with side-effect. - Option B: Use two-phase commit/transactional outbox: write results + side-effect intents into a local transactional store; after commit, an idempotent dispatcher performs external side effects referencing the intent id.- Prefer idempotent operations for simplicity.

4. Atomic checkpoint advance- Advance (persist) the checkpoint only after the entire chunk processing and all local transactional updates have committed.- If external side-effects are involved, ensure they are either included in the transaction (outbox pattern) or executed idempotently before checkpoint update.

5. Failure & restart behavior- On restart, read checkpoint and resume at next chunk. Re-processing the chunk if checkpoint updated only after commit prevents duplication.- Optional: keep a "in-progress" marker with heartbeat and allow safe reprocessing if stale.

6. Trade-offs- Throughput vs checkpoint frequency: frequent checkpoints reduce lost work but add latency and I/O overhead. Batch larger chunks to maximize throughput; add periodic micro-checkpoints if failures are frequent.- Idempotency complexity vs transactional guarantees: making all actions idempotent is engineering effort but scales. Two-phase commit/outbox preserves semantics but adds implementation complexity.- Latency vs complexity: synchronous transactional side-effects simplify correctness but may slow processing; asynchronous + idempotency preserves throughput.

Example pseudocode (chunk-level):- read checkpoint C- for chunk in chunks after C: - begin transaction (DB) - for record in chunk: process -> write result with op_id - commit transaction - publish outbox entries (idempotent) - update checkpoint = chunk.id (atomic write) - continue

Key considerations:- Durable, atomic checkpoint writes.- Strong idempotency/unique operation IDs for external systems.- Observability: log processed chunks, durations, and failed chunk ids.- Test by injecting failures and verifying no duplicated side-effects.

This approach balances reliability and throughput; tune chunk size and idempotency strategy to your error rate and performance needs.

EasyTechnical

81 practiced

Create a Python CLI using argparse that accepts --input <path> and --mode <fast|safe>. Validate that the input file exists, the mode is one of the allowed values, and produce clear, non-cryptic error messages with non-zero exit codes for failures. Provide sample code and at least two example error messages the CLI should print.

Sample Answer

Approach: use argparse with explicit choices for mode, validate file existence with pathlib, and print clear messages to stderr with distinct non-zero exit codes for different failures.

python

#!/usr/bin/env python3
import argparse
import sys
from pathlib import Path

def parse_args():
    parser = argparse.ArgumentParser(description="Process an input file in either 'fast' or 'safe' mode.")
    parser.add_argument("--input", required=True, help="Path to the input file")
    parser.add_argument("--mode", required=True, choices=["fast", "safe"], help="Processing mode: fast or safe")
    return parser.parse_args()

def main():
    args = parse_args()

    input_path = Path(args.input)
    if not input_path.exists():
        print(f"ERROR: Input file not found: {args.input}", file=sys.stderr)
        sys.exit(2)  # file-not-found
    if not input_path.is_file():
        print(f"ERROR: Path is not a file: {args.input}", file=sys.stderr)
        sys.exit(3)  # not-a-file

    # If mode wasn't one of choices, argparse would have already failed with usage.
    mode = args.mode
    # Main processing (placeholder)
    try:
        with input_path.open("r", encoding="utf-8") as f:
            data = f.read()
        # simulate mode-specific behavior
        if mode == "fast":
            result = f"Processed {len(data)} bytes in FAST mode."
        else:
            result = f"Processed {len(data)} bytes in SAFE mode with extra checks."
        print(result)
    except Exception as e:
        print(f"ERROR: Failed to process file: {e}", file=sys.stderr)
        sys.exit(4)  # processing error

if __name__ == "__main__":
    main()

Example error messages the CLI should print:- ERROR: Input file not found: /path/to/missing.txt- ERROR: Path is not a file: /path/to/directory

Notes:- Argparse's choices ensures --mode is validated and prints usage on invalid values.- Return non-zero exit codes for programmatic handling (2=file-not-found, 3=not-a-file, 4=processing error).

HardTechnical

93 practiced

Discuss the trade-offs between failing-fast (abort on first serious error) and attempting to continue processing in a high-throughput data pipeline. What metrics would you track to make operational decisions (error rate, error cost, customer impact), and how would you design safeguards to choose between both behaviors dynamically?

Sample Answer

Situation: In high-throughput pipelines, choosing between fail-fast (abort on first serious error) and continue-on-error involves latency, data correctness, operational risk, and customer impact trade-offs.

Trade-offs:- Fail-fast: immediate visibility, prevents downstream corruption, simplifies debugging. Costs: reduced throughput, higher availability risk, potential tail-latency spikes, blocked upstream producers.- Continue-processing: maximizes throughput and availability, isolates bad records, and maintains SLA. Costs: risk of silent data quality drift, harder root-cause analysis, increased complexity (retry queues, compensating actions).

Metrics to track:- Error rate (per-record and per-window)- Error cost (business value per failed record)- Customer impact metrics (SLA violations, user-facing error rates)- Throughput and latency (p95/p99)- Mean time to detect/resolve (MTTD/MTTR)- Downstream correctness (validation-failure rate)- Resource/backpressure indicators (queue sizes, retry rates)

Dynamic decision safeguards:1. Classification: label errors by type (transient vs permanent), severity, and estimated business cost.2. Policy engine: rules that map metrics + error class to behavior (abort vs skip). Example rules: - If transient error && retry_count < N → retry non-blocking - If permanent corrupting error && error_rate > X% or error_cost > Y → fail-fast - If error isolated to <M records/window and error_cost low → continue with quarantining3. Circuit breaker + throttles: open circuit to fail-fast when error_rate or downstream-violation crosses thresholds; otherwise operate in degraded continue mode.4. Observability + automated mitigation: send bad records to dead-letter store with context; alert with runbook; automatically roll back or pause producers when threshold crossed.5. Canary + gradual rollout: apply stricter behavior to a sample before global enforcement.

Operational example: For a payment pipeline, because error_cost is high, set low thresholds for fail-fast and require human approval to resume. For analytics ingestion, allow high tolerance and quarantine bad rows.

This design balances availability and correctness by making failure behavior data-driven, auditable, and reversible.

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.