Ok, this is my first Medium post and it covers a lot of ground so I'll try to keep it as brief as I can. Constructive feedbacks are appreciated and be my guest to continue the conversation in the comments.
I couldn't find "Hackathon Winning " on paperswithcode.com so I believe it's safe to assume that we're still quite far from dealing with a modeled problem. Everything from this point on is solely based on my past experiences and worldview, don't be shy to share yours.
Keep in mind this is all coming from an engineering perspective (well, mine) but the following tips are applicable to any sort of role you take up in your team. Hope you like it, nice reading 🤓
I'm no specialist hackathon winner of any sort, but last week the whole "competitive-project-weekends-thing" a couple of friends introduced me last year took uncharted proportions.
With the COVID-19 pandemic, local events that would, as previously usual, stay hidden away inside Ivy Leagues, tech giants and governmental facilities suddenly had to deal with an all-remote model in the most brutal way possible. I bet this forced many organizers to move over to platforms such as Devpost and pull some uncalled-for all-nighters but, look at the bright side: they now count with a reach many orders of magnitude higher.
Such decentralization is game-changing for participants as well. Hackers can now not only pull Monster-fuelled marathons from the comfort of their home, but also run for larger prize pools judged by names they could only dream of meeting in person.
On May 2020, the cross-continent project ImmunoLynk I helped bring to life won the Lumiata COVID-19 Global AI Hackathon, judged by none other than Edward Frenkelm, Vinod Khosla and Aneesh Chopra, among others. Yes, the tech mind behind Barack Obama for four years straight as the first CTO of the United States of America looked at our project and probably said "hey, that's pretty good".
What amazed me the most with this all-remote transformation was new technology debuting in mere months. Cryptochick's Planet Wide SOS Hackathon voting ran through the Alchemy dapp with a new way of delegating voting power to judges, organizers, participants and donors - all running through the power of blockchain.
As you can see from the picture above, we managed to finish first once more. This time, Vitalik Buterin was one of the judges. Satoshi 2.0. Smart contracts pioneer. Biggest name in blockchain development ever. Llama enthusiast. Senpai.
This was a game changer for me. Not in a hundred years would I imagine standing side-to-side (albeit in a virtual environment) with Ethereum's inventor and even present a project to him. Being recognized by one of my top idols is what made me think "we're onto something here and more people need to get into this" and basically write this story today.
So, without further ado, next up I'll go over five tips I can give hackathon participants based both on my successes and failures throughout this brief but turbulent period.
Hackathons may resemble your innocent high school science fairs or startup weekends, but they're actually more than that. Hacking events are awesome business opportunities for two main reasons:
- They are organized by industry leaders that would otherwise be way out of your league.
- Attendees are people very much aligned with your current career/lifestyle interests. If it clicks, they are very likely to become coworkers, employers or even valuable friends.
I can't stress this enough: forget about the prize, networking is any hackathon's greatest value.
Be friendly, curious and interesting (without forcing it) and I assure you you're not only more inclined to enjoy the event but also very likely to walk out with connections way more valuable than the money itself.
This tip may seem more focused towards in-person events but don't be fooled, it's even more applicable on remote environments. After the MIT COVID-19 Challenge (my first remote hackathon), I suddenly had solid connections with very smart people from Harvard, Stanford, MIT, Columbia, KCL and the list goes on.
Be it on Discord, Slack, Zoom or any other platform, don't be afraid to introduce yourself, talk briefly about your competences/past work and just chat around, specially on pre-event hangouts and first days of hacking.
And that leads us to the next tip:
…the hackathon, the organizers, the judges, their companies, their technology, other participants, existing solutions, current frameworks, recent news, webinars/livestreams, anything you can, as much as you can, as soon as you can. As Sun Tzu once said:
Strategy without tactics is the slowest route to victory.
Tactics without strategy is the noise before defeat.
Without understanding what and who you're dealing with, your project is basically a blind shot. Would you really present the same project, the same way, for George Soros and for John McAfee? What about at a local brewery event versus on the European Parliament?
I really recommend not jumping straight to hacking, but carefully planning your development cycle and business positioning around what you believe is going to stick with the event mentors and judges.
Imagine yourself, a judge, spending years and years developing your product only to see it being used by someone across the world, implemented over a weekend. Must be a great feeling, right?
But, of course, this example is just a small part of the picture. With decent prep-time, you can get a stronger grip on what's already out there and how can your project actually provide value to the community and fit into the ecosystem, victor or not.
Make sure everyone on your team is on the same page and keeping up with one another on brainstorming/early development, this will save you a lot of time and basically give you a head start over other teams.
A very recurrent problem on hackathons is spending too much time on shaping you idea while the deadline keeps getting closer and closer. I've been guilty of that, big time, so trust me, pinning down your value proposition less than 24h before the pitch knowing that only now you can actually code away is not a very productive scenario.
3. Don't start from scratch
But you know what saves you even more time? Not reinventing the wheel.
People like to romanticize so called "movements" or "ecosystems" but let's be a little pragmatic and see them for what they are: daring people continuously copying one another but each time adding their own flavor to the mix. Renaissance would be way smaller if tracing was banned, artists were forced to design their own tools or not allowed to spread fresh knowledge from Italy to the rest of the world.
Think of Github as modern day Firenze with 40 million artists. No matter how innovative your project idea is, chances are someone already developed something similar that can help you along the way. Put their hard work to use, don't forget to give them proper credit, and everyone wins.
On most hackathons, you only have 48 hours to deliver something that you're proud of. It's basically impossible to do everything from the ground up (visual identity, business model, pitch deck, code, deployments and so on), no matter how big or competent your team is.
If you spend tons of time with your codebase, but pitch it with 1996-looking slides and boring narration, you project will seem clunky. On the other hand, if you design the perfect frontend and pitch but rush over backend development, more technical judges will mark your project as shallow.
As you can see, there's no single basket you can put your eggs on, so try and boilerplate as most of you project as you can. From previously-done study, you should already know what's out there involving your soon-to-be solution so don't hesitate to fork, repackage, merge, complement, reshape, translate or give your own swing to existing assets.
4. Don't throw your project away
The single biggest mistake I see hackathon participants doing is also the worst thing you can do to any project you worked so hard on: abandoning it first try. After all, what better template to kickstart your project from than your own?
ImmunoLynk was born at a hackathon we didn't win. On our second attempt (EUvsVirus), we worked really hard once again to mature and improve, achieved results we were tremendously proud of but guess what: we didn't even finish top 50.
Maybe the judges weren't tech-savvy enough. Maybe the judges were too tech-savvy. Maybe your presentation was the last one and people were tired. Maybe your pitch focused too much on a topic people didn't see enough value. Maybe a sudden change on UK's oil price caused an influential judge to pay too much attention on his/her bonds while your team was presenting.
The truth is, hackathons are subjective events. Each person has their own standards for quality, innovation or any other judging criteria organizers can think of. Victories by themselves aren't really good performance indicators since they depend on so many other factors outside your control.
At the end of each hackathon, you should always regroup with you team to discuss the good, the bad, the ugly, feedbacks and, above all, future steps. Chances are, if you spent hours and hours working on an unpaid project, then you truly believe in it.
Don't let a defeat hold your team from further developing your project, specially since it only improves future chances of victory.
There are so many other events going on all around the world that you now have access to, one of them can be the perfect fit for your project. Even better, a mentor, a judge or any other participant could be willing to help you take the idea to market or present you to someone who could.
5. Make it fun
Try out a new programming language or software. Finally play around with that framework you saw release a couple days back. Study that weird tech everyone talks about but no one uses. Think outside the box on a market you know well. Think inside the box on a market you know absolutely nothing about. The sky is the limit.
You finally have an excuse to hardcore focus on something. Take this opportunity to do something that provides value, if not to others at least to yourself.
Don't "just work". This isn't your regular Monday, so don't behave like it's one. Enthusiastically look for more knowledge, resources, opinions and take the most fun route to victory.
With this mindset, no matter how frustrating the L is or how rocky the hackathon road proves to be, at the end of the day (better yet, weekend) you'll walk out a better person thinking:
Well, at least I learned something. Now I know how to do *this*, and use *that*, and have so many awesome friends from diverse backgrounds…
I'm glad you made it this far, thank you!
Overall, these were very general tips that I believe make all the difference. I wrote way more than I expected and I though of so many other tips along the way this could be just as well a top 10 list.
Hackathons can be life-changing events and suddenly put you on the spotlight. I mean, they helped me get my university to recognize my work once, twice, ok some times; local media also covered the last victories and even crypto news jumped on the matter.
I really hope you consider taking part in this kind of competition so each time they're taken more seriously and resulting projects can cause greater impact on society and on us, participants.
If you liked what you read, let me know so I can put out more other stories like this. Maybe my next post can be more focused on hackathon-level engineering or something like that.
The day I’m posting this is actually my mother’s birthday, so happy birthday Mama, congratulations on your english test score, be safe, luv u 🖤
Now, with the precious tips out of the way (and in your brain hopefully), all I'm left to say is..