Ask HN: I'm non-technical, going to my first hackathon. I'm going to a 36-hour hackathon (hacka2thon.com) this weekend with my friend who is a designer. I'm non-technical, registered as a business/marketing type. What should I do to prepare? Thanks. |
Ask HN: I'm non-technical, going to my first hackathon. I'm going to a 36-hour hackathon (hacka2thon.com) this weekend with my friend who is a designer. I'm non-technical, registered as a business/marketing type. What should I do to prepare? Thanks. |
Talk to a lot of people (everybody) when you're there. Hackathons are a great way to meet intriguing people and discover new ideas.
I don't like losing, especially where I have damned good control of the outcome! Here are some tips for actually winning!
Make a workable demo
One huge mistake that most every team makes is that they aim too big, then realize there simply is not enough time to realize that vision, so they start cutting features at the last minute just to have a workable demo. Instead, prototype an MVP, test it, then add features if you have time.
Test your demo
The judges and people in the audience are going to want to try your demo out. Give them a working URL that shows off the functionality you promise.
List your challenges
I always hate talking myself up and making it seem as though some problem really wasn't too difficult. At a hackathon the other day, one of the judges asked what the hardest part about building our app was. I answered, "building it in 10 hours." Wrong answer. Instead, I should have already thought about what the hardest part was and included it in my slides.
Don't go first
Going first in most any presentation sucks. Judges have no idea what to expect of any other hacks, so they give wildly varying point spreads. Try to go second or third. In these positions, you can look better than the previous presenters, and also still make the more mundane details of your hack look new (for example, with data api hacks most teams will use the most data heavy table. If you go first, you look the best).
Avoid sitting near judges
You probably have an opinion on each of the hacks being presented, and it is in your best interest to keep those opinions away from the judges. If you're impressed by a hack and a judge hears you express such, they probably think you yourself don't think your project is as good. Conversely, if you denigrate the presented hack it makes you look jealous and spiteful. Either way, you lose.
Have a full presentation
Spend a little time working on your presentation. I'm not advocating a fully polished presentation with a video demo, bios of each team member, etc., but make sure you have a few slides and you know the order of them. I try to stop hacking about 30 minutes before presentations so that I can think about the best way to showcase what I spent my time on. The slides I usually have are:
* Title, My Name
* Problem
* Solution
* (Demo, actually do the demo)
* Language and APIs
* Challenges Overcome
Avoid talking about Version 2
You know how many people continue working on a hackathon project after the hackathon is over? Nobody. Ok, maybe a few hacks are continued (GroupMe, Kindlegraph), but the vast majority get dropped before the first round of after-hackathon beers is downed. When you show a slide with your Version 2 roadmap on it you look disingenuous. Instead, highlight the awesome stuff you managed to crank out during the hackathon and go in-depth on how each of your features works and why it is beneficial.
Tell a story
You're told this all the time when asking how to pitch bloggers and connectors. Same concept applies in your presentation. Tell where your awesome idea came from (who thought of it, how did it evolve?). Describe the situation where a make-believe person would use your hack.