KadraPractice

Practice real Python data-pipeline engineering on a live ETL codebase

Streamline is a real, running nightly ETL pipeline with three seeded bugs in its load, timestamp, and row-validation logic. You're handed a ticket, open a real GitHub pull request against the actual bug, an AI teammate reviews your diff like a coworker would, and a hidden test suite decides — objectively — whether your fix works.

Real GitHub PRs · Graded by tests, not vibes · Certificate on completion

What you'll actually do

Three real bugs in Streamline's nightly ETL

This isn't a lesson plan. You clone Streamline, a working nightly ETL pipeline that loads, transforms, and aggregates records. You're handed a ticket describing a real reported bug, you read the relevant code, fix it, and open a pull request. An AI teammate reviews the PR in the thread. A hidden pytest suite tells you whether it's actually fixed.

DATA-501

Re-running the nightly job double-counts every row

The load step appends every transformed row to the target table on each run instead of upserting on the natural key — so re-running the job for a date that already loaded (a retry after a transient failure, a manual backfill) duplicates every row for that date and inflates the aggregates. Passing requires a re-run to produce the same totals as a single run, a partial re-run to reconcile correctly, and rows for other dates to stay untouched.

DATA-509

Timestamps are parsed in local time, shifting rows across day boundaries

The ingestion step parses source timestamps using the host's local timezone instead of UTC, then buckets rows into a day using that local value — so rows near midnight, and anything during a DST transition, land in the wrong day. Passing requires timestamps to be parsed as UTC, day-bucketing to use the UTC date, and daily counts to hold steady across a DST transition.

DATA-514

One malformed row aborts the entire batch

The batch transform throws on the first row that fails validation, which unwinds the whole job — a single bad row from an upstream source can block an entire night's load, with no dead-letter path and no visibility into how many rows were affected. Passing requires a malformed row to be skipped and logged to a dead-letter sink, the rest of the batch to still load, and the run summary to report an accurate skipped-row count.

How grading works

An authoritative test suite decides — not a reviewer's opinion

Every Streamline ticket ships with a hidden, authoritative pytest suite — the same kind of check that gates a PR in a real CI pipeline. That suite, not a human's impression, decides whether your fix passes.

  • The hidden pytest suite is the pass/fail gate. It runs the same checks a real CI pipeline would run against your PR, and it's what decides whether DATA-501, DATA-509, or DATA-514 is actually fixed.
  • An AI teammate reviews your diff in the PR thread — asks questions, flags issues, requests changes, exactly like a coworker would. That review is real feedback layered on top of the test suite; it isn't the pass/fail gate itself.
  • Time on the ticket is tracked as part of a simulated sprint — standups, the work itself, and a retro at the end — the same rhythm as a real team.
  • Tickets shipped and hours logged both roll into a certificate showing the stack (Python), the tickets you shipped, and hours tracked — with a public, verifiable link for a resume or LinkedIn post.
See exactly how the grading pipeline works →
Who it's for

Who the data-pipeline track is for

Streamline assumes you already know Python — it's testing whether you can debug idempotency, timezone, and data-quality bugs inside someone else's pipeline, not teaching you the language from zero.

Analysts and backend devs moving into data engineering who've never debugged a production ETL failure.

Self-taught Python devs whose portfolio is all notebooks, with no real pipeline-reliability experience to point to.

Anyone prepping for data-engineering interviews who wants to say “I fixed a non-idempotent load bug” instead of “I did a pandas tutorial.”

Developers who've never had a real code review and want to feel what an actual “request changes” comment is like before it happens on the job.

Not for: day-one beginners with no Python fundamentals — Streamline tests debugging inside an existing pipeline, not language basics.

FAQ

Questions engineers actually ask about the data-pipeline track

Is this just a course with extra steps?

No. There's no video, no lesson, no multiple choice. You get a ticket describing a real bug in a real running pipeline, and you fix it by opening a real GitHub pull request. Everything after that — review, grading — happens the way it would on an actual team.

Who's actually reviewing my PR?

An AI teammate reviews the diff in the PR thread the way a coworker would — asking questions, flagging issues, requesting changes. Whether your fix is actually correct is decided separately, by a hidden automated pytest suite, so the outcome isn't a matter of the reviewer's opinion.

What happens if I fail the test suite?

You get the failing test output — what passed, what didn't — and you keep iterating on the PR until it passes, same as you would against CI on a real team.

Can I put this on my resume or LinkedIn?

Yes. Completed tickets and tracked hours generate a certificate with a public, verifiable link, built for exactly that.

How long does the data-pipeline track take?

It's sized like a sprint's worth of real tickets, not a single afternoon exercise — expect to spend real, trackable hours across DATA-501, DATA-509, and DATA-514, the same way you'd clear a sprint backlog.

Do I need Python experience already?

Yes — this tests and builds your ability to debug and ship inside an existing codebase, not to learn the language for the first time.

What's actually different from LeetCode or a bootcamp capstone?

LeetCode tests algorithm recall in isolation. A bootcamp capstone is usually a solo project nobody reviews. Streamline is someone else's codebase, with a real bug, a real PR, a real reviewer, and a real pass/fail bar — the actual shape of the job.

Stop running tutorials that never fail at 2am. Fix a real ETL bug, in a real PR, reviewed like a real coworker would.