Here's something that might surprise you: at most hackathons, the mentors are the most underused resource in the room. They're experienced developers, designers, and entrepreneurs who volunteered their time specifically to help you. And most teams never talk to them.

Don't be most teams.

Mentors aren't judges. They're not evaluating you. They're not going to think less of you for asking a question. They showed up because they genuinely want to help people build things. Many of them have done hackathons themselves and remember exactly what it felt like to be stuck at 2pm with a broken API and no idea what to do next.

Walk up to a mentor, introduce yourself, and tell them what you're working on. That's it. You don't need a formal appointment. You don't need to have a sophisticated question prepared. Most mentors are wandering around hoping someone will flag them down.

Some things mentors are great at:

There's an art to asking good questions, and it's a skill that'll serve you well beyond hackathons. When you approach a mentor (or anyone), try to cover three things:

This structure helps the mentor understand your situation quickly and give you useful advice instead of asking clarifying questions for ten minutes. It also shows that you've put in effort, which mentors appreciate.

But here's the thing — you don't always have to follow this formula. Sometimes the honest answer is:

And that is a completely valid thing to say to a mentor. You don't have to pretend you know more than you do. "We want to add real-time notifications but none of us have done that before — can you point us in the right direction?" is a perfectly good question. Mentors love it, actually. It's clear, it's honest, and it gives them something concrete to help with.

First-time hackathon participants sometimes feel like they need to prove themselves before they've earned the right to ask for help. You haven't. You earned it by showing up. That's the whole point.

The answer is: much sooner than you think.

A good rule of thumb: if you've been stuck on the same problem for twenty minutes and you're not making progress, it's time to ask someone. At a hackathon, twenty minutes is a significant chunk of your total time. Spending two hours fighting a configuration issue that a mentor could diagnose in ten minutes is not a badge of honour — it's two hours you could have spent building your demo.

This is genuinely hard for a lot of people. We're trained to figure things out on our own, to "just Google it," to not bother others. At a hackathon, that instinct works against you. The entire event is designed to be collaborative. Use the support systems that are there.

Mentors aren't your only resource. During a hackathon, you'll lean heavily on documentation, tutorials, and AI tools. A few tips for using them well:

Documentation. Go straight to the quickstart guide or getting-started section. Don't try to read the full docs for a new library — find the minimum example that does something close to what you need and adapt it. Most good documentation has copy-paste examples. Use them.

AI coding assistants. If the hackathon allows AI tools (and most do now), use them aggressively. They're excellent for boilerplate code, debugging error messages, explaining unfamiliar APIs, and generating starter templates. Treat them like a very fast, very patient junior developer. Tell them what you need, review what they give you, and iterate.

Stack Overflow and forums. When you hit an error message, paste the exact error into a search engine. Chances are very high that someone else has hit the same problem and the solution is already out there. Don't reinvent the wheel.

This one surprises people who are new to hackathons. Aren't you competing against each other? Technically, yes. In practice, hackathon culture is remarkably collaborative. Teams help each other all the time. If you overhear another team working with the same API you're struggling with, walk over and ask how they set it up. They'll almost certainly help you.

Most hackathon participants understand that a rising tide lifts all boats. Helping another team doesn't hurt your chances — it makes the whole event better. Some of the best friendships and professional connections in tech started with one team helping another at a hackathon.

If your hackathon is online, all of this still applies — you just need to be more proactive about it. In a physical space, a mentor can see you looking frustrated and walk over. Online, they can't. So:

The single biggest risk of online hackathons is isolation. Fight it actively. Ask questions. Share updates. React to other teams' progress. The community aspect is what makes hackathons special — don't let a screen get in the way of it.

Key takeaways: