The main aim of a hackathon is to build a basic app in a limited period of time, but your success can have as much to do with your final presentation as with the quality of your code. Here are ten tips to maximise the impact of that slideshow and demonstration.
I formulated these thoughts while watching the presentations at the Ford SYNC AppLink Hackathon event in Melbourne yesterday (you can check out our video roundup of the event here). The range of apps built in 24 hours was very impressive, and I’m not looking to single out any individual presenters — after that long with minimal sleep, merely standing up is impressive, and there can always be technical issues that are outside of your control. But if you’re looking to participate in a hackathon in the future, keeping these ideas in mind for the final showdown can definitely improve your chances.
Don’t overload your presentation with text
This is the most basic rule of any presentation, hackathon or otherwise: don’t fill your slide with text which you read to the audience. Use just a handful of keywords as stimulus for what you want to say.
Keep your branding on every slide
While your slides shouldn’t be overburdened, one detail you should maintain: make sure the name of your team/app/project is present on every slide. You have lots of competitors and you’re likely to be developing in broadly similar areas, so constant reminders of who you are make sense.
Take note of the time limit and rehearse for it
You’ll invariably be given a fixed time to present. Take note of it and make sure your remarks won’t take longer than that. When in doubt, under-write rather than over-write; when you’ve worked in-depth on a project for a long period of time, you’re rarely short of things
Get to the demo as fast as possible
The point of a presentation is to show what you’ve created, not explain why you created it. Set the context quickly, then demonstrate what you’ve built.
Always use the microphone
In a small room, everyone present may be able to hear you even if you don’t use the mic. But if a mic is on offer, use it: it shows respect for the organisers, and it’s essential if the event if being recorded or streamed.
Don’t spend ages trying to fix mistakes
Bugs and crashes are going to happen with an app that’s had (at best) a weekend of work. All your fellow presenters are in the same boat. Accept the error and move on; don’t waste your (generally limited) presentation time trying to fix it.
Work in a team if possible
It’s challenging enough building an app solo at a hackathon, but the challenge really becomes pronounced when presenting: you’ll lose time switching between your presentation and your demonstration. So try and persuade a friend or colleague to pitch in.
Sleep if you can
Hackathons are presented as a non-stop endeavour, but both the winning teams at this weekend’s event actually took sleep breaks during the event. Resting can be just as helpful as pushing through, both for your code and your presentation.
Highlight your most unique features
It’s rare for an idea at a hackathon to be completely unique, so don’t describe every aspect. Focus on what distinguishes you from other similar apps or services.
Answer questions quickly
If there’s a Q&A section, be prompt when responding to questions. If you haven’t thought about a particular issue, say as much: don’t try and fake an answer. Better to acknowledge it with “We hadn’t considered that so far, but it’s definitely something we’ll bear in mind for the future.”
Disclosure: Angus Kidman travelled to Melbourne as a guest of Ford.
Comments
5 responses to “Top 10 Ways To Improve Hackathon Presentations”
DO NOT say “Um…”
If you can do that, you’ll sound better than 75%* of the presenters, out of the gate
[*] Keeping in mind that 86% of statistics are made up on the spot
Except for ‘get enough sleep’ (or, well, including that) these tips can be taken into *any* presentation.
Though, ‘um..’, @sa_penguin makes a really good point. Best thing I ever started doing early on in client/partner interactions is to focus on a different word/noise.
Say, if doing a demo, using ‘so basically…’, may sound annoying to you, but to your audience, they don’t know you use it 24/7, but, like ‘um..’, it gives you that slight pause to remember (or to just BS) what to say next.
I played “the Um game” the other day with a bunch of uni students. You are given a random topic and must speak about it for as long as possible without pausing for more than 5 seconds or saying “umm” or “ahh”. The record? 1 minute 23 seconds. With practice though, you can easily get up to more than 5 minutes.
Thank you.I’ll follow up with a suggestion: If someone records your presentation, and you plan to release it on Youtube, edit out the “umms” and awkward pauses.
Sure the video may jump around a bit, but it will be shorter and feel faster paced.
Nah, the video isn’t jumping! Their internet can’t handle 480p.
Every 4 seconds.
*Gulp*