A hackathon is an event where developers get together for a limited time (it can go from a few hours to a few days) to collaborate on a project.
There are many types of hackathons: internal to a corporation or open to the public, independent or as part of a conference, themed or topic-free, limited to a set of technologies, or open to anything, etc. And not all of them are competitions. Some are collaborations to achieve a common goal (and these are as fun and fulfilling as the competition ones.)
I have participated in many hackathons with different results: sometimes I've won, more times I've lost, but in all of them, I've had fun and enjoyed coding and networking with different people.
In this article, I will describe how I approach hackathons (or at least how I try to approach them.) It is based on my own experience and in hackathon competitions where you get to pick your project idea (even if it's within a specific topic.)
Article contents:
Introduction
Let me start by saying: winning a hackathon is not everything. If you win, but you are in a project that you don't like, you will feel miserable most of the time. So, rule number one of a hackathon: enjoy and have fun!
Embrace the event: build your project, but also hang around to see what others are making (if there's a chance), offer help, chat with people, network. Some of those connections may grow into new projects, friendships, or job opportunities.
The Idea
I am going to say something that many people will disagree with, but from my experience, it seems like the norm: your hackathon idea will die with the hackathon. Most hackathon projects are born, grow, and die with the competition. Rule number two of a hackathon: don't get too attached to the idea.
Of course, there are exceptions, but they are normally extraordinary projects. I can count all the projects that ended up completed and delivered after the hackathon was over with the fingers of one hand. Especially if it was a team project.
Keep your side projects as your side projects, and go to the hackathon with something different and fresh. A killer idea that will blow everyone's mind.
A killer idea
A hackathon winning project must fulfill three requirements:
- Be original
- Be practical
- Have a "wow factor"
Most hackathon projects don't check these three boxes, but all winners usually do. There is also one more thing that is not necessarily a requirement, but I would highly recommend:
- Fit the time scope
A hackathon idea that fulfills these four points is a killer idea. It may not win -there are too many other factors- but it will be up there for sure. So, rule number three of a hackathon: find a killer idea (more of a goal than a rule, though). Something easier said than done. And that will determine most of the later outcomes.
Let's see each of them.
Be original
The concept of originality is a bit fuzzy. What is original for a person may not be as original for others. For example, I have seen the same idea presented to two different hackathons with over ten years difference, and both projects won due to their originality (check Examples of Killer Ideas for reference.)
As they say in imgur -mainly as an excuse to repost content, but that's a different story-: "It is original if I haven't seen it before." Is the idea original if most people (or at least the judges) haven't seen it before? And the answer is a resounding "yes." In this case, "original" doesn't mean "new", it means "unusual" or "different."
If you can't come up with an original idea, a tactic that generally plays well is building something that mixes APIs and technologies. It tends to generate projects somewhat original and with a wow factor: combining social media with sentiment analysis, using the standard Web APIs (people don't realize how many there are and how powerful they can get) with a day-to-day issue, public data with AI and graphs...
Be practical
The hackathon idea has to be something practical. It must have a function or be useful for something. And again, the concept of practicality may differ from person to person. For example, a video game may not seem practical to some people, but many others will want to play. It is useful in that way.
A practical idea needs to be useful in some way or form. But the opposite is not always true: an useful idea may not be practical. For example, building an app to connect people (like to charities, NPOs, or clubs) sounds like a nice and practical idea, but in reality it is not (at least not for a hackathon.) It will require development well beyond the hackathon time, and on top of that, it requires data and connections (and in some cases personal and/or tax information for legal purposes) that are not commonly available, and which may take time, negotiation, and money, to collect. It doesn't look so practical now, does it?
As you might have noticed from the previous paragraph, even when it may not seem like it, this requirement is closely related to the time scope one. A practical idea that cannot be developed within the timeframe of the hackathon may be a great idea... just not for this type of events.
Have a wow factor
Having a "wow factor" is not the same as being original. It's something impressive that will make the judges smile, and other attendees' jaws drop and wish they were in your team. It's what will separate your idea from the rest.
It can be present in many ways. Sometimes it's a revolutionary design, the application of a different peripheral, or just an unexpected use case. It may be the most difficult of the requirements to accomplish, but when you do, it's great.
One crucial thing to consider is that having a wow factor is helpful in non-corporate hackathons, but not so much in corporate ones. Companies focus more on the idea's development and practicality than on the project's pizzazz. It is unfortunate, but it makes sense.
As mentioned above in the "be original" section, using different APIs or technologies (and gadgets) is a great way to achieve this. Building something "classic" with new technology triggers nostalgia and can help with the wow factor, too.
Fit the time scope
There are two sides to this requirement: one is related to time management and having a "realistic" approach to things, and the other one is more about "honesty."
If the idea would take more time to implement than the one you have for the hackathon, then it is a side project, not a hackathon project. The scope goes beyond the event, resulting in rushed development, poor design, bad experience, etc., which is both bad and sad because it may be a great idea, but it is the wrong stage for it.
When picking an idea for a hackathon, make sure that you can develop it within the event's time frame. Don't rush things, and don't "cheat,"... which brings me to the second part. (And this is more of a personal preference.)
You often get to the hackathon presentations and see projects that are so perfectly crafted and designed that you -and all the participants- know that they didn't do it during the time of the event. The presenters have been doing (a lot) of pre-work, which leaves a bad taste in everyone's mouth.
Be honest to yourself and the rest of the participants. Don't be afraid to present something that is not polished or only half-baked. You are not submitting an idea to make millions. You are at the hackathon to have fun (rule #1) and remember that, most likely, the project will die with it (rule #2).
There are no silly ideas for a hackathon. Some people may think the idea is ridiculous, and others believe it's original and quirky. In reality, silly ideas win more hackathons than "super-serious" ideas.
Rule number four of a hackathon: there are no stupid ideas, just ideas that need some polishing. Polish them BEFORE the event. I keep a log of "hackathon ideas," and, depending on the event, I see if I can use one of the existing ones instead of coming up with something new.
Development
This is the part that most developers cherish. But in my opinion, and I know many people will disagree (again): the development is the least important part of a hackathon. (It will depend considerably on the type of hackathon.) A good presentation of a great idea will compensate for poor programming or lack of features. But a great implementation won't lift a bad idea.
Also, hackathons usually are short, fast-paced events. Developers often put aside the best practices to advance as fast as possible. While that's terrible for day-to-day work, it makes sense from a hackathon perspective. And anyway, it's not like the project was going to go much forward after the hackathon (based on rule #2 described above.)
While talking about development, here's rule number five of a hackathon: a hackathon is not the right place to learn a new language. You can learn new functionalities, an API, upcoming language features, etc. But going to a hackathon with the mentality of "building a project from scratch using a language I have never used" is a bad idea. You will not complete the project, and you will most likely not learn the new language, or at least not the proper use of it.
A similar rule applies to other technologies: a hackathon is not a place to reinvent the wheel (unless reinventing the wheel is your project.) To speed up the development process, don't hesitate to pull modules, libraries, or APIs.
If the hackathon is with teams, try to build a compensated team: if everyone is a developer, you may finish the project, but it won't likely look great. If there are many designers and only one developer, the development part will struggle. Make sure that one person plays the role of PM, keeping track of progress, and have a dev double as a tester.
The Presentation
After submitting the ideas and developing the project, it is time to present. A vital part of the hackathon: the presentation can elevate a mediocre idea and make it competitive, or take a great idea and destroy it. That's why it's surprising to see how many participants often seem to focus less on this part.
This section of the hackathon is also excellent for practicing leadership and soft skills: public speaking, communication, assertiveness, sense of humor... These are important skills as you grow professionally.
When preparing a presentation, it is essential to know your audience (rule number six of a hackathon.) What you talk about and how you do it should change depending on the audience. You wouldn't present the same to developers, business managers, or executives. For example, we recently submitted an idea for a corporate hackathon. Dev leaders judged the first round, so we focused on the technical aspect of our solution: what we used and how it would be useful. But when we made it to the final round, to the executives, we presented how our solution would be useful and how much money it could save to the company.
The presentation will vary considerably depending on the available time, but in general, you should always try to touch the following points:
- Team introduction: keep it short and simple.
- Description of the problem: the "why?"
- Description of the solution: the "how?"
- What is the outcome: benefits of your projects.
If time permits it, I like including a small joke in the presentation. Usually, judges see dozens of presentations, many of them could be considered boring, and it's easy for them to "drift away." By adding a joke (between 1 and 2, or 2 and 3), you get their attention back, and then you can present the main part of the project. Plus, it will make you memorable.
Conclusion
I have experience participating in many hackathons performing different roles, but I wouldn't consider myself an expert. I have won sometimes; most times, I went back home empty-handed. But I can say I've had fun and learned something new in every single one of them, and that's a big win in my book. What I'm trying to say is: take this post with a grain of salt.
If there's any takeaway from the article, it should be: have fun. Enjoy participating in the hackathons. They are fantastic events for developers that allow everyone to interact, cooperate, and network. I cannot wait for the pandemic to be over to attend some more in person (instead of virtual.)
If you want to have more takeaways, remember the "rules of thumbs" of a hackathon:
- Have fun and enjoy.
- Don't get too attached to the project.
- Find a killer idea: original, practical, and with a wow factor.
- Learn new things.
- Know your audience.
Examples of killer ideas
F*CK AT&T
If I recall correctly, this was a Tech Crunch Disrupt Hackathon in 2009 or 2010. The iPhone was an almost-exclusive product for AT&T. The unlimited plans were not as popular as they are now, and the service provider was notoriously famous for having many drop calls (and for some high call connection fees.)
A developer came up with an exciting project: the iPhone has a database with a log of all the calls, durations, status, and end reasons. If he could prove that many of the dropped calls were not due to the iPhone itself but to poor service by AT&T, they could start a class-action lawsuit against the communications giant.
During the presentation, he showcased how AT&T had dropped a high percentage of the calls, and he did the same for some attendees in the audience. In total, AT&T had charged them a small but potentially significant amount.
The project was great: original, with a wow factor, practical, great presentation... The idea caught on, and it won the hackathon. As far as I know, it died there. It didn't move forward, no product was released, and no lawsuit came out of it -rule #2 of the hackathons.
Video game Eye controller
Imagine controlling your favorite video game without a game controller. Just using your eyes. Look up to jump, down to dodge, and to the sides to move right or left. You can even blink to perform some action like shooting or grabbing something.
I have seen this idea presented in hackathons spanning three decades (the 2000s, 2010s, and 2020s.) It is an interesting project because it "breaks the originality rule" but is quite successful nonetheless: every time I saw it, the idea ranked high or won an award. As they say online, "it's new -and original- if I haven't seen it before."
The technology changes, and so does the video game used as the base (Mario, the Chrome offline dinosaur, something more original). In the 2000s, Flash was the main development driver, and in the 2010s and 2020s, it was different technologies but mostly JavaScript and different APIs.
Dance-Dance-Revolution... in JavaScript
My daughter and I won a hackathon with this project a couple of years ago (I did all the coding, she did the testing and quality control). The idea in itself was not super-original, but it has a wow-factor (especially during the presentation.)
Imagine connecting your Dance Dance Revolution (DDR) pad to your computer and being able to dance to any song, or connecting your USB Guitar Hero/Rock Band guitars or drums and playing anything you want. Even songs that would never make the actual game. Not being limited by any game or publisher.
It is possible -and actually, pretty easy to develop- using the Gamepad API and combining it with Youtube or any other video/music service. The result is a fun, impressive demo. And you can personalize the music selection to match the hackathon (or the judges) and get some brownie points.
Intelligent Welcome Mat
This project was a combination of APIs, hardware, and social engineering. And the presentation was a fun, interactive event showcasing the final product: a welcome mat connected to an Arduino connected to the Internet that detected the owner's mood and greeted the person accordingly? That sounds like fun!
The mat would detect when someone stepped on it (it had a pressure sensor), then it checked the owner's Twitter account (using the Twitter API), read the last few tweets, and ran them through a sentiment API to detect the person's mood. Based on the results, the mat would welcome the person with a message or another (with a small speaker attached to the mat.)
Independently of the practicality of the idea -won't so much hardware be a problem on a rainy day?-, it has a fantastic wow factor. If I recall correctly, this idea did not win, but it was one of the runner-ups.
iPad holder
The year is 2010, we are at a Tech Crunch hackathon in New York City, and Apple just recently released the iPad, so there's a lot of chatter about it (and the market is lacking a lot of accessories for the Apple's tablet.)
A young man goes up the stage with an iPad and presents his idea: he shows his iPad, takes two pieces of velcro out of his pocket and attaches them to the back of the tablet. "Now I can easily watch my iPad with just one hand without it falling or tilting. Behold, the iPad holder!"
This project won an award for its originality! And is an excellent example of how not everything you need to do in a hackathon has to be related to software or be a great project.
Top comments (0)