Most coding platforms train you to solve clean problems.
You’re given a neat description.
Clear inputs.
Clear outputs.
A well-defined goal.
Real software development rarely looks like that.
Instead, it looks like this:
- A job queue randomly stops processing.
- A rate limiter "works"... but never actually limits.
- A race condition only appears under load.
There’s no tidy prompt. Just something broken.
And you have to figure out why.
The gap between interview prep and real work
I realised something odd while practising algorithms.
I could solve medium-level problems comfortably.
But when I opened a messy codebase and something didn’t work, I felt slower and less confident.
Because algorithm platforms train you to:
- Construct solutions from scratch.
- Optimise for time and space complexity.
- Recognise patterns quickly.
They don’t train you to:
- Read unfamiliar code written by someone else.
- Trace state across multiple functions.
- Identify subtle logic flaws.
- Fix something without rewriting everything.
Debugging is a different cognitive skill.
It’s less about invention.
More about investigation.
What debugging actually feels like
When you debug, you are:
- Building a mental model of the system.
- Forming hypotheses.
- Testing assumptions.
- Eliminating possibilities.
- Narrowing down the failure.
It’s closer to being a detective than a puzzle solver.
Often the hardest part isn’t the fix.
It’s understanding the system well enough to know what’s wrong.
So I built something around that
I built Recticode, which is a collection of small, self-contained systems that are intentionally broken.
Not toy problems.
But things like:
- A job queue with a hidden race condition.
- A rate limiter that never rate limits.
- A subtle state bug that only appears after multiple operations.
- A database interaction that looks correct but behaves inconsistently.
Each challenge starts with:
- Existing code.
- A failing behaviour.
- No obvious error message.
- No instruction to "rewrite everything".
Your task is to:
- Read the code.
- Understand what it’s trying to do.
- Identify the real issue. F4. ix it cleanly.
That’s it.
What I learned building this
Designing debugging challenges is much harder than writing algorithm questions.
You have to:
- Make the bug realistic but isolated.
- Avoid accidental red herrings.
- Ensure there’s a clear root cause.
- Prevent solutions that just patch symptoms.
I also realised how many bugs revolve around:
- Concurrency and race conditions.
- Incorrect assumptions about state.
- Edge cases that only appear after sequences of actions.
These are things you only really internalise by fixing them.
Why I think this matters
If you’re a student, debugging skill builds confidence fast.
If you’re a junior developer, it’s probably the skill you use most.
If you’re preparing for interviews, being able to reason about broken code makes you stand out in system design and practical rounds.
Writing new code is important.
But being able to understand and repair existing code is what makes you useful on a team.
I’m still iterating on this idea, and I’d genuinely love feedback from people who think debugging is under-practised compared to algorithms.
If this resonates with you, what kind of "broken systems" would you want to practise on?
If you want to do a debugging challenge, check out Recticode