Error Handling and Defensive Programming Questions

Direct answer
Design a 60-minute error-handling interview exercise around a small, realistic scenario (not a puzzle) that has genuine ambiguity requiring judgment calls, with a rubric that scores correctness, defensive design, testability, and error-message clarity SEPARATELY, so a candidate can score well on some dimensions and poorly on others rather than a single pass/fail gut call.

Structured elaboration

• The prompt: a realistic, bounded task (e.g., 'implement a function that processes a batch of user-submitted records, handling malformed records gracefully') with deliberately underspecified edge cases, since how a candidate HANDLES ambiguity (asking clarifying questions, stating assumptions explicitly) is itself a signal worth observing, not noise to eliminate from the prompt.
• Constraints: a realistic time-box (45 minutes coding, 15 minutes discussion) and explicit permission to use documentation/search, since defensive-coding judgment (not memorized API trivia) is the actual skill being assessed.
• Expected deliverables: working code (even if incomplete, given the time-box) plus a brief verbal explanation of the design decisions made, specifically the error-handling choices and why.
• Scoring rubric, four separate dimensions: (1) correctness: does the happy path work; (2) defensive design: are malformed inputs handled explicitly and sensibly (not just 'does it crash'); (3) testability: is the code structured so the error paths COULD be unit tested (dependency injection, small functions), even if time didn't allow writing every test; (4) clarity of error messages: are errors actionable and specific, or generic.
• Grading borderline solutions: a candidate who writes clean, correct happy-path code but handles only ONE of several plausible malformed-input cases, and can ARTICULATE the others when asked in discussion, should score differently than one who neither handles nor recognizes the other cases exist; the VERBAL discussion component is what distinguishes 'ran out of time but understands the gaps' from 'doesn't see the gaps at all', which is why the discussion time is deliberately built into the 60 minutes, not treated as optional overflow.

Worked example
Prompt: 'Write a function that parses a batch of JSON-encoded user records and returns the valid ones, given the batch may contain some malformed entries.' A strong candidate handles the obvious malformed-JSON case, explicitly discusses (even if not fully implementing) the partial-batch-isolation question (does one bad record fail the whole batch or just itself), and proposes a specific error-reporting shape for the malformed entries; a weaker candidate writes code that crashes on the first malformed record with no discussion of the trade-off, scoring low on defensive design and error-message clarity even if their happy-path code is clean.

Trade-offs and pitfalls
A rubric with only a single overall score collapses genuinely independent signals (a candidate can be excellent at defensive design but rusty on a specific syntax detail, which a single holistic score would unfairly conflate); scoring the four dimensions separately, then discussing them together as a panel, produces a much more calibrated, defensible hiring decision than a single gut-feel number.

Direct answer
For a team you manage, defensive coding is a lever for reducing the cost of the bugs that inevitably reach production, and your job is enforcing it consistently through code review rather than writing it yourself; the failure mode to watch for is defensive code so heavy it slows delivery without proportionally reducing real risk.

Structured elaboration

• Practice 1: input validation at every public boundary (an API endpoint, a function another team calls) is a hard requirement in review, since a missing check here is the single most common root cause of the on-call pages your team owns.
• Practice 2: no bare except/catch-all without a logged reason, so a swallowed exception never becomes an invisible, undebuggable failure three weeks later.
• Practice 3: resource cleanup (context managers, try/finally) is mandatory for anything that opens a file, connection, or lock, since a leaked resource is a slow-burning outage that's much harder to diagnose after the fact than a fast, loud failure.
• Enforcement, not authorship: as the manager, you don't personally add these checks; you make them a PR-review checklist item and a topic in retros when they're missed, so the practice survives your own attention wandering to something else.

Worked example
A PR adds a new internal helper function called only by two other functions your own team wrote and controls, and the reviewer requests three defensive null checks on arguments that are already guaranteed non-null by the two callers. That's the counterproductive case: the checks add code, review time, and a false sense that this function is somehow riskier, for zero actual risk reduction, since the real trust boundary (validating user input) is two layers up and already covered. The right review comment moves the validation discussion to the actual boundary, not this internal helper.

Trade-offs and pitfalls
Defensive coding enforced as a blanket rule ('validate every argument, everywhere') trains engineers to pattern-match the checklist rather than reason about where the actual risk is, and it slows down internal refactoring, where the same 'obviously safe' invariant gets re-verified at every call site. Enforce it hardest at genuine trust boundaries and let it relax for code that only your own already-validated code calls; that distinction, made explicit in review comments (not just enforced silently), is what keeps the practice from becoming cargo-culted busywork.

Direct answer
A company-wide error taxonomy only pays off if it's operationalized past the design doc: every category maps to a concrete severity level, an on-call runbook, and an escalation path, and teams are trained to use it consistently during actual incidents, not just told about it once.

Structured elaboration

• Taxonomy categories: a small, memorable set (validation, authentication, dependency-failure, data-integrity, capacity, internal-bug) that every service maps its own errors into, rather than each team inventing its own incompatible categories.
• Operationalizing into alerts and severity: each category has a default severity (data-integrity and internal-bug tend toward higher severity than validation), and alert rules key off the category so a spike in dependency-failure pages differently than a spike in validation (which is often just a client bug, not an operational emergency).
• Runbooks per category: a dependency-failure runbook starts with 'check the dependency's own status page and your circuit breaker state'; a capacity runbook starts with 'check current load against provisioned capacity'; having category-specific starting points cuts triage time versus a generic 'something is wrong' runbook.
• On-call escalation: each category also carries a default escalation path, not just a severity label: a validation spike pages only the owning team's primary on-call, since it's rarely an emergency; a data-integrity or internal-bug incident above its severity threshold pages the owning team's primary AND automatically escalates to secondary on-call if unacknowledged within a fixed window (for example 10 minutes), and above a defined blast-radius threshold pages an incident commander rotation that spans teams, so a category-wide taxonomy also standardizes WHO gets pulled in and how fast, not only how the error is labeled.
• Documenting residual risk: for a category of error that's known but not fully mitigated (a rare race condition that's hard to eliminate), document it explicitly with likelihood/impact/owner, so it's a tracked, visible decision rather than a surprise the next time it fires.
• Training teams: run the taxonomy through a tabletop exercise or an actual on-call rotation shadow period, not just a wiki page, since a taxonomy nobody actually uses under real incident pressure provides no value.

Worked example
A dependency-failure category fires an alert when a service's error rate for calls to a specific downstream crosses a threshold; the linked runbook's first three steps are: check the downstream's status page, check this service's own circuit-breaker state for that dependency, and check whether a recent deploy on either side correlates with the onset. An on-call engineer new to this specific service can follow the SAME first three steps they'd use for ANY dependency-failure alert on ANY service, because the taxonomy and its runbooks are consistent company-wide, not reinvented per team.

Trade-offs and pitfalls
A taxonomy that's too granular (twenty categories, each service using a different subset) loses the cross-team consistency that's the entire point; a taxonomy that's too coarse (just 'error' and 'not error') provides no useful signal for prioritization or runbook selection. The real failure mode isn't picking the wrong category count, it's ROLLING OUT the taxonomy as a mandate without training or tooling support, so teams default back to their old, inconsistent practices under real incident pressure within a few months.