Most school coding contests give students a problem statement and ask for code. I found this didn’t stretch their analytical thinking. I created Reverse Engineering to flip it: students must first discover the problem by testing a hidden program, then solve it themselves.
Students receive a compiled program (.exe) with no instructions. They give it inputs, watch how the outputs change, and work out the hidden logic. Once they’ve identified the problem statement, they write their own code for it in a language of their choice. They have 90 minutes in total.
The challenges are real-world logic problems, such as an invoice calculator that applies tax and discounts per item, or a denomination problem that finds the fewest notes for an amount. Solutions are judged on how fast they’re completed and whether they handle every use-case, so students have to test edge cases rather than just the obvious inputs.
It began as an event at Technophilia, the IT Fete of Cambridge International School, Amritsar, where it ran from 2018 to 2020 and drew students from around 10-12 schools. I still propose it to Grade IX-XII students in my sessions today.
I am using it as a part of the hackathons, coding events I organize anywhere in K-12 schools or colleges.
The core format has stayed the same since it began: decode a hidden program through inputs and outputs, then rebuild it in 90 minutes. That consistency is deliberate, because the format works.
The latest addition extends the same thinking to app innovation and vibe coding. Students decode an app prototype, working out what it does and how it behaves, and then build the same using vibe coding. This shifts the skill from writing every line of code to understanding a product well enough to describe, direct and verify what gets built.
There are two ways to run this: the coding route and the vibe coding route. Both start with the same step, decoding something hidden, and they differ in how students rebuild it.
Route 1: Coding
Before you write a single line of code, you have to work out what the code is supposed to do. The facilitator prepares a logic-based problem, such as an invoice with tax and discounts or the fewest notes for an amount, and builds it as an .exe with no source code or instructions. In a 90-minute session, students first decode the program by feeding it inputs, noting how the outputs change, and testing edge cases to uncover the hidden rules. They then write their own code for the identified problem in a language of their choice, check it against the .exe, and submit. Entries are judged on completion time and on handling every use-case, and a final debrief reveals the intended logic and what students missed.
Route 2: Vibe coding
When AI can write the code, the real skill is knowing exactly what to ask for. The facilitator shares a working app prototype with no source code or specification. Students decode it by using it closely, mapping its features, flows, rules and edge cases into a plain-language spec. They turn that spec into clear prompts for an AI coding tool, build the app through vibe coding, and iterate by reviewing and refining the output. They then verify their build against the original, feature by feature. Entries are judged on how closely the build matches the original,
