A futuristic city powered entirely by software has begun to malfunction. Systems are unstable. Interfaces are broken. Logic is corrupted. Somewhere in the chaos, one hundred and twenty engineers just got their first assignment.
That was the premise we built Debug Quest 2.0 around — and for three weeks in April and May, it stopped being a premise and became the actual experience of running a debugging competition for GDG on Campus RCCIIT, alongside my co-organizer Soyam Paul and lead organizer Rishi Paul.
Why "Glitch City"
Most debugging competitions read like a to-do list: here's a repo, here are the bugs, go fix them. We didn't want that. Debugging is already the least glamorous part of software engineering — the part nobody wants to admit they spend most of their time doing — so we decided to lean into it instead of hiding it.
We framed the entire competition around Glitch City: Fix the Chaos — a city whose infrastructure runs on code, and whose code has started failing. Every bug in the repository wasn't just an issue ticket; it was a system in the city breaking down, waiting for someone to walk in and fix it. The launch event introduced participants to the city and its crumbling systems before a single line of code was touched.
It sounds like a small thing, but it changed how people approached the work — participants weren't just closing GitHub issues, they were "restoring" parts of a city, and that framing showed up again and again in how engaged people stayed over three weeks.
The Real Challenge Wasn't the Code
Here's what the event report doesn't fully capture: a huge portion of our 120 participants had never opened a terminal to run a git command in their life. Some were as early as class 12 — barely out of school, with zero exposure to version control, pull requests, or working inside someone else's codebase. Others knew how to code but had only ever written standalone scripts, never contributed to a shared repository.
So before Level 1 even opened, Soyam and I ran the introductory session covering everything from Git fundamentals to branching strategies to what an "issue" even is on GitHub. But the real work happened after that session ended — in the days and weeks that followed, fielding a constant stream of questions from participants who were stuck, confused, or just unsure if they were doing it "right."
We made ourselves genuinely available for that. Not just office-hours-available — actually present, answering the same "how do I fork a repo" question for the fifth time that day without making anyone feel behind for asking it.
A lot of participants told us afterward that this was their first pull request, ever. One participant's testimonial joked, "can we still report bugs after the competition?" — which became one of our favorite pieces of feedback, because it meant we'd managed to make people who'd never touched Git a month earlier actually enjoy the process of hunting for bugs.
Reviewing Under Volume
By the time the competition closed, participants had opened 91 issues and submitted 150+ pull requests. Every one of those needed to be read, tested, and either merged or sent back with feedback — and since a large share of the contributors were beginners, a lot of those PRs weren't clean on the first pass.
That meant a lot of manual review: reading through diffs to understand what a participant was actually trying to fix, checking whether the fix addressed the root cause or just patched a symptom, and — where it wasn't quite there yet — leaving comments that pointed someone in the right direction rather than just closing the PR.
For a beginner, the difference between "this PR is rejected" and "here's what to fix and why" is the difference between quitting and coming back for Level 2. We tried hard to always be the second kind of reviewer.
Level 2 raised the difficulty considerably — multi-file logic issues, edge-case failures, workflow-related bugs — which meant the review bar went up too. By the end, distinguishing the participants who'd genuinely understood the systems they were debugging from those who'd gotten lucky with a fix took real attention, and that judgment call fed directly into how we evaluated the final standings.
What Made It Work
Looking back, three things mattered more than anything else:
Meeting people where they were. We didn't assume prior GitHub experience, and we didn't gatekeep the competition behind it either. The introductory session existed specifically so a class-12 student and a final-year CS major could both start Level 1 on equal footing.
Being reachable, constantly. Doubt-clearing isn't a one-time session — it's an ongoing commitment for the length of the competition. Participants needed to know that getting stuck wasn't a dead end.
Making the grind fun. Debugging is tedious by nature. Glitch City gave it a narrative, and that narrative is a big part of why a month-long event with real technical difficulty still produced testimonials calling it "hands-on chaos" in the best possible way.
The Numbers
| Metric | Count |
|---|---|
| Participants registered | 120 |
| Issues created | 91 |
| Pull requests opened | 150+ |
| Competition levels | 2 |
Winners were announced live on TechKotha Episode 3.
Final Thoughts
Debug Quest 2.0 wasn't really a competition about who could fix the most bugs the fastest. It was about giving students — many of whom had never worked in a shared codebase before — a real, guided first exposure to how software actually gets built and maintained in the industry: through issues, through pull requests, through review, and through a lot of getting stuck and asking for help.
Glitch City is fixed, for now. We'll see what breaks next time.