5 Steps on How to not loose at a hackathon?

In 1999, ten developers gathered to work on cryptographic frameworks, IPv6, and IPsec for OpenBSD, in what is often considered the first-ever hackathon. Since then, the tech world has decided that the best way to encourage innovation is to put a few hundred developers in a building, deprive them of sleep, give them unlimited caffeine, and ask them to build something extraordinary in 24 to 48 hours.

Rather surprisingly, it worked.

Hackathons have become places where people build remarkable projects, discover new technologies, make lifelong friends, and occasionally spend six hours debugging something that could have been fixed by restarting their computer.

I started participating in hackathons in my first year of college, eventually began organizing them, and today, as a Hackathon Community Manager at Major League Hacking (@mlhacks), I work with organizers and hackers across the community. Along the way, I've noticed something: some people walk away with incredible experiences but no trophies, while others spend the whole weekend obsessing over winning and miss everything else that makes hackathons worthwhile.

So, how exactly does one avoid losing at a hackathon? Here are five steps. They won't guarantee a prize, although my definition of winning might be slightly different from yours.

Step 1: Talk to People. A Radical Concept, I Know.

You arrive surrounded by hundreds of people who share your interest in building things. Naturally, the sensible move is to find a corner, put on your headphones, and avoid all of them for 36 hours.

Or perhaps not.

Hackathons bring together developers exploring new frameworks, designers who approach problems differently, first-timers discovering what an API is, and veterans who've already made every mistake you're about to make. Talk to them. Ask what they're building and why. You don't need a networking strategy; a simple conversation is usually enough.

Talk to the organizers too. They've spent months on an event you're experiencing over a weekend. And at MLH-supported events, talk to the MLH reps. We're not just there to explain rules and hand out stickers (though stickers are an extremely compelling reason to approach anyone btw). We can connect you with resources, opportunities, and people worth knowing.

You might come looking for a teammate and leave with a mentor, a future collaborator, or someone who shares your inexplicably specific interest in apps for household appliances. You won't find any of them by staring at your terminal.

Step 2: Observe. There's a Lot Happening Beyond Your Screen.

In one corner, someone's building an AI app. Across the room, a team is assembling hardware with a worrying number of exposed wires. Somewhere else, a group has just discovered that the technology they spent twelve hours integrating doesn't support the one feature their project depends on.

Watch how other teams divide work, which tools they try, and how they decide what to do when something breaks. Most importantly, pay attention to how they think. One team might build a complicated ML pipeline while another solves the same problem with simple software and clever design. Neither is automatically better, and understanding why someone chose a solution is often worth more than the solution itself.

(No, this isn't an invitation to copy someone's project or acquire their GitHub repo through questionable means.)

Walk around and attend demos. Hackathons pack enormous amounts of knowledge into small spaces, and it would be a shame to spend the weekend accessing only what's already on your laptop.

Step 3: Ask Questions. Particularly the Ones You Think Are Stupid.

There's a peculiar belief among developers that everyone else knows exactly what they're doing. They don't. Some are just better at maintaining the appearance.

Hackathons give you mentors, workshops, and experienced developers who are all there to help people build things. Use them. If you're stuck, ask. If a workshop covers something unfamiliar, ask. There's no noble reason to spend four hours debugging something someone could explain in ten minutes.

Figuring things out yourself is valuable, and getting thoroughly confused is practically a tradition in software development. But knowing when to ask for help is a skill too. And sometimes the best question isn't "How do I do this?" but "Why did you build it this way?"

Step 4: Build Something Great. Whatever That Means.

Ah, yes. The actual project. You may have noticed we're only getting to it at Step 4. This is intentional.

We've developed strange expectations about what makes a project great. Apparently it must revolutionize education, transform healthcare, end climate change, or use AI to fix an inconvenience humanity has tolerated for centuries. Preferably within 24 hours.

Solving meaningful problems is worthwhile, but not every great hackathon project needs to save the world. Sometimes it solves a small problem exceptionally well, combines existing tools in an interesting way, or, especially for beginners, is simply something you've always wanted to build.

Start with something that interests you. Great ideas often begin with "Wouldn't it be interesting if I could build something that does this?" Maybe that's computer vision, language models on physical hardware, a tool for an annoying task, or just a fun game. When you care about the idea, you'll keep going when something inevitably breaks. And something will inevitably break.

Experiment with technology. Don't just collect it. Hackathons are a great place to try unfamiliar APIs, frameworks, and hardware. But integrating a tool because it improves your project is different from integrating it because its logo looks good on a slide or MLH is giving out a prize for it. Good technical decisions aren't about using the most tools; they're about choosing the right ones.

Step 5: Collect Feedback, Not Just Stickers.

Let me be clear: stickers are important. I've been in the hackathon space for over three years, I work at MLH, and I'm obsessed with a good sticker collection.

But you should also collect feedback.

One of the biggest mistakes is guarding your project like a state secret until judging, only to discover that the feature you spent ten hours perfecting isn't useful to anyone but you. An unfortunate discovery to make three minutes before judging ends.

Share early. Explain your idea to another team, run your approach past a mentor, and show someone a prototype to see if they get it without a fifteen-minute explanation. If they don't, or they suggest something simpler, or they spot a problem you missed, that's all useful information.

And if another team is stuck on something you've solved before, help them. You're not giving away your chances of winning. Hackathons are competitions, but they're also communities, and the two can coexist just fine.

So, Did You Win?

At the end, the judges decide. Some teams win prizes. Most go home without a trophy, presumably after locating their chargers and remembering what uninterrupted sleep feels like.

But consider what you've gained. You met people you wouldn't otherwise have met, explored new technologies, and built something that didn't exist when you arrived. Maybe it worked perfectly. Maybe it worked only during the demo, an achievement deserving its own category of engineering recognition. Or maybe it didn't work at all, but now you know why and what you'd do differently.

Winning a prize is wonderful, so work hard and give the judges every reason to recognize you. Just don't make it the only measure of whether your weekend was worthwhile.

A hackathon is one of those rare competitions where you can lose the judging round and still leave with more than you arrived with.

And if you've managed that, I'd argue you've followed these five steps rather successfully.

MLH Hackathons are the best place to lean, connect and grow in the tech space. So, at your next MLH Hackathon, don't forget to follow the 5 steps and don't forget to grab some awesome stickers and swag!