How to win and how not to win a Hackathon
Programmer’s pragmatic perspective
HOW you present matters much more than WHAT you present.
Our first hackathon had a very technological app, real time, interactive, great looking UI. We asked audience to open it on their phones and interact. That was too complicated. And we didn’t explain business idea well, since we spend most of the time demoing. We bet too much on “coolness”. We didn’t even get in top 3.
Our second hackathon we started from presentation. We created a story and beautiful yet simple slides to help to explain it well. We run through our talk and demo 6 times. We didn’t have interaction, we emulated real-time experience, we mocked the data. We got 1st place.
They may forget what you said––but they will never forget how you made them feel.
It’s much more fun to code than to create slides and think how to explain stuff to people, therefore you can expect most teams to have poor presentations and lots of code.
Win or Fun
How to explain stuff and how to build it— are two very different problems to solve. First one is not fun at all and you, as a programmer, probably, suck at it. So you and your team should know what to expect and decide what is the goal of hackathon from the beginning. You can have only one of these: to have fun or to win it.
You should decide as a team if you want to win or to have fun.
Looking back, I enjoyed our first hackathon more. But I can learn how to build stuff on my own, I don’t need hackathons for that. While it’s impossible to learn how to explain stuff to others sitting at home. Hackathon is a great opportunity to develop your communication skills.
The fact that most of us suck at presenting gives another reason to start from presentation, since it’s the hardest part. When you are super-tired, demo time is coming and you have that uncomfortable feeling that it’s all buggy and barely works… Would you rather do final bug fixes (as a final aid to your anxiety) or rush through presentation trying to “creatively” mask your poor skills in 30 minutes? Don’t underestimate lack of sleep and don’t overestimate your verbal skills.
Focus on visuals. Minimize words, maximize pictures. Use jokes. Don’t overuse jokes, 2–3 is enough, start from it. Give you project a good name.
If you want to have fun as a programmer — forget about prizes. You are not going to win anything and that is okay. Focus on speed of delivery, start from high level things. If you are building a web app––the sooner you get to a working proto the better, let it be ugly, but make it work as soon as possible, pages should be linked to each other, buttons should do something.
If you are planning to use any kind of web API––mock the data, run super-simple instance of Express server (or whatever you comfortable with) that just returns data for your success path. That is enough for 99.9% of the cases.
When you just need to show sophisticated page, but you won’t interact with it much––use screenshots, just put an image as a background, it works, it’s impossible to tell the difference and it’s super fast. This is hackathon way. Focus on what matters.
Build your toolbelt before a hackathon. Pick a framework, run web-server. Find all bootstrapping things you need.
It takes 6–12h to create somewhat good 5–10 minute long talk . This is assuming you are very sharp with tools to create slides, tools to draw visuals (I drew them on paper and used Scannable), tools to massage the data and tools to put this all together. So for 24h hackathon it’s hard (it’s manageable for 48h one). You would need a separate team-member that spends half of it just doing presentation, while the rest is coding.
It takes 5–8 rounds to try and run your presentation end-to-end, before you will get comfortable and get enough feedback to do it right. Demo, get feedback, iterate, repeat. When you are done, do the demo to a person that haven’t seen it before, you would immediately know if it’s good enough. Remember:
If you want to be good at something — do a lot of it.
If you have 5–10 minutes to present, you don’t need meeting notes, you will memorize the whole thing after those 5–8 repetitions, this is another reason to invest into practice.
It’s super important to stay focused, so you don’t waste time on minor things. Hackathons are all about efficiency and cutting corners. You will need to things for that a plan and a timer. Vanilla todo-list on paper would do it, but it won’t work just for you, create one plan for the entire team, so you all will be on the same page and you all can help each other to follow it and don’t get distracted.
Single-person todo list won’t work, create a plan for entire team.
Set a timer to 30–45min and work hard with zero distractions during this time. Take a break after, 5–10min and do another interval, synchronize intervals with your teamies. Taking breaks is crucial to stay productive and to look back if you are on track and whether you need to keep doing what you are doing.
You can either have fun or try to win, not both.
Good presentation takes 4–12h of preparation including practice.
To win — start from presentation and do it right.
To have fun — focus on coding from top to bottom. Mock everything.
Create a shared plan for entire team, use paper for that.