How Three High Schoolers Coded Their Way to HackMIT USA: A Mentor Reflection
- John Hernandez
- 11 hours ago
- 4 min read
60 teams, a 36-hour ticking clock, and all the chaotic energy of coding, debates, and lack of sleep that characterize a Hackathon.
Unlike most teams formed by students from the same school and class, our team was Frankensteined a week before the competition with three young gentlemen from different cities and campuses, who were unfamiliar with each other and had diverse expectations for the event.
Spoiler Alert: it turned out to be a key for their success!
Robot me wanting to systematized as much as I can, I sent out a pre-event survey. I was looking for understanding their personalities, experience and working styles. With that in hand, I mapped out potential roles, ways of approaching each student and a rest-work strategy. I also organized an online meet-and-greet session. Although I intended to cover some CS content, the students were occupied with exams, so that was the extent of our "training." The rest would be entirely up to them over the 36-hour hackathon.
The First Reality Check: Should I Intervene or Not?
After the opening ceremony, while other teams sprinted to their laptops, my students spent 2 hours engaged in a heavy debate over what to build.
They were torn between two ideas: One was an APP to recognize cyberbullying interactions, offering educational guidance and next steps based on severity. The other was a 2D physics card game (an idea two of the members were heavily invested in).
A little, or not so little, voice was singing a "step in, force a decision, and get them on schedule" rock and roll song. But I stopped myself, maybe because I was enjoying the debate so much. These kids were practicing discomfort. They needed to navigate conflict and communicate effectively. I observed their dynamics: one got emotionally involved defending his ideas, another tried to play the calming mediator, and the third threw hard fastball questions at every proposal (yes, I suggested he offer some ideas too).
So I just simply moderated. I asked them to evaluate both ideas against four criteria: personal interest, community impact, feasibility within 36 hours, and their actual skill sets. The next morning, they arrived with a unified decision, a clear logic map, and feature outlines for the game.
Lets work! wait, dont forget the big picture...
They chose to build Newton’s Edge, a Python-based 2D physics card game inspired by one team member's struggles preparing for the AP Physics C: Mechanics exam.
Hackathons are notorious for tunnel vision; students will spend 10 hours perfecting code or GUI while forgetting they need to submit a pitch deck. To prevent this, we leaned on the Software Development Life Cycle (SDLC): I constantly initiated discussions about the "pipeline elements" of their project and reminded them of the three non-negotiable phases of the competition: Build, Deploy, and Present. By visualizing the pipeline, they understood exactly how their current tasks connected to the final deliverable. This macro-level view ensured they didn't just build a game but a complete, deployable product with a compelling narrative.
And, They Were Working... Until They Didn't
Passion and pipelines only get you so far. After 16 hours, the mental demand of the hackathon set in. They had spent the first night debating and now the sheer volume of Python coding, UI design, and documentation was catching up to them.
This is where the pre-survey and our SDLC approach paid off. We utilized the rest-work routines we had identified earlier: when their energy was high, they tackled the heavy logic/code and game mechanics. When they were burning out, they looked at the pipeline and switched to "lighter" tasks like recording the demo video or writing their GitHub documentation. As for their time management: one of them needed a few naps a day, another was a morning bird, and the last one needed to wander around in fresh air from time to time.
TIME is Up!
When time was up, they had a fully functional, deployed web game. They pitched it to a judging panel of MIT CS students and industry experts.
The result? Out of 60 teams, these three strangers took 3rd place overall, and 1st place in the Educational Track. They walked away with trophies, medals, and a qualification card to attend the global HackMIT event in the USA later this year.
Now the team will meet to maintain the chemistry and learn more advanced tools, algorithms, and methodologies to prepare for the next event!
What We Learned (The Educator’s Perspective)
Conflict is a feature, not a bug: The hours they "lost" debating actually built the trust required to survive the pressure.
Big picture and pipeline are lifesavers: Constantly referencing the pipeline (Design, Implementation, Testing, Deploy, Present) kept them from getting lost in the weeds.
Intrinsic motivation needs scaffolding: Interest gets them to the table, but strategic task-switching keeps them from quitting at hour 16.
Guidance for Schools and Teachers: How to Start
If you are a STEM coordinator, school leader, or parent wondering how to get your children into hackathons, check at this:
Audit your students' soft skills: Technical ability is only 50% of a hackathon. Assess their resilience and communication styles first.
Teach the pipeline early: Equip them with the Software Development Life Cycle so they know how to manage a project from end to end.
Be a mentor, not a project manager: Your job is to set guardrails (like my 4-point evaluation criteria), not to make decisions for them.
Prepare for the emotional dip: Plan specifically for the middle of the event. Have snacks, mandatory screen breaks, and "low-brain-power" tasks ready.
Focus on the documentation: Judges can't evaluate what they don't understand. Ensure students allocate real time to their pitch, video, and GitHub readme.
A Personal Reflection
Nowadays, international school educators are sometimes suggested to smooth out the bumps for students. However, true innovation occurs in the friction. Mentoring students at the first China-based HackMIT confirmed my approach of pushing students into high-stakes, unscripted problem-solving and stepping out of comfort zones can lead to incredible outcomes when done with a clear goal and an environment that fosters growth.
Looking to expose your students to high-stakes, real-world challenges like HackMIT? Or perhaps you're a parent wanting to prepare your child for collaborative tech environments?
Connect with me here. Let’s talk about how to teach students to build things that actually prepare them for real life and not just standardized exams or school assessments.
Comments