Practical Coding Rounds/API & Data Integration Exercises

Defensive Data Handling: Parsing and Validating Real-World Input

The "parse a CSV of transactions" style prompt Stripe and others use for phone screens — where the actual test is how you handle the missing field, the malformed row, and the duplicate you weren't told to expect, not the parsing logic itself.

!!2/5Theory: 20m2 problems

The prompt that looks trivial and isn't

"Parse this CSV of transactions and produce a summary" reads like a five-minute warm-up exercise, and that's exactly the trap. Stripe's own phone screen deliberately uses this style of prompt precisely because the parsing logic itself is trivial — every language has a CSV/JSON parser in its standard library or a one-line import away — while the actual signal comes entirely from how you handle the input the parser doesn't expect: the row with a missing field, the amount stored as a string with a currency symbol still attached, the duplicate ID, the row that's just malformed. A candidate who writes clean happy-path parsing code and never considers what happens on bad input has, in the interviewer's eyes, solved a different and much easier problem than the one being asked.

Assume the data is wrong until you've checked

The default posture for this style of exercise should be adversarial toward your own input, not trusting: for every field you read, ask "what if this is missing, the wrong type, or an unexpected value — and what should happen then?" Concretely, for a "parse a CSV of transactions" prompt, the checks worth doing before you're asked about them:

  • Missing or empty required fields — an ID, an amount — should be reported, not silently treated as a default value that might mask a real data problem.
  • Type mismatches — an amount field that's sometimes "19.99" (string) and sometimes 19.99 (number), or a date in an unexpected format — need an explicit parse-and-validate step, not a raw cast that either throws unhelpfully or silently produces garbage (parseFloat("N/A") returning NaN in JavaScript is the classic silent version of this).
  • Duplicate identifiers — did this transaction ID already appear? Depending on the prompt, that might mean skip-and-report, or it might mean something is wrong with the input source itself worth flagging separately.
  • Out-of-range or nonsensical values — a negative amount where only positive makes sense, a currency code that isn't a real currency — worth at least a comment acknowledging you'd validate this, even if full validation is out of scope for the time given.

Collect errors — don't let one bad row take down the whole batch

The single most valuable design decision in this class of exercise: a malformed row should produce a reported error for that row, not an unhandled exception that stops the entire batch. A batch job that crashes on row 47 out of 10,000 because that one row had an empty field is a genuinely bad production design, and interviewers watch for whether candidates default to try/catch-per-row (or the equivalent) versus a single top-level try/catch that silently loses everything after the first failure. Returning both a list of successfully parsed records and a list of what failed and why is almost always the right shape for the output, even if the prompt doesn't explicitly ask for the error list — offering it demonstrates you were thinking about failure from the start rather than bolting it on when asked.

Silent wrong answers are worse than loud crashes

A subtler trap: code that doesn't crash on bad input but silently produces a wrong result is more dangerous than code that crashes, because a crash is at least visible. parseFloat("abc") returning NaN instead of throwing, or a missing field defaulting to 0 instead of raising a flag, are both examples of failure modes that look like success until someone downstream notices the totals don't add up. Explicit isNaN/None/null checks immediately after any parse or lookup that could plausibly fail — and choosing, deliberately, whether that becomes a reported error or a genuinely sensible default — is the concrete habit that prevents this.

A concrete way to practice this deliberately

Real, intentionally messy datasets are better practice material than hand-constructed toy CSVs, because real data has failure modes you wouldn't have thought to insert yourself. fivethirtyeight/data is a large, genuinely public collection of real-world datasets with the normal mess real data has (inconsistent formatting, missing values, occasional encoding issues) — picking a file at random and writing a parser that reports every row it had to skip, and why, is close to the exact shape of the interview prompt this subtopic targets.

Reference implementations in:

Validating a Row Instead of Trusting It

The same decision at every layer: a malformed row is reported and skipped, not silently dropped and not allowed to crash the whole batch.

from dataclasses import dataclass @dataclass class Transaction: id: str amount_cents: int currency: str def parse_transactions(rows: list[dict]) -> tuple[list[Transaction], list[str]]: parsed, errors = [], [] seen_ids = set() for i, row in enumerate(rows): try: tx_id = row["id"].strip() if not tx_id or tx_id in seen_ids: raise ValueError("missing or duplicate id") amount_cents = round(float(row["amount"]) * 100) # defend against "19.99" as a string currency = row.get("currency", "USD").upper() seen_ids.add(tx_id) parsed.append(Transaction(tx_id, amount_cents, currency)) except (KeyError, ValueError) as e: errors.append(f"row {i}: {e}") # collect, don't crash the whole batch on one bad row return parsed, errors

Returning both the parsed rows AND the errors (instead of raising on the first bad row) is the key decision — a real batch job needs to know which specific rows failed and why, not just that "something" was wrong.

Further Resources (Optional)

Practice Problems

Interview relevancy:!!!Critical — must-have!!Important — highly recommended!Good to have~Niche — rarely asked