I decided to share some insights based on some recent experience participating in various crypto/web3.0 hackathons to help others who are considering going down that path. The hackathon ecosystem is thriving recently but as a side effect is also becoming complex and confusing to navigate to the newbie. Hopefully this article will save you some time and effort repeating some of the common newbie mistakes I’ve made.
Where to find the best Web3 Hackathons
There are many sources that list hackathons, but from experience, it’s best to focus on a shortlist of hackathon directories that seem to list the best projects:
A. https://gitcoin.co/hackathons – The number one source for quality hackathons, with a focus on the web3 scene and a built-in integration with github. Most high profile hackathons will be listed here.
B. https://devpost.com/ – Another great source that hosts some of the best hackathons in web3.
C. https://hackerlink.io/hackathon – While not as content reach as the two options above, Hackerlink is nevertheless still worth the effort of checking occasionally as it sometimes hosts hackathons not present in the two options above.
What are you trying to achieve by participating in a hackathon
First and foremost, there are many different reasons to join hackathons, and figuring out what your goal is can help you focus on the right kind of hackathons. Here are some examples:
- If networking and industry connections are your main goal, I’d advise to focus on in-person hackathons. While remote hackathons are more common nowadays, they offer little to none true networking/bonding opportunities. Group interactions are typically limited to group chats during the occasional demo/intro/workshop streams and some discord chitchat, all of which are a very poor replacement to IRL encounters. If your only options are online hackathons it would be a good idea to reduce expectations with regards to the networking prospects.
- If you’re in it for the money, you should evaluate hackathons the same way you would any business opportunity: by analyzing your profit expectancy and ROI. Focusing only on prize size is a common mistake. Instead you should also factor in: number of participants per prize, technical level of most participants (this is usually reflected in the discord group chat), the amount of work expected per task/bounty, are you competing against teams or individuals etc. Sometimes a 5k prize with only 2 newbie participants and a week’s work is more lucrative than a 30k prize for an open project that can take 2 months of your full time, for which there are 300 competing professional teams.
- If you’re in it for the learning/professional cred, it would be good to check the hackathon agenda and specific bounties to make sure that: The project you submit can remain public on github, the bounty themes involve deep, interesting tech, the sort you would be proud to present on your resume (some hackathons focus on trivial, “cheap labor” tasks that will not contribute much to your portfolio).
Things you should pay attention to when deciding on which hackathons to join
Here is a list of factors you should check before deciding on participating in a hackathon:
- Transparency around judging – The more detailed the winner selection process is the better. Any ambiguity around who’s doing the judging, how and based on which criteria is likely to result in random (or even biased) winner selection without any reasoning or feedback offered. This can be extremely frustrating if you’re planning on spending significant time and effort on your submission.
- Number and makeup of participants – large prizes draw mass participation that may reduce your winning potential.
- Clear rules on who can participate – I’ve encountered hackathons where established teams with a partly developed product and funding were allowed to participate side by side with projects that started at the hackathon start date. This is clearly unfair and should be avoided.
- Hackathon length of time – Short span hackathon (typically in-person events) are less about building a fully functioning product and more about ideation. If your advantage is in being able to build a working product, look for the longer term hackathons (some go on to two months or more).
- Learning curve – many hackathons aim to raise developer experience and familiarity with a new framework or technology. In these cases it’s beneficial to check how complex this tech is and how long the learning curve, and also if there’s any value in spending the time to go through that curve.
- Open bounties vs specific task bounties – Hackathons that revolve around building anything using specific tech are a good place to kickstart an existing idea you have or as a launchpad for a startup. On the other hand, specific tasks leave you more room to shine with regards to tech and problem solving skills.
- Teams vs Solo participants – If most participants are teams (around 5 team members seems to be the common number), your chances of winning as a solo participant are slim. This is especially true for ‘build a dApp’ hackathon where a wide range of skills (frontend, backend, design) are an advantage. You should look to join a team or move to a more solo participant focused hackathon to stay competitive.
In summary, to successfully navigate the hackathon scene one needs to do some research and evaluate the value of each hackathon in light of their specific goals. There are some great opportunities out there both in terms of networking/exposure and in terms of potential profit. Being able to spot these from the crowd in key to make the most if this fun activity.