ยท4 min read

Why I Mentor at Hackathons: Lessons from HackGT9

hackathonmentoringpersonal

Two weeks after winning at HackHarvard and HackUMass, I got on a flight to Atlanta. Not to compete. To mentor at HackGT9 at Georgia Tech.

People asked me why. I'd just had the best hackathon run of my life. Why not keep the streak going? Honestly, it felt like the right time to give back. I'd been on the other side of that table, staring at a broken Flask API at 2am, wishing someone would just tell me what I was doing wrong. I wanted to be that someone for somebody else.

Also, I'd never been to Atlanta. And I'm still new enough to the US that every new city feels like an adventure. The weather was warm, which was a welcome break from Boston already starting to get cold. I was two months into living here and already learning that "fall" in New England is just winter's opening act.

The 3am Flask Debugging Sessions

There's a specific type of chaos that happens at hackathons between 2am and 5am. The caffeine is wearing off. The code that worked an hour ago now throws a 500 error. People are tired and frustrated and starting to wonder why they signed up for this.

That's when mentoring matters most.

I spent a solid chunk of Saturday night helping a team of freshmen debug their Flask backend. They were trying to build a mood-tracking app that used sentiment analysis on journal entries. Good idea, solid scope. But they'd never built an API before, and their POST endpoint was returning empty request bodies because they forgot to set Content-Type: application/json in their fetch call.

It took us ten minutes to find the bug. But the look on their faces when the API finally returned real data, that's the thing I'll remember. One of them literally pumped her fist and said "LET'S GO" loud enough that three other teams looked over.

Explaining ML to Non-ML People

The hardest part of mentoring wasn't debugging. It was explaining complex concepts simply. A team wanted to add image classification to their project but had never touched machine learning. I had maybe fifteen minutes to get them from zero to "working prototype."

So I skipped the theory entirely. No talk about convolutional layers or gradient descent. I showed them how to use a pretrained model from HuggingFace, load it in five lines of Python, and get predictions. They didn't need to understand backpropagation. They needed a working demo by Sunday morning.

That was a lesson for me. As an ML engineer, I default to wanting to explain the internals. But a hackathon isn't a lecture. The right amount of abstraction depends on the goal, and the goal here was shipping.

What Competing Never Taught Me

When you compete at hackathons, you're focused inward. Your idea, your code, your demo. Mentoring flips that completely. You're bouncing between ten different teams, each with different tech stacks, different experience levels, different problems.

I talked to a team using Unity for the first time. A team building a Chrome extension in vanilla JavaScript. A team that decided to learn React during the hackathon, which is either very brave or very unwise depending on how you look at it.

Every conversation forced me to think differently. To diagnose problems in codebases I'd never seen, in frameworks I don't normally use. That kind of rapid context-switching is genuinely hard, and genuinely valuable.

The Part That Sticks With Me

At the closing ceremony, one of the freshmen I'd helped with the Flask app found me and said, "You're the reason our demo worked." Their team didn't win any prizes. But they shipped a working project at their first hackathon, and they were already talking about the next one.

I flew back to Boston on Sunday night, exhausted in a totally different way than after competing. When you win a hackathon, you feel accomplished. When you help someone else succeed, you feel useful. Both are good. But useful stays with you longer.