2 min lesson
Take-home / practical exercise
Explain the order in "Take-home / practical exercise", then say how you would verify the result.
Step 1 of 2
Senior data roles commonly include a four-to-eight-hour take-home and the likely shape maps straight onto the team's work: build or design a pipeline, ingestion path or data model from realistic, deliberately ambiguous requirements.
Treat it as production code you'd own on day one, not a happy-path script. The reviewers are platform engineers and they read for the instincts that keep data reliable at scale.
- 1Read the brief for the ambiguity, then state your assumptions. Write them down at the top - ambiguity tolerance is being graded and silent guessing reads as junior.
- 2Choose a partitioning and incremental-load strategy on purpose. Partition on a real query/ingest dimension, load incrementally with a watermark and say why.
- 3Make every transform idempotent. A re-run after a failure must not double-count; use merge/upsert semantics, not blind appends.
- 4Handle schema evolution and bad data. Tolerate an added column, route malformed records to a dead-letter path instead of crashing the job.
- 5Add data-quality checks and observability hooks. Freshness, row-count and null/distribution checks signal SLA thinking even at small scale.
- 6Write a README that argues trade-offs and cost. What you cut, what you assumed, what you'd do with more time and the cost implications of your layout.
Reviewers skim for: does it run from a clean clone, is the transform idempotent and incremental, does it survive a schema change and a malformed record, are there data-quality checks and does the README reason about cost and trade-offs. Optimize for those before any clever feature.