How to Win a Hackathon — Tips & Tricks
So far, I’ve participated in seven different Hackathons — four national and three international. Some of them were successful and some were not. But, even in the latter ones, I’ve learned many different tips and tricks that helped me perform better and led me to wins too. Even though my insights may not be too useful for Hackathon-experienced devs, I believe they might be useful for those who have just began their Hackathon adventure.
Through this list, I will consolidate all the things I wish someone had told me before my first Hackathon. Tips & tricks given in this article are related to the software-oriented Hackathon. Before we dive into tips & tricks I need to say one thing — I don’t regret taking part in any of those hackathons, no matter of the results. Even if we didn’t win, I’ve gained invaluable experience and motivation for further learning and advancement. This is why I dare everyone to find upcoming Hackathons and apply for them.
But first, lemme… explain Hackathon
For those who are not familiar with the concept of Hackathon — it is a competition that usually lasts for 24 hours where teams of three to five members are solving a given problem that is related to a specific topic. Solving problems mostly comes down to creating a software product. After 24 hours all teams present their solutions, and presentation usually lasts only five to ten minutes, which is why I’m also going to explain how to rule a presentation in such a short time.
Let’s get ready to rumble!
1. Team selection
The ideal team would be the one consisting of people with different skills and types of knowledge — when skills and knowledge vary. Also, it’s better if team members know each other because it will be much easier for them to get into the flow.
From my experience, the best team ratio is two mobile devs, a backend dev and a frontend dev who also works on the design of application, or maybe a designer instead of one mobile developer. Specifically, that does not mean that in your team everyone must be a developer, nor that you can’t succeed if team members share equivalent skills and knowledge. But, we believe that this ratio is the one that might increase your chances for success.
The team must work as one, or all bets are off. But, don’t forget to set up one member of the team in the leading position. The leader makes the decision whether to implement a particular feature if you have divided opinions about feature validity. Another case is when team gets stuck for a longer time with a certain feature implementation. In that case, the leader should decide whether to dismiss that feature or continue with its implementation.
2. Planning and preparation
A week or two prior to the competition, try to organize an experimental Hackathon for your team with the topic on your own. Experimental Hackathon should take about 12 hours. This way, you will tune as a team and prepare certain things that otherwise would unnecessarily confiscate your time at real competition. By the way, you will solve any problems you encounter, prepare templates and reusable components such as login, registration, forms, admin panel layout, navigation and other components that appear on most projects and that are easy to reuse. If you’re not able to organise an experimental Hackathon with your team, then at least independently prepare basic things and setup boilerplate project.
“No Battle Plan Survives Contact With the Enemy”
Planning is good, but preparation is even better and therefore before the start of the competition define the place for communication (recommending slack) and the place for exchanging files (recommending Google Drive).
“Hope for the fastest, expect the slowest”
Usually, Internet gets very slow during the competition when a large number of people connects to the network. There will be periods during the competition when you will not have the Internet access at all. Therefore, prepare a backup plan for the Internet.
The topic of competition is usually revealed just before the start, so it’s not possible to generate ideas in advance. Sometimes, the topic of the competition gets published a few days before the competition even starts. If this happens, sit down with team and try to generate all possible ideas and solutions that you can think of. With pre-ready ideas and possible solutions for implementation, you will gain some advantage before you even start.
3. Brainstorming
Hackathon began. The topic of Hackathon is revealed and you are already informed with the problem you have to solve. Everyone is excited and eager to start solving the task and to code. In half an hour you generate certain ideas and solutions, then hastily give each team member assignments and immediately start to work — NO! A BIG NO! This is probably the most common mistake that teams encounter when they’re on the competition for the first time. It is impossible to find a good idea and define tasks for each member in half an hour. Brainstorming and defining tasks should take 2–3 hours or more if necessary.
The next way of generating ideas has proved to be the best for our team:
Step 1 — Generate ideas
Try to come up with as many ideas and features as you can, and write them on a list. Remember that you’re working on a concept and not a production ready, fully tested product. The best ideas are the ones that are simple and innovative. While thinking about the ideas, try to think about the presentation. Consider in advance which ideas are creative and effective for presentation and give more attention to them. Try to incorporate your idea in your act. Presentation must be effective, creative and interesting.
Step 2 — Filter ideas
When you have fired all the ideas, go through each idea and feature on the list, and then argue using the following guidelines:
Basic issues that idea has to meet:
- Does the idea solve a given problem?
- Is the idea creative and innovative?
- How much time is necessary for the implementation?
- Shall we present the idea?
Additional issues that characterize the winning ideas (these two questions are usually intertwined because killer feature should be both innovative and unique):
- Is the idea a potential killer feature?*
- Is the idea sufficiently innovative and different that it will make you stand out from the crowd?
*Killer feature is feature that will get the audience and that will make you stand out. If you have two or three killer features you will probably win the Hackathon.
If some features can’t be realized within the time frame, then they should be rejected. Only those ideas and those features that meet all the basic criteria are going to the next step. The idea must solve a given problem. It must be creative, time-feasible and it must have a story to tell.
Step 3 — Prioritize features and define critical path
After you generate and filter ideas, the next step is to determine the critical path and prioritize features. The most important feature will have the highest priority, and will be marked as a number one. Less important feature will have priority number two and so on. Implementation starts with the highest priority feature and continues with features that have lower priority.
Among feature prioritization, it’s necessary to determine the critical path. Critical path is defined by the minimum set of features that must be implemented for the presentation. After the implementation of critical path features, you should be able to create a presentation with complete story that has a beginning and an end.
Step 4 — Prototyping on paper
When you’re done with feature prioritization and determining critical path, the next step is to make a quick application sketch on paper and to talk in detail about implementation of chosen features. This way, all team members will know what exactly needs to be done.
After this last step, you are ready to start with the implementation.
4. Let the coding begin
At this point, each team member should have tasks, so they can start implementation. Take a break every 2–3 hours for a short meeting. This short meeting is used as an opportunity for each team member to inform others what they have implemented so far, have they encountered any problems, and what is their next assignment.
If a team member gets stuck with a particular task, leader should decide whether to continue with implementation, or reject that feature. This is important because you do not want to waste too much time on a certain complex feature if it is not important for the presentation, and if you feel that you can compensate it with other features. Just proceed to the next feature according to the previously defined feature priority list.
Remember that you’re creating a prototype, and not a product that should be architecturally perfect and production ready. That is why you should simplify things as much as possible, and implement features to a level where they can be presented as concept.
5. Tips for a killer presentation
Although you will probably want to code to the last minute, I don’t recommend that you do so. Leave the last two hours for presentation preparation.
Victory consists of 50% presentation, 30% ideas and 20% implementation.
With that in mind, you should not ignore time for presentation preparation. Prepare the tools that will be used during presentation in advance.
If you are familiar with Murphy’s Law, then you know if something can go wrong, it will go wrong. You will not have Internet access during presentation, or some other sort of sh*t will happen, and you will not be able to present the awesome product that you’ve created. In order to prevent that, you need to be prepared!
The presentation needs to have a story — beginning and the end. In the beginning, you have to clearly explain what was the problem you were solving, and how did you solve it. Do not stretch too much with theory and introduction. The audience doesn’t care about some dull theory, and they will not remember any of it. If you have a killer feature (which you should), then think of the story and the context in which you can place that feature. Make a story that will be different than the others. Show them what you’ve done in the most creative and memorable way.
If the presentation lasts 10 minutes, spend 1–2 minutes for the introduction and clarifying solutions, and 7 minutes to show what you have done. You still have one minute left to conclude and finish.
Avoid talking about technology that you’ve used, or a technical background of everything, unless they explicitly ask you. Explain those things after the presentation if someone asks a related question. If you didn’t manage to implement a feature don’t say “We didn’t implement feature x, we could not implement the feature y”. Audience is not interested in what you haven’t implemented. They want to know what you have done, and what is the idea behind it.
tldr;
Team selection
- Try to assemble a diverse team of people with different skills and types of knowledge, where each member will play a key role
- Choose a team leader
Planning and preparation
- Organize experimental Hackathon that will last approximately 12 hours
- Prepare templates and reusable components
- Setup boilerplate project
- Prepare backup for the Internet
- If topic is known in advance, think about possible solutions
Brainstorming
- Generate as much ideas as possible
- Filter the best ideas that you can implement within given time frame
- Make feature prioritization, and define minimum set of features that you need to implement for presentation
- Make a sketch of application
- Give tasks to the each member
Let the coding begin
- Do short meetings every 2–3 hours
- Remember that you’re creating a prototype — simplify things
Tips for killer presentation
- Leave the last two hours of competition for presentation preparation
- Create a story with the beginning and the end
- At the beginning of presentation clearly explain what was the problem you were solving and how have you solved it
- Do not talk too much about dull theory, show what you’ve done and show it in the most creative way
- Do not present boring things that will not keep audience interested, such as registration or login process etc.. That’s boring — you can do much better than that
In the last few hours of Hackathon, we hate life, and are slowly losing will for everything. Despite that, we’re still giving our best to push through to the end. The feeling that you made something is priceless, and the feeling that you won the Hackathon is even better. The only mistake you can make when it comes to the Hackathon is to not participate in any.
Danijel is a web developer at COBE. JavaScript warrior with _React_ as shiny dagger and _Node_ as blazing shotgun ready to fire. In his spare time, like every other geeky kid, he likes to create pens on Codepen and develop tiny Node apps while listening RHCP in the background thread. Apart from his JavaScript warrior dreams, he likes to lift weights, eat a lot of chicken and watch crime/thriller movies till the late hours.
I hope you like my pieces of advice. Do you have some tips that you would also like to share? If you’ve already participated in Hackathon, what have you created? Leave me a comment :) And while you are here, read some other stuff from my team:
