Ideas.
Code.
Caffeine.
On minimal sleep.
What is a hackathon?
A hackathon is a set time frame, usually 24 hours, where teams build something. They can either be for fun or competitive. For-fun or non-competitive hackathons often revolve around flexing creative muscles while building community. Many can even be for the benefit of non-profits or to contribute to open-source software. Organizations like GiveCamp help organize large hackathons worldwide and make it easy for developers to get involved. (Running a GiveCamp is a great way to flex your leadership skills).
At the end of the time limit, they present their creations to an audience. Depending on the types of hackathons, the winners can take home fantastic prizes, like funding for their idea, credits toward services, or cold, hard cash.
The primary goals are to get people out of their comfort zones, try new things, and something incredible within a set of constraints. You’ll come to notice that not all hackathons are created equal, so understanding the context of the one you are entering is of paramount importance.
There is a formula
What if I told you there’s a formula for winning hackathons?
While every hackathon is different, and the strategy in how you prepare, build, and present is different. In this article, the definition of winning is taking home first place or a top prize, but there are other incredible benefits of hackathon participation that can be equally important. You can "win" by becoming better as a developer or entrepreneur. You can "win" by networking with others. Keep that in mind as we start with the first step – preparing for the hackathon.
Know the rules
The first and the most non-negotiable rule of winning a hackathon is to know the rules. You don’t have a shot if you are disqualified from the competition or fail to meet the requirements. If the rules state that you must use a specific service or technology, you must use that technology. If there is a requirement for a certain number of teammates, then meet those requirements. This leads to the next softer rule of knowing the audience.
Know the audience
Knowing the audience helps give your team and your product focus. If the hackathon is based around high innovation, then a to-do like application will likely not win. If the theme is "hack for non-profits," then a robotics project based on drones will probably not help if the non-profits present are lower-tech office workers who just need a new website. Keep in mind who is attending, the hackathon theme, and what the people attending are looking for. This is particularly important for winning the "people’s choice" awards where the audience votes.
Know the judges
The win and the loss are ultimately in the hands of the judges. When planning your idea, it’s crucial to know who the judges will be, their industries, and their background. Each judge will bring with them biases, personal interests, and philosophies of what a winning project will look like.
An angel investor is likely highly focused on ROI and innovation. What would the market look like, and how much could this potentially be worth?
A judge with a marketing or sales background will likely be excited by things that show well.
If a particular judge has a clear stance against the continued increase in mass surveillance technology will likely not vote for you if your project requires a camera in their bedroom.
The key here is to find hard-negative biases to avoid while looking for a project idea that hits the excitement button in some way for each judge.
The Team and The Idea
"If you want to go fast, go alone. If you want to go far, go together." is a quote that applies so well during hackathons. When selecting a team, the main tradeoff is that the fewer people you have, the faster you can pivot and move, while each additional person adds communication overhead. Additionally, you want to balance something that is both ambitious and doable. Understaff an idea, and you won’t complete it. Overstaff a plan, and it leaves someone sitting on their hands at best, or at worst, will slow you down.
It’s best to keep the team small, particularly before you solidify an idea. Two or three people total is best. These key individuals are your "founders." They are both idea machines AND can execute. If the work for the idea can be evenly distributed between the three, then continue with the team.
If the idea is ambitious enough to need more people, then you’re at your first crossroad to "go far." You must stop and determine if the execution you are planning can support more people and decide where the "snap points" or interfaces will be.
As developers, we’re familiar with the concept of an interface. It’s a contract between two types – a bridge that allows developers to build pieces of a program, totally isolated from each other, and have some semblance of a guarantee that the two will work together. This concept and construct is the key to building larger projects in a shorter amount of time. The most effective software leaders know how to use interfaces to effectively divide and parallelize work, and it’s a vital skill to have if you intend to ramp team size.
In one hackathon, my team won by building a universal search for an existing application. It was similar to how the Windows key works on Windows or Command + Space works on Mac OS. We started with a team of 3, where we created an interface for services to search different parts of the program. One person built a service for the navigation and menus, and another the user search service, and a third built the UI. This division of work allowed us to agree on a common language between the services and, once complete, gave us the unhindered freedom to work in parallel for the rest of the time. Once we realized this, we recruited two more people to help build other services. Since an interface was in place, we were able to parallelize that work as well.
Look for ideas that have parts that can be broken off. This gives you the power to be more efficient in building a real demo of your design or product and ultimately gives you the edge over the competition whose idea is less complete. Ideas are cheap. Execution is everything.
The Execution
The execution.
The demo.
The prototype.
This is where the fun begins. It can generally be a hectic segment. If you did your due diligence in planning and team building beforehand, your goal should be clear. Break up the work and start building. Pivots and questions are sometimes inevitable. If you see that you are running into unforeseen issues, sometimes it’s best to pivot in a new direction, or at least mock a particular service or part and note the assumption.
Some hackathons, such as Startup Weekend, have designated business and technical mentors. Keep in mind any resources available to you during the hackathon and take advantage of them if appropriate (my #1 tip would be any free snacks, of course).
For picking technologies to use, some people try new tech to learn. If your intent is to win, use safe and known languages and technologies for core parts of your prototype. Only use new or unknown tech for required pieces that relate to hackathon rules, if possible. If rules say no code should be written until the competition starts (most do), then think about the code beforehand. What might it look like? Many times you imagine what structures and integrations will generally look like before you code, so run things through in your head to ensure a clean implementation.
The Presentation
The final presentation is critical. It can make up for execution missteps, and it can lose the competition for an incredibly well-built prototype.
First, choose the best presenter on the team, who is most comfortable on stage. This isn’t always the leader.
Next, craft the story. Think of the judges and the audience. What ideas are they interested in, and what stories can you tell during the demo that they will connect with? Keep in mind the original goal of the hackathon. If it’s a startup or business-focused hackathon, then be sure to include all the essential numbers. Include data about the market, ROI, relevant competitors, etc.
Finally, be sure to nail the ending. Have a final slide or come back to the most important questions and remind the judges and audience of what they just saw. Why is this the problem to solve? Why now? Why is this the right solution and not something else, or nothing at all (many times in business we aren’t fighting against competitors, we’re fighting against customers or people doing nothing)?
In Conclusion
Hackathons are incredibly rewarding and pack incredible amounts of experience and learning into a small amount of time. I recommend everyone participating in one at some point in their career (the earlier, the better). Have you participated in a hackathon? If so, what helped you get the edge over the competition? Or, what did you do that you might do differently in the future? Leave a note in the comments and let me know.
Happy hacking!
