My Hackathon Mentoring Experience 🚀
26 Nov, 2022 • 3 min read
What it's like mentoring developers at a hackathon: guiding teams, reviewing ideas, and helping build solutions under time pressure.
Listen
Playback speed
I’ve been on the hacker side of hackathons: Google Cloud DevJam, PandoConnect, the 2 AM debugging sessions, the scramble to get a demo working with 20 minutes left. I know that feeling. So when I got the chance to mentor at the CentuRITon Hackathon, a 72-hour event organized by Ramaiah Institute of Technology, I said yes immediately.
10 teams. 72 hours. And me on the other side of the table for the first time.
The biggest lesson: scope is the real enemy 🎯
Here’s the pattern I saw across almost every team. Hour 1: “We’re going to build a full-stack app with auth, real-time chat, ML-powered recommendations, and a mobile app.” Hour 20: stuck on setting up the database. Hour 40: panic.
The hardest thing I did wasn’t debugging code. It was convincing teams to kill features. To take their “we want to do X, Y, and Z” and turn it into “let’s nail X first, make the demo tell a clear story, and see where we land.” That conversation happened with almost every team I mentored.
One team wanted to build a health-tracking platform with 6 features. I asked them: “If the judges only remember one thing about your project, what should it be?” They thought about it and said “the medication reminder from a photo of the prescription.” Cool, that’s the product. The other 5 features are distractions. Build that one thing well. They did. And their demo was 10x sharper because of it.
The hardest lesson
Scope isn’t a planning problem. It’s a courage problem. Cutting a feature you’re excited about feels like losing. But shipping one thing that works beats demoing five things that don’t.
What I actually spent my time on
Most of my 72 hours went into three things:
- Idea sharpening 🎯: Not “is this a good idea?” but “is this a buildable idea in 72 hours?” Two very different questions. I helped teams find the smallest version of their product that still told a complete story.
- Technical unblocking 🔧: Stack decisions, API choices, and the occasional “your CORS issue is because you forgot the trailing slash” moment 😅. Sometimes the mentor’s job is just to be the person who’s seen that error before.
- Scope negotiations ✂️: The hardest part. Helping teams let go of features they loved because the clock was real. “You can always build v2 after the hackathon” became my most-used line.
The thing nobody tells you about mentoring: you’re not there to have all the answers. You’re there to ask the right questions. “What’s the one thing your user needs?” cuts through more confusion than any technical advice.
Offline hackathons hit different 🏟️
After years of online-only events, being in a room full of people building things was something else. You could walk up to a team’s table, look at their screen, sketch an architecture on a whiteboard, and feel the energy shift when something clicks. The 3 AM coffee runs. The “wait, it’s working!” moments echoing across the hall.
The next generation of builders isn’t just sitting in classrooms absorbing theory. They’re shipping real projects, learning in public, and helping each other debug at 2 AM. That’s the kind of thing that keeps the ecosystem alive.
The people matter more than the projects 🤝
The projects were great. But honestly, the conversations were better. I got to connect with Ananya and Ashutosh, sharp, driven people who were there to build and to help others build. The hallway conversations, the impromptu whiteboard sessions, the post-event reflections: that’s what I remember most. Not the tech stacks. The people.
What mentoring taught me about my own work
Here’s the thing nobody tells you about being on the mentor side: you learn more about your own gaps than your mentees’. Explaining “why” behind a technical decision, not just “what”, forces you to examine whether you actually understand it yourself. There were moments when a team asked me something and I thought, “huh, I’ve been doing this on autopilot for years and never questioned it.”
Teaching is debugging your own understanding 🧠
If you’ve only ever been on the hacker side, try mentoring at least once. You’ll see the same problems from a completely different angle, and you’ll realize that the skill of shipping under constraints isn’t just about code. It’s about decisions. What to build, what to cut, and when to stop polishing and start demoing.
And if you were at CentuRITon and we crossed paths, thanks for the 72 hours. It was a blast ✨
You can also find my shorter take on the same event on LinkedIn.