Min-Maxing to Win Hackathons

In a previous life, I used to frequently attend hackathons. This was in the pre-COVID era, where it was still possible to hold such events. Hong Kong isn’t exactly a global destination for such things, and indeed compared to London (where I was previously) there were quite few. Still, I had the pleasure to attend several such as HackTrain, HackHorizon, AngelHack and a few others. I even managed to win a couple.

For those not familiar with what a hackathon is, it is roughly described as a team based competition to create a product/solution to some problem in a limited amount of time. Usually these events are sponsored by some company, with the set tasks being related to problems that the company faces. The idea I guess is that if you lock a bunch of developers and designers in a room for 48 hours with RedBull on tap, they will somehow come up with some sort of novel solution to your problem. I am unsure of how often this actually works out, though I have heard anecdotally that it does occur. Also, Diet Coke was my preferred beverage.

This type of hackathon I call a “Corporate” hackathon, and in Hong Kong this was by far the most common type. There were on occasion others, such as ones run by non-profits or programming groups. By definition these would be much more low-key, and not offer any prizes. Definitely worthy of attendance, but not what I will be discussing in this article.

Talking of prizes, these can be actually quite good. I’ve seen everything from free flights, laptops, and cold hard cash. However, when one reflects on the amount of time spent on the hackathon itself (typically 48h+), the hourly rate is perhaps not so attractive. Seemingly this doesn’t stop bands of programmers who make an actual living off of winning hackathons, though possibly this is only feasible in the US where the prize money can be quite large.

With all this in mind, there is (in my opinion) a way to optimise for winning, and below I wanted to outline some of my thoughts and observations on the matter. It’s not a full proof plan, and there are certainly others who I’m sure have even better ideas, but this will give you a reasonable starting point. Also, don’t take it too seriously.

Do Your Research & Come Prepared

Before you go, it is worth reading up on the hackathon online. I’m assuming you know their website since you applied, but take a look around for the first key bit of information: Who is sponsoring the hackathon. This is very important since usually the theme and tasks will be related to that company or industry. Read up about what they do, what kind of issues they face. This also allows you to scope out who the judges might be, which will be important later.

On the practical side, bring all the stuff you might need. The following are all useful:

• A laptop with good battery life, and preloaded with all of your tools. Internet connectivity can be sometimes spotty at these events due to the large number of people. Don’t start downloading Linux ISO’s to try and dual boot your laptop at the event, trust me on this.
• A notebook and a pen. Usually they give you this stuff but don’t rely on it. Drawing stuff out is in my opinion the best way to plan.
• A change of clothes. This only applies if this is a hackathon where you stay overnight. You don’t want to get up on the stage looking like you slept under a table (you probably did).

Figure Out the Win Condition

In any game, it is always important to know what is required to win. In most hackathons this is done by a panel of judges, who will score you in some semi formalised way using a points system. Knowing how this works is crucial, since this will allow you to tailor your strategy. Look at what the points are allocated to. Commonly you will notice that the “technical” side of things has only, say, 30% of the points, while the other 70% is allocated to presentation, design, business fit etc. Have this in mind when you start pitching your distributed microservice idea that you will almost certainly not be able to finish in time.

Talking of technical, “code reviews” are another important thing to keep in mind. Very often in order to prevent cheating, organisers will state that all projects will be reviewed by a developer to make sure they actually work, and are not drawing paper glued to a laptop, or otherwise stolen off of GitHub. My experience with this has been mixed, with the most common setup being a random guy who shows up at the end, looks at your repo for about 30s and gives it the OK. Unless the bar is specifically quite high, don’t feel like your code has to be production quality (unless that is a stated requirement).

Assemble Your Crew

Depending on the setup, this step will be either done before (pre-made team), or done at the event itself. The latter is usually the most amusing because more often than not it ends up mimicking that scenario from school where kids pick each other for a football team. In such cases, it pays to either radiate competence or otherwise be generally popular.

Arguably this step is one of the most important, since a good team will make or break any project. The team size itself can vary, but generally a team size of 4 is the most common that I have seen, and that’s what I’ll go with. As you will see, I’m also quite opinionated on the ideal team composition.

The Presenter / Business Person

Having a top-notch presenter is crucial to doing well. A stunning presentation can take an average project and make it great, but it requires a competent presenter. Hackathons usually have some sort of demo and presentation at the end, and this is typically the ONLY way you will be able to present your project. This role also often doubles up as a general “business” person, and this is useful because there are usually industry experts on the judging panel. Having a solid business case behind your product will usually speak louder to them than any clean code or efficient architecture.

By the way, this person has to actually be able to present. This can be difficult to determine sometimes, so you need to make a judgement call (or do tryouts?). I cannot stress enough that whoever is up on the stage has to get the whole idea of your product across, as well as do a demo in 3 - 5 minutes. They have to be able to speak clearly and not stumble or forget. It sounds harsh, but it’s a very much a get-it-right-the-first-time type role.

The UI/UX Designer

If you want your project to win, it simply needs to look and feel good. To that end, a good UI/UX designer is key in order to put a generous lacquer of paint on what will likely be a quite shaky house. I vaguely remember a blog post (I can’t recall the author, though I think it was Joel Spolsky) that recounted a story of a development team showing a (non-functional) UI to the customer, and the customer believing that the product was “90% complete”.

This misconception arises because I suspect there is a natural bias for people to view a polished UI as being “more complete” than a half-assed UI with an almost complete backend. As such, you must make sure whatever product you make looks the part and consequently presents well. Remember, the judges can’t see your code, but they can see the front end and the workflows you come up with.

The Frontend Developer

In line with the above, you will need a good front end developer in order to actually make the UI work. The reason I rank this role higher than backend is purely because (as mentioned earlier), what is visible to the judges is most important.

The Backend Developer

Last but not least, you will need a backend developer to put together whatever business logic is required for the demo. While in a real life application the backend/business logic is the core of the system, in a hackathon it is highly likely that it will be quite limited. This of course depends on the project, but usually a couple of APIs will be enough to get something working, and sometimes even this can be mocked or stripped down.

Knowledge of hardware such as Raspberry Pi or Arduino can sometimes be a nice wildcard to have, if the project is conducive to it. If hardware is your bag, then consider bringing your boards and electronics with you just in case.

Other Roles

If the team is larger than four, then fill where it makes sense to. I think that really any more than 4-5 people on a team is too many, and will actually cause you to build slower. Opt for lean and mean if you can.

If the hackathon is related to data, this can also be a data scientist or something similar. Data science hackathons are from what I can now see quite in vogue. They are also a good way of getting some practical experience since you will not only need to come up with some sort of model, but be able to productionise it as well. If this is the case, then this role can be a higher priority.

Choose A Project That Presents Well

More often than not, you will be given either a choice of themes or a choice of problems to solve. For instance, if it is a hackathon about the retail industry, there might be themes of “customer acquisition”, “theft prevention” or “product selection”. Your goal is to choose a theme/project which will be most presentable. What do I mean by this? Again, it depends on the judges, but think about how you will talk about your project. Let’s say from the above you had two themes to choose from:

1. Theft Prevention
2. Product Selection

Which one is better? It depends. If several of your judges are e.g. data scientists, then perhaps the “Product Selection” theme will be best. You can for instance write a product popularity ranking tool, or some other data related product. If they give you their actual data, that’s even better!

If your judges are more assorted, then “Theft Prevention” can be a good choice because it allows you to do something “sexy” such as a theft detection product, or a shoplifting classifier. Things like this demo well because they lend themselves to doing a real world demo, which is always popular (more on this later).

In all cases, the most important question to answer is the following: How will I do a demo of this project, and will it be interesting?.

Design Your Project Around Your Presentation

Once you are done with team selection, and you have a project idea in mind, it’s time to get down to work.

But wait, you thought I was going to say to start coding, didn’t you? No. In fact, you should spend (depending on total time) around one to two hours figuring out what your presentation and demo will look like. Before you write any code or do any designs, write out a list of steps in your presentation, and what you will talk about. Plan out your demo in detail. What will you do and which parts of the application will you show. Think in terms of workflows, and choose one or two key ones to present. Resist the urge to do too much; you won’t have enough time.

Once compiled, this list will act as your specifications for what needs to be built. On the code side, it will show you which (and only which) features are required to carry out the demo to plan. For the presentation side, the guy writing the presentation will know exactly what points they need to hit, and how they will tie into the presentation. Spending this time at the start can save a mountain of problems later when you’ve written a project which has around 10 unfinished features, but don’t know how you will even present one.

My friend Jess Pang (with whom I attended several hackathons) wrote how she and her team mapped the user’s journey to shape the solution that they ended up building. As before, anything that is relatable to judges and the audience is going to do much better than a cold list of features. If possible, try and make your project personable and use e.g. personas or real life experiences to make the audience empathise with you.

Build Only What You Will Use

A common issue many teams face is building a whole bunch of stuff that they don’t actually need. A perfect example of this is login forms. Most apps that I see presented during hackathons will start with some sort of login screen, where a presenter will need to type in a username and password to log in. Amusingly, I saw a case where this was functionally implemented and the presenter (presumably out of stress) mistyped the password several times leading to delays trying to log in. Don’t do this. The login form is not a unique feature of your project, and no-one is impressed by it.

Anything that is not part of the workflow being shown should not be implemented. If you need a page to e.g. look less bare, then consider getting the UI/Frontend guy to add some extra controls that are not usable, but look pretty. You have limited time, so don’t do anything that will not be presentable. I’ve been bitten by this personally where I spent several hours writing a WebSocket chat function for an airline booking related application. It was cool, but we ended up not even showing it as it was not part of any workflow, and it was hard to demo.

Think Carefully Before Faking It

To a degree, all product demos are build on a variable layer of deception. Famously, many game reveals at events such as E3 were from pre-alpha builds which had a ton of bugs or were even completely pre-rendered. In the case of a hackathon, everyone knows that you can’t build a fully functional product in 48 hours, so some degree of “massaging” is expected. However, be aware that you want to actually have a product that roughly works, just at a smaller scale.

For instance, at one particular hackathon I wrote a person detection algorithm by simply using OpenCV to count the pixel difference between the current frame and a background image. It wasn’t a full solution, but it did roughly work as a person detector. It’s possible to turn the fakery to 11 and just use e.g. PowerPoint to show your app “working”. I highly advise against this$^*$, as more often than not any app made this way will not stand out, and while it might look nice and present smoothly, it will rarely feel real.

$^*$Having said that, early on in my career one of my friends managed to win an internal hackathon using nothing but Excel. I respect the hustle, but I remain salty about it to this day.

Do Not Present A Terminal

Any project whose primary presentable application is a terminal is destined for failure. Remember that judges will largely be made up of end users who are likely not familiar with terminals or how they operate. If your application just displays a bunch of text in a terminal, the entire point will be lost, even if what is going on is actually quite impressive. It must be visual, and it MUST have a UI of some sort. The only time this advice does not apply, is if the hackathon itself is incredibly technical (this is rare).

In fact, consider not presenting a phone app either. This is perhaps controversial, but I once attended an event where the judges had to sit through (I estimate) 20+ shopping apps which all looked pretty much the same (and had login screens). By the time such judges get through all of them they will really not care, and anything even slightly different will pique their interest. I have personally always favoured what I call a physical demo.

A physical demo is so called, because it involves something happening in the physical world. Despite computers being prevalent in our culture, I find there is still something magical about a users action affecting something in the physical world, even if it is quite minor. For one hackathon I put together a “passenger load balancer” using two Raspberry PIs with webcams and a python web server hooked up to an HTML page via WebSocket that simply pointed left or right depending on which camera saw less people.

The project itself was very simple, but it was extremely presentable because it allowed audience participation by having users move back and forth between the two cameras (acting as passengers queuing up). As the audience members queued up on one side, the arrow would switch telling people to queue on the other side. The system was trivial, but the audience and judges appreciated the interactivity, and they paid attention. The worst thing you can do, is be boring.

Practice Your Presentation Until You Get It Right

For your presentation you will typically have about 3 - 5 minutes, as well as maybe 1 minute of time for questions. That might sound like a long time, but in the moment it flies by real fast. A common failure mode of many teams is actually overrunning their allotted time and being cut short by the moderator. DO NOT be a victim of this (it looks really bad), and practice your presentation until you get it exactly to the time limit. Don’t leave this till the last minute, and favour spending more time practicing presenting over adding more features. Make it a group effort, with non-presenting team members tracking time and making suggestions.

As for the questions, this is free time that you can use to your advantage. Think of what the questions might be, and practice those too. As before, look at the judges and try and guess what they might ask. If there is a technical guy, make sure you have any potential technical or cost questions covered. For more business oriented judges, prep how your “business model” might work, or how you might decide on pricing etc. Keep in mind that the questions don’t just have to be answered by your presenter, feel free to defer to other team members (who also need to practice answering) which can give your presentation a more professional vibe.

Make Sure Your Demo Works

Having a demo fail on you is the absolute worst, but it is a startlingly common occurrence. Typically, this is due to two factors:

1. The demo itself is highly flaky, or dependent on getting something “just right” (e.g. reading a QR code with a phone).
2. The team didn’t test the demo properly, or didn’t practice the presentation and demo enough (see above).

Make sure as part of your practice you practice the demo walkthrough every time. If there are any signs of flakiness, stamp them out. It should be 100% consistent. In addition, make sure you test your demo in battlefield conditions (on stage). Most well run events will allow you to test the AV equipment and the stage. Make use of this, and make sure your laptop works with the HDMI cable or whatever other rube-goldberg contraption they’ve got set up.

Speaking of laptops, close all the other applications. No-one wants to see your (sketchy) browser history, company emails (!), or your torrents that you are inexplicably seeding over the organisers anemic network. I have seen all of these occur live on stage.

In Conclusion

This probably sounds really cynical, but if you follow the above, you will have a decent chance of winning. Note also that winning isn’t everything, and you can learn a lot and network at a hackathon as well. I do think however that “coding to win” does teach you some valuable skills. While I haven’t done it myself, I suspect that pitching to VC’s probably shares some similarities with pitching judges at a hackathon.

I actually think that companies in general could benefit from hosting hackathons - even internally. As an engineer in a larger company you may not always get the “startup experience” of having to get SOMETHING to market in a short amount of time. Having to face quick fire choices of what features to drop, what things to paper over, and how to sell something can be highly instructive. Even if it’s not fully realistic, it’s usually a fun experience and simulates the process of making a working prototype quite well.

Good luck, and don’t take it too seriously.