KadraPractice

Practice Python data engineering on a working ETL pipeline

Streamline is a working nightly ETL pipeline that loads, transforms and aggregates records. Re-runs double-count, timestamps land on the wrong day, and one bad row stops the whole batch. You fix each bug and open a GitHub pull request. An AI teammate reviews it, and a hidden pytest suite decides whether it passes.

Real GitHub PRs · Graded by pytest · Free during beta

What you'll actually do

Three bugs in Streamline's nightly job

Pipeline bugs tend to show up as wrong numbers on someone's dashboard the next morning. Each ticket is a bug report with acceptance criteria, in a Python codebase you didn't write.

DATA-501

Re-running the nightly job double-counts every row

The load step appends rows on every run instead of upserting on the natural key, so a retry or backfill duplicates the whole day. To pass, a re-run has to give the same totals as one run, a partial re-run has to reconcile, and other dates can't change.

DATA-509

Timestamps are parsed in local time

Source timestamps are parsed in the host's timezone and bucketed by that local date, so rows near midnight and during daylight saving changes land on the wrong day. To pass, timestamps are parsed as UTC, days are bucketed by the UTC date, and daily counts hold steady across a DST change.

DATA-514

One malformed row aborts the whole batch

The transform throws on the first invalid row and the whole night's load fails with it. To pass, a bad row is skipped and logged to a dead-letter sink, the rest of the batch loads, and the run summary reports how many rows were skipped.

How grading works

pytest decides whether the fix works

Each Streamline ticket has a hidden pytest file that's added to your branch at grading time. The result appears on your pull request as a check.

  • The hidden tests run with pytest on Python 3.13 in a clean sandbox. They re-run loads, feed in timestamps around midnight and DST, and mix bad rows into good batches.
  • An AI teammate reviews the diff in the PR thread and can request changes. That review is feedback; the tests decide pass or fail.
  • If a check fails, the test output is on the PR. Push another commit and it runs again.
  • Shipped tickets and tracked hours go on a certificate with a public link for your résumé or LinkedIn.
See exactly how the grading pipeline works →
Who it's for

Who the data pipeline track is for

Streamline assumes you know Python. It tests whether you can fix reliability bugs in a pipeline you didn't write.

Analysts and backend devs moving into data engineering who have never debugged a failed load.

Self-taught Python devs whose work so far lives in notebooks.

Anyone preparing for data engineering interviews who would rather talk about an idempotent load than a pandas tutorial.

Juniors who want to see what a "request changes" review feels like before it happens at work.

Not for: people new to Python. Streamline is about debugging an existing pipeline, so learn the language first.

FAQ

Questions about the data pipeline track

What do I need installed?

Python 3.13 and pip if you work locally. Every Streamline repo also opens in GitHub Codespaces with Python ready.

Who reviews my pull request?

An AI teammate reviews the diff in the PR thread and can ask for changes. Whether the fix is correct is decided by the hidden pytest suite.

What does idempotent mean here?

Running the job twice for the same day leaves the same result as running it once. DATA-501 is about making the load work that way, so a retry can't double the numbers.

What happens if the tests fail?

The failing test output is on the pull request. Push a new commit and the check runs again.

Can I put it on my résumé?

Yes. Finishing the sprint gives you a certificate with the stack, the tickets you shipped and your tracked hours, behind a public link.

Does it cost anything?

It's free during the beta.

Take DATA-501 and make the re-run safe.