Robust Python Components And API Failure Handling

What's being tested

These questions test defensive Python programming: validating inputs, isolating side effects, handling exceptions, and producing deterministic outputs. They also probe metric correctness—especially precision/recall—and whether you can make an evaluation component robust to flaky APIs, malformed responses, retries, and partial failures.

Patterns & templates

• Separate pure computation from I/O: fetch API results first, then compute metrics or scores in deterministic, easily unit-tested functions.

• Validate at boundaries with explicit types, required fields, ranges, and allowed values; reject malformed data instead of silently coercing it.

• Wrap network calls narrowly with try/except; distinguish timeout, connection, HTTP-status, parsing, and semantic-validation failures.

• Use bounded retries with exponential backoff and jitter; retry transient 429 and 5xx responses, not invalid requests or malformed payloads.

• For top-k evaluation, deduplicate results and normalize identifiers before calculating $precision = TP/(TP+FP)$ and $recall = TP/(TP+FN)$.

• Treat zero denominators explicitly: return 0.0, None, or a documented convention rather than allowing ZeroDivisionError or misleading perfect scores.

• Represent prices as integer cents or Decimal, never binary floating point; keep validation, calculation, and presentation separate.

Common pitfalls

Pitfall: Counting duplicate API results as separate predictions inflates true positives and can make precision exceed the intended interpretation.

Pitfall: Catching broad Exception and returning an empty result hides outages; preserve an error state or structured failure reason.

Pitfall: Retrying every failure can amplify load and duplicate side effects; use timeouts, bounded attempts, and idempotency where applicable.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.