How to Win a Hackathon (or Increase Your Odds) Heitor Sergent September 5, 2013 Events // SUMMARIES ?> Though I am a new SendGrid developer evangelist for Latin America, before landing the job I attended a lot of hackathons. That track record was a big part of me getting the job. I have competed in more than 10 hackathons in the past years, winning prizes at several. I even took first place at Evernote’s hackathon and The Next Web Hack Battle in São Paulo. I honestly love hackathons. They are a great way for you to learn new things, improve workflow, improve communication with your team, build cool things, meet new people, and get awesome prizes. And now I want to share some of the things I learned after participating in so many of these events, and hopefully help to increase your chances of winning one of them. Preparation is Key Be organized: One thing I like to do at hackathons is quickly go through these: Dropbox folder for files and code Google Drive folder for presentation and spreadsheets Trello for task management Github for code versioning When the end time is getting near, and you’re looking for that 75×75 image for your app icon, or the logo of the app to put in a presentation, you don’t want to spend more than 10 seconds looking for it. The same goes for when your hack just broke 10 minutes before the deadline, and you start trying to remember what were the changes you made for the past hour. Just go back to the last commit and move on. Get sleep: Ok, this is my personal advice and I know some people will disagree with me, but I’ve found that for myself, getting six hours of sleep and continuing through the next day is miles better than pumping Red Bull + Coffee and staying up all night. I can make decisions quicker, work faster, and present with a much better face after some rest.The only way I would recommend not sleeping is if your project is really organized, to the point where you don’t really have to think about what you’re doing. That happened to me once, after me and the team spent six hours planning the hack before we started design and coding. But I wouldn’t count on that happening again. Bring ideas: Have a few ideas ready before going to the event. Time is essential at hackathons, and while it’s cool to share and discuss new ideas, try to have some beforehand so you won’t waste half of the time available trying to decide on what to do. Be social: Speak to attendees. This is one example where asking for help actually does you two things: helps you with your project, and you meet new friends. A lot of people I’ve met at hackathons opened up a lot of opportunities for me, professionally and otherwise. It’s great to meet others who are just as crazy as you to spend 48 hours straight working on a project, during the weekend where most of your friends are out drinking. Practice presenting: So you’ve spent all those precious hours hacking away, and didn’t make a presentation, or practice what you were going to say. Please do leave one-two hours to practice what you’re going to say. And here are some general tips: Tell a story. Explain what made you build the hack. Face the audience (unless you hacked on your own, but still try to face everyone) Don’t worry about things breaking. Keep your hands out of your pocket Mention the APIs you used, but don’t focus too much on the technology There’s a lot more about this topic in Elmer’s Principles of a Killer Hackathon Demo. Hack Efficiently Prepare your environment: Seriously. A hackathon is a great place to try new APIs, tools, etc, but make sure to test things beforehand. Got a brand new IDE, install it, make a quick Hello World and run it. Playing with a new smartphone, test deploying in it. I had more than one hackathon where a friend went unprepared and spent basically half of the hackathon downloading stuff, and the other half setting everything up. Ask for help: Don’t be afraid to ask for help. There’s always a bunch of people at a hackathons that are there exactly for that. If you’ve tried something, googled it, stack overflowed it and still couldn’t find an answer, go talk to someone. That’s another reason for #4, be social. Limit learning: A hackathon is a great place to learn new things, but if you’re intent on winning, you need to spend every second making your hack the best. If you want to lower your chances of getting frustrated, I don’t recommend trying to learn something like a new language during a hackathon. I tried that once at a Windows 8 hackathon, making a game with HTML5/CSS3/JS, and it was some excruciating 8 hours of Google, StackOverflow, and lots of bad code. Focus: Don’t waste precious time during a hackathon making a Facebook/Twitter/Google+ login or share button. Those are not hard things to do, there’s a bunch of tutorials on how to do it, and you can fake it using HTML/CSS. Don’t worry about it, your hack won’t need to go live right after the event. Also, spend more time thinking how you’re going to build the main feature, than worrying about how to scale to a million users. You won’t be judged on that. Final Advice for Winning Value design: Designers are scarce at hackathons. I don’t know why but most of the audience is always developers. And what I did found participating in all these events is that design is a game-changer. Not only how beautiful your application is, but how the user experience is. There’s a bunch of online resources that can help you design better than most teams without designers: Bootstrap for websites Adobe Kuler for color palletes Hack Design for learning about design Dribbble for inspiration That said, if you have designer friends, please try to get them to go to a hackathon with you. Design can be such an important role in hackathons and we need more designers to attend. Truly Final Advice If you take all of the above consideration, I’ll guarantee you’re going to win! Seriously, and cheesily, the last advice is to have fun. At the end of the day, you’ll have a cool (and most likely buggy), shiny new hack, met some people, drank some beer/Red Bull, have some hours of sleep to catch up and perhaps a brand new prize.