Python

A loader you wrote reads a daily orders.csv from a partner and appends it to the warehouse. It worked for months on the sample they gave you. In production it fails (or worse, *silently corrupts*) on real files: occasional non-UTF-8 bytes, rows with too many/too few fields, a two-row header on some days, commas inside quoted free-text fields, and an order_id column that sometimes loses its leading zeros. The interviewer wants you to turn a happy-path loader into one you'd trust unattended at 3am.

Twice this quarter a bad upstream load shipped straight to the executive dashboard — once a partial file (40% of rows), once a currency column that arrived as cents instead of dollars. Both times nobody noticed for days. You're asked to add a data-quality gate to the pipeline so a bad batch is caught and *stopped* before it reaches consumers. The interviewer wants the design: what you check, where the gate sits, and what happens when it trips — including how you avoid crying wolf.

You've inherited a Python ETL pipeline — extract from an API, a few pandas transforms, load to the warehouse — with zero tests. It breaks in production a couple of times a month, always discovered by an analyst noticing weird numbers. You're asked: how would you make this testable, and what would you actually test? The interviewer is probing whether you can tell apart the tests worth writing from the ones that just feel productive.

You're pulling order events from a partner's REST API into the lake. The API paginates, rate-limits aggressively (HTTP 429 with Retry-After), occasionally 500s mid-pull, and the job is scheduled hourly. The naive version — loop pages, append JSON — sometimes double-writes records, sometimes silently misses them on a mid-run failure, and gets the job throttled into oblivion. The interviewer wants an ingestion you can run hourly, unattended, that neither loses nor duplicates events.

A daily job needs to aggregate a 30 GB CSV of events on a box with 8 GB of RAM. The current code does pd.read_csv(...) and immediately OOM-kills. Someone suggests "just spin up a Spark cluster." The interviewer wants you to first *scope the problem*, then reason about the ladder of options — from a one-line fix to distributed compute — and pick the right rung for the actual requirement, not the flashiest one.