How to win at hackathons!

I had an unexpectedly amazing time on the 8:30 bus to Chicago last Friday. I met a stranger that I really clicked with, and that meant our conversation was a game of Olympic ping-pong, ideas zipping between us at lightning speed. We eventually talked about why we were heading to Chicago in the first place: me, the airport; him, a hackathon.1 I’m the lucky owner of a 6-0 hackathon record,2 so I gave him some advice.

I got this message two days later:

Most of the stuff I create in public comes from the mentality of “I talked about this with at least one person who found it useful, so I should broadcast it broadly.” Here’s the latest!

Seriously: why do you want to win? “First place” is just a title. Do you want it for your resumé? As a cool story to tell your friends? Because you’re a competitive person at heart?

Thinking deeply about this question—and being radically honest about your answer—means you’ll be able to find your actual goals, which you might be able to achieve without winning in the first place.

Is your goal to boost your resumé for a specific company? Your “win” might mean building something with their tech stack. Is the event in the middle of midterm season? Make it a point to avoid all-nighters! A win for you might mean attending every software workshop, or making new friends, or pulling aside that famous guest speaker and peppering them with questions about their 40-year tenure at NASA. Your best course of action is entirely dependent on your goals.

The advice that I’ll be giving only makes sense if you want to win a prize, which is a very narrow goal with its own set of tradeoffs. My advice also only makes sense for a certain kind of hackathon—you know, those in-person, software-kitbashing, college-student-oriented ones. Your goal (and your situation) may be completely different.

…but if it is your goal to win a prize, and you are at one of these hackathons… read on!

You want to win. The judges determine the winners.

Therefore, to win at a hackathon, you must impress the judges!

This will guide every decision that you make. Consistently think: does this action take our team closer towards impressing the judges?

In practice, this means two things:

1. There are implicit guidelines for successful hackathon projects.

   1. You don’t need a minimum viable product, you need a minimum presentable product.

      1. If you have errors flashing in the console, but the live demo looks fine, you’re doing it right.

      2. Remember, your goal is to impress the judges, not to build a scalable and production-ready Kubernetes cluster. (Unless that’s how you’re impressing the judges, because you’ve determined that this is a very technical hackathon.)

   2. Try to prioritize project ideas that are flashy. Does it have a wow factor? Does it lend itself well to visual effects? Does it do something novel or clever with existing technology? Does it solve an actual problem?

2. Knowing who the judges are and how you present to them become critical points of information.

   1. Some questions you can ask:

      1. How many judges are there? Do you present to one judge at a time, or a panel?

      2. Do you get slides?

      3. Do you get to talk over your slides? How long do you get?

   2. Judges need not be technical! I’ve seen CS professors, but also members of industry or friends of the event organizers. Know your audience!

At hackathons, there are many ways to win. Most hackathons have prizes beyond the podium—Best Presentation, Best Beginner, Crowd Favorite—and company sponsors that offer their own prize tracks.

So, some questions to ask:

• How many prize tracks are there?

• Can you apply to multiple ones?

• Are the prizes announced before the competition or during? Can you plan ahead?

• Are there prizes that few teams will go for, and thus you’ll have less competition?

Make sure to scope out the event format and gauge your level of competition. It may be the case that the pool of competitors is so small that half of them get prizes. In other cases, you may need to get very lucky, or be very good. Adjust your strategy based on your answers to these questions.

If your goal is to win, then it helps to ensure that you have a good team before you step through the doors. Gather up some friends that you click with and get to work!3

Team size doesn’t really matter as long as you’re not solo (because why are you there) and not too large. Don’t feel pressured to go to a size of 4 just because that’s the max size! What you gain in potential output, you pay in coordination costs.

You can prepare beyond just the people, too. It’s expected that all of your code is created during competition. But, notice—this doesn’t say anything about the idea.

We knew the NASA Space Apps organizers would release the project tracks ahead of time. We met up a week before the event, combed through the options, and picked one out ahead of time. When the event began, we set off sprinting!

(Shoutout to my teammates—Max, Rahul, Brennen, and everyone else I’ve worked with. It’s been fun!)

Our team did one thing very differently than others: we spent a lot of time choosing a good idea.

Look, I get it: at hackathons, there’s a lot of time pressure. The countdown begins, and you see the other teams darting ahead with their laptops and full desktop PCs and mobile battle stations and you feel the need to get started right away:

How long do you think it takes to find a good idea? Ten minutes? Half an hour?

For what it’s worth, we once took nearly 2 hours out of our allotted 24 to settle on something good!

Here’s a couple heuristics:

• Does the idea have a wow factor?

• Is it visually appealing?

• Does the idea fit a prize track? If the venue allows multiple prize tracks, can it count for multiple?

• Does it solve a real-world problem?

• Is the core of the idea small?

  • It’s almost always better to get the core features done and integrate them well. You can take any extra time you have to tack on bells and whistles. (Or sleep. Up to you.)

• Can you see a path forward to expanding on it after the hackathon ends? You can make this up!

You know what prize you’re gunning for. You’ve assembled a rock-solid team. You’ve chosen an idea that sets your soul alight, and you can practically see the final product assembling in real time.

Execution matters a lot more than any advice I can give here, but here’s a few pointers regardless:

• Don’t step on each other’s toes. Everyone on your team should be working all the time, and ideally on different features. This means you need to coordinate! It’s often helpful to have a glue guy.4 At Hack Midwest, I was checking in with everyone every 30 minutes. Just a quick “hey, what are you working on?” works wonders.

• Use best practices for merging code. Bad Git management and version management will always, always come back to bite you. Take the time to set this up right. This is one case where slow is smooth, and smooth is fast!

Another thing that our group did different than other teams: we took a lot more time than most to make (and practice!) the final presentation. I genuinely think we won MadHacks 2023 because we spent the whole morning practicing and refining our pitch.

Some quick pointers:

• Set aside time to practice your pitch with your team! Give everyone a chance to talk.

• Clean slides take deceptively long to make, which is a problem when time is limited. Try to walk the line between “making it look good” and “spending 30 minutes on something that’s only going to be on the screen for 30 seconds.”

Here’s the slideshow cookbook we used at MadHacks 2023, and have stuck to ever since:

1. The Problem. What are you trying to solve? Try to emphasize its importance, either through statistics or description.

2. Existing Solutions. Cherry-pick sources and fudge the numbers. You’re trying to communicate that existing solutions suck.

3. Your Solution. Hype yourself up here. Show off your features, connect it to the problem, show that it solves it. Give a live demo whenever possible!

4. How You Built It. Show off the tech stack. Talk about the design decisions that you made and the obstacles you’ve overcome.

5. What's Next. Talk about improvements to existing features and what new ones you'd add. You don't even need to be realistic here, you just need to sell a story!

Hackathons are amazing little arenas with lessons that generalize to your career and life in general. Perhaps the most applicable lesson is this: have fun, because you’re only there for a short time! Enjoy your experience, take lots of pictures, make good memories, and always remember to thank the organizers.

If you end up winning a hackathon after reading this, shoot me a message! I’d love to hear your story.

Happy hacking!