Back home

For experienced developers

Built for the ten-year engineer, not the first-year student

Difficulty bands that start well past what a variable is, for the fundamentals that get quiet from disuse rather than never getting learned.


What actually gets rusty at ten years in

Nobody with a decade of experience forgets what a function is. What goes quiet is more specific: the SQL you used to write by hand before the ORM did it for you, the exact rule for when a JavaScript closure captures a variable at that point in its lifecycle, the mental model for how a database index actually changes a query plan, the OOP design instincts that used to be automatic and now take a beat to reconstruct.

None of that is beginner material, and a tool that starts everyone at what a variable is will not notice the difference between someone who has never coded and someone who coded for a decade and stopped writing raw SQL two years ago.

What this actually asks you

The upper difficulty band in SQL is window functions, query plans, and the tradeoffs behind an index you added six months ago and cannot fully explain anymore. In Python it is the async model and the typing system, not print statements. In Java it is generics, concurrency, and the JVM behavior underneath the collections you reach for every day without thinking about. In JavaScript and TypeScript it is closures, the event loop, and the type-system tricks the compiler usually does for you. In system design it is caching layers, replication, and the consistency tradeoffs behind a decision you have probably already made in a real design doc.

The full list of tracks, including which ones are live right now, is on the tracks page.

Not beginner content, and it says so up front

Difficulty in every track runs 1 to 5. Self-assess as Sharp when you enroll and you start at 3 through 5, the top of the range, not the bottom rung everyone else gets. From there it adjusts between sessions based on how you have actually been doing: string together roughly 80 percent correct over your last several answers and the next session nudges harder within the band, drop to around 40 percent and it eases back, so it settles near where you actually are.

There is no tutorial to sit through first and no introductory video. You pick a track, say you are sharp, and the first task is already at the level you asked for.

What a Sharp-band task actually looks like

A difficulty 4 SQL task might hand you a query plan and ask which operation is actually the bottleneck, not which keyword belongs in a blank. A difficulty 5 Java task might be a code-reading question about a race condition that only shows up under a specific interleaving of threads, with four plausible explanations and one correct one. Nothing in that band is testing whether you remember syntax. It is testing the same kind of judgment call you already make against a stack trace at ten in the morning.

The manager who codes twice a month

The other half of this audience does not have a rustiness problem so much as a frequency problem. Managing more than you code for a few years does something specific: the fundamentals are still in there, but the day-to-day fluency, the thing that made writing code feel automatic instead of effortful, fades from disuse.

A five-minute session does not require blocking out an evening, which matters more for this group than for almost anyone else, because an evening is exactly what they do not reliably have.

There is a close cousin of this problem too: the engineer who switched stacks at work, say a move to Go for the job while still caring about keeping React sharp for a side project or a future role. Two active tracks on the free plan covers exactly that split, one for what you use daily and one for what you are not ready to let go of.

Reviewing code you could no longer write yourself

There is a specific and growing version of this problem: approving a pull request written mostly by an AI assistant, for a pattern you have not personally typed out in months. You can tell if the code runs. Telling if it is the right code, the version that will not need rewriting in six months, still requires the same judgment it always did, and that judgment erodes the same way any other unused skill does.

The Agentic Engineering track deals with this directly: reading and reviewing agent-generated code, spotting when a confident suggestion is wrong, understanding what the model is actually doing before it writes anything. It sits alongside the language and framework tracks rather than replacing them, because the fundamentals are still what you are ultimately judging the output against.

Every task, right or wrong, ends with an explanation rather than just a checkmark. That matters more here than it does for a beginner, because the value is rarely learning the fact for the first time. It is re-anchoring something you already half remember, and catching the gap quietly before it costs you in an actual review.

What this will not do

This will not teach system design from nothing, and it will not replace the kind of learning that comes from building something with real constraints and real consequences. If your fundamentals are genuinely absent rather than rusty, project-based learning and production experience will get you further than a daily quiz ever will.

What this is built for is narrower: catching decay in things you already know, before it shows up in a code review or a design conversation you used to be able to lead without thinking about it.

Start at the level you are actually at.

Start a free session