A systems-design challenge
You won't be judged on your code. You'll be judged on whether you can explain a system so clearly that a small, free AI model can build it — inside 32 KB of RAM, on a 4 MHz CPU, with 10 MB of disk and no network. Talk us through your thinking on video. If the transcript alone is enough to build a working solution, you pass.
The premise
On a normal machine the obvious solution usually works, so nothing about your thinking is revealed. Starve the machine and the obvious answer falls over — now you have to choose between architectures, account for every byte, and defend the trade-off out loud. That reasoning is what we're measuring.
You don't submit code. You submit a video where you reason out loud and a written design. We feed your words to a small, free model and have it build the solution. A clear explanation produces working code; a vague one doesn't.
We want the wrong turns. "I tried X, it broke because Y, so I moved to Z" tells us more than a tidy final answer. The path through the problem is half the grade.
Thirty-two kilobytes forces honesty. A strong submission says where each KB of RAM goes, how many times it touches the disk, and why the naive approach can't fit. Hand-waving scores low.
What you submit
Record yourself thinking through the problem, write up the design that came out of it, and attach anything that helps. The captions of your video are the primary graded artifact.
Your transcript, on its own, must be enough for a small model to build a solution that fits the constraints. If the words you spoke don't carry the design, no diagram will save it.
How you're scored
Every submission is graded against the same rubric. Vagueness is penalised; arithmetic, explicit memory budgets, named data structures, and explored dead ends are rewarded.
Pass = total ≥ 70 and your transcript is buildable on its own. Dimension 10 is confirmed by running the built solution in a constraint harness that enforces the RAM, disk, and CPU limits.
The problems
Each one has an obvious approach that won't fit, and several that will. Your job is to find one and explain it clearly enough to build. Pick a problem to read the full brief.
Where to start
The problems vary in difficulty and a couple build on each other. A sensible order if you're new to designing under constraints:
External sort, spell checker, compressor. Each teaches you to do the arithmetic and budget the 32 KB before anything else.
Editing structures, persistence, dependency graphs, and streaming estimators. Now you're paging to disk and reasoning about error bounds.
Full-text search reuses your external sort; pathfinding trades memory for time; the scheduler is concurrency with no OS. Hard, and worth it.