Katas, projects, or courses: how to practice coding so it transfers

You can solve two hundred katas and still freeze the first time someone hands you a real repository. Not because you can't code — you clearly can — but because a kata trained one narrow muscle and the job needs six. The question isn't whether to practice. It's whether the thing you're practicing is the thing you'll actually be measured on.

How to practice coding so it transfers

Practice the parts you'll be graded on at work, not just the one that's easy to grade on a website. Katas train a single skill well — turning a clearly-specified problem into working syntax — and that skill is real. But the engineering process is a different muscle: structuring a project, using git, deciding what to test and writing those tests, reading a code review, shipping through CI. You don't build that muscle by solving more katas. You build it by doing those specific things, on code that has more than one file and more than one right answer.

What a kata actually trains

Here's a normal kata. Given a list of integers and a target, return the indices of the two numbers that add up to it:

def two_sum(nums: list[int], target: int) -> tuple[int, int]:
    seen = {}
    for i, n in enumerate(nums):
        if target - n in seen:
            return seen[target - n], i
        seen[n] = i
    raise ValueError("no pair sums to target")

pytest -q
5 passed in 0.19s

This is a good exercise. It rewards knowing that a dict lookup beats a nested loop, and it punishes you fast if you forget the edge case where no pair exists. Solve fifty of these and your syntax gets fluent, your algorithmic instincts sharpen, and reading other people's code gets easier. That's worth something.

Now look at everything the kata handed you for free. The problem was fully specified. The function signature was decided. The tests already existed, written by someone else. There was one file, no git, no review, and nothing to name except two local variables. Strip all of that away and what's left — the pure algorithm — is maybe a fifth of what a working programmer does in a day. The kata trains the fifth you'd have learned anyway and skips the four-fifths that are hard.

What the job actually is

A real task doesn't arrive as a signature and a test suite. It arrives as a sentence: "an upstream service sends us user records and some of them are malformed — make ingestion not fall over." Now you have decisions the kata made for you. What counts as malformed? Do you drop bad records or collect the errors? What's the function even called, and where does it live? Which cases deserve a test, and which are you just assuming will never happen?

Say you write the first version, and a reviewer leaves one comment: "what happens when records is empty versus None — are those the same to a caller?" That single question is the whole game, and syntax has nothing to do with it — you knew the syntax cold. What it tests is the habit of thinking past the happy path, the habit a kata never asks you to build because a kata's inputs always arrive well-formed. You answer it by writing a test that pins the behavior down:

def test_empty_and_none_both_yield_no_records():
    assert ingest([]) == ([], [])
    assert ingest(None) == ([], [])   # a missing batch is not an error

pytest -q
9 passed in 0.24s

Same person, same Python, a completely different skill. The kata version of you can write ingest's inner loop in your sleep. The engineering version of you knows that the loop was never the risky part.

Why video courses transfer even less

If katas train a fifth of the job, a video course often trains less, because watching is not doing. A well-made course feels productive — the instructor's code runs, the concepts land, you nod along. Then you open a blank file and discover that recognizing a solution when someone shows it to you and producing one from nothing are separate abilities, and you only trained the first. This is the tutorial trap: forty hours of watched material that collapses the moment the hand-holding stops and there's no next "play" button, only a problem and a cursor.

Courses have a place — they're a decent way to meet a concept the first time. But treating "finished the course" as "learned the skill" is the same error as treating katas as engineering practice. You're counting the input and hoping the output followed. It usually didn't. For the honest version of that arithmetic, see how long it actually takes to learn Python: the hours that count are the ones spent producing, at the right difficulty, not the ones spent watching.

So how do you practice the process?

By practicing it directly, in the smallest form that still contains it. You don't need a twelve-person team to learn code review — you need one honest reviewer and your own code in front of them. You don't need a production outage to learn testing — you need one task where the edge case is the point. The trick is to practice the boring four-fifths on purpose instead of waiting to absorb them by accident at a first job.

That's the loop ProdQuest runs today. A task isn't a kata with the tests pre-written; it's graded by deterministic checks — your code is run against real tests, static analysis, and security scans that carry at least 70% of the grade, with a quality rubric worth no more than 30%. The point of that split is to grade you on the engineering, not on an opinion, and to do it in under 30 seconds so the feedback lands while you still remember what you were thinking. Getting told exactly which assertion failed, on your own code, is the review muscle in miniature.

The rest of the process is coming, not here yet. The full simulated cycle — a feature branch, a pull request, an agent reviewing your diff like a senior engineer, a CI/CD pipeline gating the merge — is a planned stage on the roadmap, not something you can run this week. What exists now is one loop: task, grade, reward, held in the 70–80% success zone where practice is hard enough to teach and not so hard you quit. That loop already carries more of the process than any kata site, because the grade cares about your tests and your structure, not just your return value.

The honest answer

Use all three, but know what each one buys. A course introduces an idea. Katas make the syntax automatic so the idea has somewhere to live. Neither one teaches you to structure a project, defend a decision in review, or write the test that catches the bug before the reviewer does — and that last category is most of the job. Practice it as its own thing, deliberately, on real tasks with real grading. The alternative is learning it in production, on someone else's deadline.

If you want practice that grades the process and not just the algorithm, join the closed beta — the first task starts in the browser, no install, and the grade tells you which four-fifths you've been skipping.