Winning hackathons

How to finish strong in any hackathon.

I have judged a few hackathons and here is my advice to anyone participating in one.

Things to do

Pick the idea and scope carefully

Spend a few hours picking the project for your hackathon. This is the most important decision you will make. It dictates the technology, the features, and everything else. A ten minute discussion and prototyping on paper can save 5-10 hours of coding and refactoring later.

Make sure the project covers the target technology

If the hackathon is focused on a specific technology, make sure that technology is well represented by your project. For example, a Node project should not be a static website, rather something that uses Node in a way different from any other platform (like Java or Go).

Keep the team small

I honestly do not see much difference in features between projects with a single or just two people and projects made by a larger team (3 - 5). Making the team larger increases the communication overhead and slows you down. Judges even without realizing this expect to see larger projects with more features and polish.

Implement and automate the entire pipeline right away

Even for small and simple projects, you should setup a continuous integration and deployment pipeline from the very beginning. Use Heroku or something else to host and make sure the deployment happens on the code push automatically if the unit tests pass. This will eliminate problems trying to deploy / run the project during the last hour.

Install exception reporting service

Nothing compares to the real-world users banging your application, finding all the edge cases. Install a crash reporting library and go through the demo steps. The installation is very very simple, here is one for Express.js under Node.

Use friends

If you can deploy the initial seed functionality, it has an extra benefit. You can ask your friends to use your application as soon as possible. This will both provide feedback on the features and test the code (if you have installed the exception reporter).

Learn and use a start kit

Do not start from scratch. Use a starter kit, like MEAN starter or SQL-EAN starter, or my own version PouchDB-E-N starter. Even make your own fork with technologies that you know and trust to work during the crunch time. This means practicing with the starter kit beforehand.

Things to avoid

Using multiple unfamiliar tools

Every platform, language, stack add risk to your project. It is hard enough to solve problems in a single library, now imagine that during the final hours you must solve problems with a database driver written in C while your project uses Go.

If you pick a database to store your technology, pick something simple and trusted, preferably with a native driver. For example, in JavaScript I like using PouchDB - because it is JavaScript too and can sync to plain JSON files.

Learning new technology

It is fine to learn something for the hackathon, like a company's hackathon, but do not try to use completely new tech stack. For example, if you are comfortabe with Angular or React, do not try to hack in Meteor - this will ensure that you spend time going over "Hello World!" examples, rather than implementing actual features. Again, try to stick 90% to the technology you already know.

Making long demo videos or writing long intros

When judges view your video or read the project's description and instructions, they have very limited time - your entry is probably one from 10-20 each judge has to review and grade. Thus anything longer than 60-90 seconds is too long.

Requiring the judge to login with private information

I see this error all the time: a project requires me to login with my twitter or github account; but asks for very wide permissions. If you demo application wants to post tweets on my behalf or change my profile details - I am NOT going to run it. Plain and simple. If you need my twitter details - ask for read-only access. If you want to show how your application can tweet, if this is an integral part of the application - make a demo account one can use to check it out.

Taking the judgment personally

Sometimes I judge an application harshly. Maybe I think it is out of scope, or not very novel, or even annoying. The worst thing one can do as the application's author is to send me an angry email. Maybe I did not see your genius, but I am sure other judges did. Remember, even the smartest people can make mistakes or have honest disagreements about the value of any particular idea or thing.

Best of luck and keep hacking!