Tips for Hackathons, Tips for Life
05/22/2025
I love hackathons. After doing a few, I noticed the skills pushed to their limits during a hackathon are skills frequently used outside of hackathons as well. This is a general list of pointers I’d like to offer for hackathons, with, I believe, takeaways for most group endeavors.
But first, some background.
As of the writing of this article, I’ve taken part in 10 hackathons, won 7, and have helped organize 3 others. Past that, taking part in hackathons helped me land 2 internships during college, and the hackathon I organized helped several of my friends land interviews, then work experiences of their own. The largest hackathon I took part in was 3000+ people, and the smallest was a local event with around 20 high schoolers. This is my devpost, which contains most of the hackathons I’ve participated in. Essentially, I’ve been forced to think about hackathons quite a bit from organizational, mentorship, and participatory perspectives.
I’m also going to list out a few assumptions I’m making for this post:
- You, the reader, are engineer-adjacent, i.e., someone who could and would take part in a hackathon.
- When I talk about a “hackathon”, I’m specifically referring to 24-48 hour software development competitions done in teams of 1-4. However, many of the takeaways here apply to similarly scoped events.
- There are three general reasons a person might want to invest their time and energy into a hackathon– personal growth, material rewards (acclamation, cash prize, networking), and enjoyment. Since the third is entirely subjective, I’ll spend my time talking about the first two.
Without further ado, here are my tips, split into the segments of a hackathon, chronologically. I’m breaking up thoughts into growth, reward, and general (relevant for both) categories. Important tips are highlighted, and apply fairly strongly outside of hackathons as well, in other technical contexts.[1]
Before applying to a hackathon |
General - Figure out what you want. For every hackathon I’ve gone to, I’ve broken it down into the growth vs. reward vs. fun system
- Figure out what you’re giving up (time, energy, travel expenses)
- Figure out if you’re going with friends, or if anyone you know is going
- At this point, you should be able to conclude whether you want to go to the hackathon at all
- Getting accepted to go to the hackathon is not a given
- However, the effort to apply to most hackathons is trivial. It’s almost always worth a shot
|
Growth - Determine what skills you’d like to use, or frameworks you’d like to get familiar with
- Start brainstorming things you’d like to build in the back of your mind to accommodate those goals
|
Rewards - Take a look at the hackathon’s schedule and prizes (if they’re up yet). Barring that, see if you can find anything online about past events or sponsors they brought in
- See if you can find a list of mentors or sponsors. It’s 100% worth reaching out[2]
|
Before starting development |
General - First, find a team. A good teammate has one (ideally more) of the following:
- Expertise in a skill you don’t have or would like to improve
- Organizational capability, or the ability to diagnose problems
- Your trust
- It’s helpful to assign roles early. These probably will change a bit– that’s ok. They’re for getting everyone sprinting ASAP
- Second, find an idea
- Already have an idea? That’s ok. But don’t try to build a team around an idea unless you’re very good at pitching. Everyone will be happier and have more buy-in if you come up with something together
|
Growth - Start previewing the skills for the idea you need. There’s a fine line here between prepping and cheating, but there’s no harm in setting up your software environment
- In practice, this looks like
- Finding guides
- Doing research
- Foreshadowing problems
|
Rewards - You’re going to want to get to know your team fairly well. They’re going to be the closest friends you make during this thing
- Read and understand the prize requirements to inform your project idea
|
During crunch time + judging |
General - No matter how crappy your work is, submit it and present. You’ll learn from this
- As you near the end, you might have to cut out some of the last steps in your plans. That’s ok. Be honest about it and mention it for “next steps” in your submissions
- Remember you’re going to have to present your project to judges
- Make sure at least one member of your team is fresh enough to present
- Put aside time and energy to prep the submission
|
Growth - Consider pulling an all-nighter. Athletes have PRs– why are you any different? It’s worthwhile to find your limits
- Non-technical learning is also learning. Pay attention to the submission, videomaking, and presentation process, because making a good project is only half the fight
|
Rewards - Victory is at hand. Get ready to sprint
|
Starting development |
General - Make a roadmap with your team. Set goals on what you need done, when
- Pay attention to blockers– things one member of the team might depend on another for
- Scope things down! You’re going to be able to do less than you think, because things will go wrong. You can always do more if you have free time later
- Stay flexible. You might have to throw out a lot of work at the start. Remember sunk cost fallacy and actively work against it
- Remember to take breaks, ideally when you’re being blocked, because it will probably happen
- Keep an eye on the food, or buy some yourself
|
Growth - Growth is fundamentally about maintaining a balance between overuse and underuse of external help (AI, assistance from a mentor, internet guides, etc)
- You’re going to need to use some of it in order to get work done fast
- If you overuse it, you will retain nothing
- My personal tendency is to start with high usage, then trend down as you familiarize with patterns and tools, then trend up as time runs out
|
Rewards - Check out the hackathon events, if there are any
- The start is a good time to say hi to the mentors. Definitely worthwhile to ask them for tips
- The most interesting projects have stories attached to them. You might already have one in mind– spin it up. This will make it much easier to talk about your project down the line
|
After the hackathon |
General - Recover. I cannot emphasize this enough. Your body will know how much you need to sleep
- Everything in life is improved with a blameless postmortem. Structure it around your original goals. If your team is up to it, do one with them. If not, do one yourself, and bounce it off someone who’ll be willing to challenge your perspective
- The discussion bit here is entirely necessary. Don’t skip it
|
Growth - Follow up on the project you built and the skills you developed– if it’s worth it. You have a taste of the work now, so you can come to that conclusion yourself
|
Rewards - Collect your prize! (hopefully)
- Follow up with the people you met. Thank the mentors and volunteers, connect with the sponsors
|
And don’t forget– have fun!
[1] Hackathons are a leaky abstraction of “real” projects. They are shorter, scoped down, and provide clearer criteria. At the same time, they are usually an order of magnitude more intense, and the competition is in many ways more direct as well. What this means is that the basic premise of some of these tips can and should be overlaid onto other contexts
[2] If you’re a student, there’s really no reason to not reach out. A teacher of mine once put it well – “people are going to be more receptive because you’re just a kid, in the eyes of the world.” This might be annoying to hear, but you should take advantage of it.