How to win a Hackathon by CC Mark
Meb (Mark) is a core contributor and protocol engineer at Synthetix. And while he is known in the Synthetix community for being a gigabrain protocol engineer, what perhaps is not so well-known is his impressive hackathon track record.
Because, when it comes to hackathons, Meb slays. He has won more than ten crypto and non-crypto hackathons and has five ETH global hackathons in the bag, including ETH Denver, ETH Berlin, and ETH SanFrancisco. So what is his winning formula? Meb shares his must-dos and must-don’ts as we enter the 2023 conference season.
Not financial advice.
The Do’s
-
Come prepared.
- When you think of crypto Hackathons, you may think of tired teams hunched around laptops, surrounded by half eaten takeaways in crammed venues or hotel rooms. They may seem a little chaotic, and they can be, but they’re also an incredible opportunity. Some of crypto’s most important protocols were born out of Hackathons - take 1inch and Aave. So you need to take them seriously and come prepared. Some tips:
- Start thinking of ideas ahead of the event and have them written down, ready to casually pitch to others before kick-off to get their buy-in. A team already unified by a shared vision is a great place to start.
- Know what tech stack you are going to use. You want to play where you’re most comfortable, so choose something familiar to you and your team.
- Get the basics right - be well rested, drink lots of water, eat healthy snacks. You should be excited by the idea of 24-48hrs of hacking, but equally prepared for the toll on your mind and body. Optimize with a well-fuelled team.
- When you think of crypto Hackathons, you may think of tired teams hunched around laptops, surrounded by half eaten takeaways in crammed venues or hotel rooms. They may seem a little chaotic, and they can be, but they’re also an incredible opportunity. Some of crypto’s most important protocols were born out of Hackathons - take 1inch and Aave. So you need to take them seriously and come prepared. Some tips:
-
Read the room.
Both literally and figuratively speaking - there are obvious people in the room that you want to have a good understanding of, but equally having a strong understanding of the industry climate before you walk into the room is non-negotiable. Some tips:
- Know what the current state of affairs is in the ecosystem. What problems are people talking about on Discord and Twitter on the regular, and need to be solved for? Ultimately, Hackathons are about solving hard problems. You should already have a razor sharp sense of what these problems are. In a sense, you go into the Hackathon with the ideation phase very nearly complete.
- Know who the sponsors and judges are, and what their interests/backgrounds are. Are they investors, engineers, or in BD? Try to tailor your idea and presentation based on the makeup of your judging panel. Ultimately you are there to wet the palette of this small group of people.
- Leverage the tools and APIs provided by the sponsors. It seems obvious, but people don’t do it. They are there to support you and lead you in the right direction. Use them, and then explain to the judges (one of whom is usually a sponsor and has provided these tools) how you have used them.
-
Get your team situation sussed early.
- Team chemistry and composition is one of the most important factors to both your success, and your overall experience of the hackathon, so you want to get this part right.
- Decide fast if you are working solo or with a team, and don’t waste time on this. There’s pros and cons to both but, imo, the benefits of working in a team outweigh the trade-offs. You have diversity of thought, more hands to do the work, and it generally ends up being a really fun social experience.
- If you do choose to work in a team, try collaborating with new people. While working with the people in your everyday team/dao is always going to be great, you know their perspectives and wheelhouses. Reaching out to new people will give you a richer experience with more opportunity to learn (and network).
- Be sure to diversify your team skills, so that you are operating like a mini-dao. Ideally you would have one dev, one designer and one marketer for a well-rounded concept and output. Chuck a BD person in the mix and you’re humming. Knowing each member’ strengths and weaknesses beforehand gives you an advantage in both preparation and execution. Be honest with yours to set the tone - if you’re a dev with very little marketing or presentation skills - let that be known quickly and ask the rest of your team to be as transparent. Being a straight shooter in these situations is advantageous, so you can get on with assigning roles and responsibilities fast and effectively.
- Keep open to all ideas and collaborate hard. Every team member will bring something special to the table.
- Team chemistry and composition is one of the most important factors to both your success, and your overall experience of the hackathon, so you want to get this part right.
-
Have fun!
- The best part of these events are the friends you made along the way. :)
The Don’ts
Here’s my quickfire round of don’ts. I’ve experimented with a few of these so that you don’t have to. None of these are deal breakers, but they can definitely slow down/add stress to your hackathon experience.
- Don’t bite off more than you can chew.
- Scope the project accordingly, if you can’t easily see how to build a proof-of-concept, then it’s too large. There’s nothing worse than stressing the way through the last stretch in full knowledge you’re not going to complete the project.
- Don’t neglect the UI/UX.
- There’s no need to focus too much energy on the technical aspects in a hackathon, just make the thing work. In the short few days of the competition, you don’t have time to set up a backend. Make your lives easier and utilize front-end and Javascript! On this occasion, easy options and shortcuts are your friend.
- Don’t be a perfectionist.
- Don’t waste too much time on polish, just make it presentable. This rings true with the presentation too - don’t overdo it, make it concise, funny, and convincing. They are not judging you on aesthetics or your ability to present (although a confident/persuasive team member to present certainly doesn’t hurt).
- Don’t waste time coming up with the app name - it’s a time waster and it’s difficult to get consensus. Simply start out with a codename, and sudden inspiration will surface as you’re through your project. Who knows - you might even fall in love with the codename instead.
- Don’t stay up all night.
- Don’t do it to yourself. Only if you really need to finish something last minute and you’re nearing the deadline. But you shouldn’t have this problem if you pace yourself and scope the project accordingly. Save the all-nighters for the post-grind celebrations.
And that’s all I got.
See y’all on the floor at ETH Denver 2023 - and good luck to the builders!