About BugHunt
Courses teach you to write code. Almost nothing teaches you to fix it.
Every CS student has been here: the code looks right, it runs, and the output is wrong. No error message, no stack trace, nothing to search for. Coursework rarely prepares you for this, because assignments are graded on writing code from scratch — and yet debugging is most of what the job actually is.
How it works
You get working code with exactly one bug in it, and a description of the symptom rather than the cause. You find it, fix it in the browser, and run it against the test cases. When it passes, you get an explanation of the pattern behind the bug — not just the diff.
That last part is the point. Knowing that this particular loop needed i + 1 is worth very little. Recognising the shape of an off-by-one, so you spot the next one faster, is worth a great deal.
Everything runs in your browser
Python runs through WebAssembly and JavaScript in a sandboxed worker, right in the tab. There is no server executing your code — which means it is fast, it works offline once a challenge has loaded, and there is no queue.
The step-through visualiser
For most challenges you can watch the code run line by line, with the value of every variable at every step. Seeing the exact moment a value goes wrong is a different kind of understanding from being told where the bug was.
It is free, and stays free
No account needed to try it, no paywall, no ads, no upsell. It runs on free hosting tiers deliberately, so there is nothing to recoup and no reason to start charging.
Found a problem?
Every challenge is written and checked by hand, and each one is executed before it ships — the broken version has to fail at least one test and the correct version has to pass them all. That still doesn't guarantee an explanation is clear. If one confuses you, use the report button on the challenge, or email devfixdaily@gmail.com. Reports genuinely get read.