I Mentored 12 Teams at a Hackathon. Here's What I Learned.
System-level engineer building reliable backend systems with a focus on performance, correctness, and real-world constraints. I work across APIs, databases, networking, and infrastructure, enjoy understanding how systems behave under load and failure, and write to break down complex backend and distributed-systems concepts through practical, real-world learnings.
Recently, I got invited to mentor at HackArena 2.0 - Kolkata Zonals, held at Jadavpur University. Honestly, when the invite landed in my inbox from the Ignite Room team, I wasn't sure what to expect. I've been on the building side of hackathons before, but never on the other side of the table.
This was different. This time, I was the one asking the questions.
Walking into the Room
The event was at the TEQIP Building in JU's main campus. I showed up, got my evaluation sheet - a simple grid with 12 team names and five scoring criteria: Innovation, Feasibility, Use Case, Technical Depth, and USP. Each out of 5, total out of 25.
Sounds straightforward on paper. It's not.
When you're sitting across from a team that's been coding for hours, running on caffeine and conviction, and they're pitching you something they genuinely believe in, scoring becomes a lot harder than circling numbers. You start weighing things differently. You start caring about whether they'll actually take this forward after the hackathon ends.
The Teams
There were 12 teams in total: Full Stack Shinobi, Innovher, Los Blancos, Null&Void, Solvers, Agent_Forge, Matrix, BrainLeaf, Domain Expansion, VSS Errors, LOOSER'S, and BinaryBrains.
Every team had a different energy. Some came in with polished slides and rehearsed pitches. Some stumbled through their words but had rock-solid code underneath. A few had ideas so ambitious I genuinely wondered if they knew what they were signing up for, and I mean that as a compliment.
What stood out to me was how many teams were thinking beyond just "building a cool thing." They were thinking about real users, real problems, and real constraints. That's not something you can teach in a classroom.
What Mentoring Actually Feels Like
Here's something nobody tells you about mentoring at a hackathon: you learn just as much as the teams do.
I went in thinking my job was to point out flaws, suggest improvements, push them to think harder. And sure, that was part of it. But what actually happened was more interesting. Listening to 12 different teams explain 12 different problems forced me to think about software from angles I don't usually consider in my day-to-day work.
One team would be solving something with a completely different architecture than what I'd reach for. Another would frame a problem in a way that made me rethink assumptions I didn't even know I had. That's the underrated part of mentoring: it stretches your own thinking.
The best conversations happened when teams pushed back on my feedback. When someone says "we thought about that, but here's why we went this route instead" and then gives you a solid reason, that's when you know they've actually thought through their product, not just their code.
The Panel
I wasn't the only one evaluating. The mentoring panel included Abhay Nath, Krishnendu Dasgupta, Daipayan Guha, and Avik Agarwala. Having different perspectives in the room made a real difference. Where I might focus on backend architecture and system design choices, someone else would catch a UX issue or question the business model. The teams got much richer feedback because of that mix.
Credit Where It's Due
Ignite Room organized this, and they did a genuinely great job. Tarushi brought me in, Shiv handled the ground-level logistics, and the whole team made sure things ran smoothly. No unnecessary chaos, no confusion about schedules or rooms. For a hackathon event, that's rarer than you'd think.
GDG Kolkata was the community partner, and honestly, community partnerships like this are what make events like HackArena possible. Having an established developer community backing an event gives it credibility and reach that organizers can't build alone.
The Takeaway
If you ever get a chance to mentor at a hackathon, take it. Not because it looks good on LinkedIn (though it does), but because it forces you to articulate things you take for granted.
When a team asks you "why should we use X over Y?" and you can't just say "because that's how we do it at work," you have to actually think about fundamentals again. That's valuable.
Twelve teams, one afternoon, and a blue pen. That's all it took to remind me why I got into building things in the first place.
If you're organizing a hackathon or developer event and need mentors, reach out. I'm always up for it.