Burn Rate

Hacking the Hackathon

Hackathons. Love ‘em, hate ‘em, they’re everywhere. It seems like every college has one. Whether you’re a computer science student or simply adjacent to programming, you always have the opportunity to attend some sort of hackathon.

Here’s some guidelines for how hackathons work, whether you should attend or not, and tips for making the best of your experience.

What is a Hackathon?

A hackathon, fundamentally, is an event where people come together and make cool stuff. Generally people will work together on teams to create a new project that they will then submit for judging and prizes. There’s usually free food, swag and companies who sponsor the event. Hackathons range in length from 12 hours to 48 hours. Some attendees will stay at the venue and (maybe) sleep.

Making stuff doesn’t necessarily mean programming by the way. You can go around surveying people and getting a feel for product fit1. You can design mockups for websites or apps. You can polish pitches. You can solder stuff or debug hardware.

You can also go to a hackathon and do none of that! Hackathons are great in that they aren’t super restrictive. You can just go there eat the food and hang out. Usually there’s some other activities planned which are fun. You can also work on your existing projects, although you won’t be able to submit them.

College hackathons are going to be the main ones that you’ll attend. Some of the more well known college hackathons out there are PennApps, HackMIT and MHacks. NYU also has a hackathon called HackNYU. For more events, check out Major League Hacking for a full list.

There are certainly other hackathons too, such as corporate ones, or online hackathons. You’re less likely to encounter those, but hey, if it looks good, why not?

Should I Go?

If you have the time and you’ve never been to a hackathon before, then sure! A hackathon is definitely a good thing to experience if you’re interested in tech. If you don’t like it, then that’s fine. If you do, then great! You’ve found something fun and interesting.

Personally, I do occasionally attend hackathons, but I don’t go to them super consistently. I find that I enjoy working on projects at a slower, more long term pace. But I did go to hackathons a lot more in the past. I met some good friends, worked on some cool projects and won a few prizes. Overall I’ve benefited from having attended hackathons.

I’d especially consider going if you don’t have a lot of practical experience programming. There’s something really freeing about just coding like mad with no guidelines or rules.


I’m going to get this out of the way. Hackathons don’t have the best reputation with respect to sleep. And to be honest, yeah, it’s kinda warranted. I don’t get a lot of sleep at hackathons. But that doesn’t mean you shouldn’t sleep! Sleep is super super important. It is a massive element of your physical and mental health. It also is kinda essential for making your brain work. I’ve had times where I hit a wall where my brain just couldn’t code due to lack of sleep.

Part of the reason I don’t get a lot of sleep is because I’m competitive and want to win the damn hackathon. But I’ve started to realize that not sleeping isn’t that great of a strategy. No matter how much time you have at a hackathon, the last few hours are always going to be a crunch. Therefore, if you sleep, you’ll be ready to work work work for those last few hours. While if you don’t sleep, you’ll just be a bleary mess and unable to finish strong.

Sleep is important. Get some.

What Should I Bring?

I’m gonna assume the event is longer than a day. If it isn’t, just bring normal day job stuff, a laptop, maybe a water bottle, etc.

You definitely need a computer of sorts. Some…hardcore people bring desktops, but a laptop is probably a better bet.

Decent headphones to block out noise. Essential for programming in what’s basically the largest, most uncomfortable open office.

A change of clothes. Especially socks. For some reason there’s nothing worse than wearing the same pair of socks for too long.

Warm jackets. I don’t know why, but hackathons always get super cold. Maybe they pump the AC. Maybe it just gets really cold at 4am. I don’t know. I like having a light down layer in warmer months/climates and a heavy layer, even a parka in cold weather.

Shower supplies. This means a towel, soap, flip-flops and extra underwear. Lots of hackathons will provide showers, so take advantage.

Sleeping bag. Definitely worth bringing. Sleeping on the floor is not only terrible, it can legitimately be bad for you. Certain materials can suck body heat from you and cause mild hypothermia. Trust me, I’ve been there and it’s terrible.

A good sleeping mask and earplugs. A nice sleeping mask with padding makes all the difference. Make sure the earplugs fit and give a nice seal too.

I started bringing vitamins, specifically Emergen-C, because between the typical unhealthy food hackathons serve (any hackathon organizers reading this, please consider serving healthy options like fruit) and the sleep deprivation, I tend to feel not great by the end of a hackathon. Vitamins help with that. Maybe pack some fruit too.

Other Frequently Asked Questions

Do I need a team?

Nope! I’ve gone to plenty of hackathons by myself. Just be open to talking to random people and you’ll have a good time. I’ve done a few hackathons where I met the team at the event and proceeded to do quite well. In general you shouldn’t restrict events/activities because you don’t know anybody there. Go and meet new people!

Help! I don’t know how to program/I only know Python/Java/Racket

That’s fine! Hackathons should be about learning. You can spend the event learning just what you need to get started. Don’t compare yourself to other people with different experience levels and expectations. As mentioned before, you don’t need to know how to code to be a helpful team member. Gather product data, design marketing material or even provide manual data (many a successful project has been built upon manual data entry).

This project isn’t a good hackathon project but I still want to build it…

Go for it! I mean, don’t expect to win or anything, but you might as well work on a project that you actually want to make. You’d be surprised what judges like too. I’ve won with projects that I never expected judges to like. Besides, if you want to continue, you can work on the project after the hackathon. Which is far better than any half built project that’s immediately tossed once the event’s over.

How Do I Win?

Ah yes. The question you really want me to answer. You’ve seen the awesome prizes, the Facebook likes and potential internships that hackathon winners can achieve. You want that Oculus, that iPad, that whatever on the DevPost listing.

Disclaimer: Please Don’t

Before we get into the frankly cynical winning tactics, I want to caution that winning is a pretty lame reason to go to a hackathon. Just doing the math, you’re working about 24-48 hours straight, which at a rate of 20 dollars an hour (a pretty low programming wage), gives you a total of 480-960 dollars. Therefore unless the prize is above that amount, you’re not really making any money. Plus there’s no guarantee you’ll win a prize.

Putting money aside, the amount of stress and lack of sleep that you endure by working like mad to win isn’t worth the possibility of winning a prize. Obsessing too much about winning poisons the whole experience and makes hackathons a lot less fun. Plus it leads to forthcoming cynical, deceptive tactics which, unfortunately, are pretty effective but also ruin how you see hackathons.

Winning a prize now and then is great. Obsessing about winning isn’t.

Okay Fine

With that said, let’s get down to some nice cynical strategy.

Hackathons fundamentally are about convincing the judges that your project is cool and interesting. As a general rule, judges tend to not be super technical or well versed in hackathons. Therefore, they’ll mostly judge your project on A. aesthetics, B. perceived social impact and C. wow factor.

Therefore—and this is a rather contentious conclusion—you should basically try to write as little backend code as possible. Storing data? Do it in localStorage. Accounts? Fake it. Computations? Don’t bother. Yes, yes, I know, front-end is icky. But it’s also visual and that’s far more important than anything in the backend.

For front end development, I’d generally recommend learning plenty of JavaScript and some basic HTML and CSS. People for some reason have an obsession with React at hackathons, which I think is a little misplaced. As someone who is fairly decent at React, I like it but it’s also tricky to get right and has a somewhat steep learning curve. I’d learn to use something like Materialize or Bootstrap, then get really good at CSS. An okay CSS developer is so much more useful than an amazing Flask dev at a hackathon.

For social impact, make sure your app does something that can be sold as good for the world. Doesn’t matter if it’s actually feasible. For instance, your app can help people get news across the political spectrum. Or maybe it can help diagnose patients. Or maybe it just solves world hunger.

I don’t know why this is so important, as frankly hacks for hacks’ sake can have as much benefit on the world as ones for ostensible social good. Plus I’ve found that a lot of evil has been done in the world in the name of social good. Perhaps we should have a social evil hackathon instead? But I digress.

Wow factor is probably the most important aspect. Let’s face it. Judges aren’t gonna look at your code. They’re not gonna remember your lofty pitches on saving the rainforest. Maybe they’re remember a tiny bit of your slick UI. But they’ll remember above all the crazy VR/AI/ML/NLP/etc. project that’s gonna revolutionize the world.

This is definitely true with less technical judges. It’s pretty easy to get non technical people impressed by just saying “machine learning” or “neural network algorithm”.

That being said, some buzzwords are better than others. I’ve never gotten a good VR/AR hack to work, though maybe if you have an HoloLens or Oculus laying around, it could work. Machine learning is a great bet. Especially because there’s some great off the shelf ML APIs from Google, IBM, etc. that work decently well.

Blockchain is a little dicey. I’d say maybe 2-3 years ago it’d be a good idea, but now I think people are cooling off on it. Try to keep it to relevant, hot buzzwords.

Hit the right balance of aesthetics, social good and wow factor, and you’ll be well on your way to impressing judges.

Misc Winning Advice

Stick to familiar technologies. I hate giving this advice because I love to explore new technologies and despise when people stick to the same tired languages. But if you want to win, try to spend as little time as possible reading documentation or teaching yourself.

Likewise, stick to the happy path of development. If you’re trying to add a new feature to a project, but you’re just stuck and nothing is working, ditch it and add something else. For instance, I was at a hackathon recently where I was trying to implement an autocomplete component in React2. I was struggling like hell because apparently React autocomplete libraries all suck. Now I could have slogged through, gotten it working, etc., but I would have lost a significant amount of time, momentum and most importantly, morale. Not worth it.

Hard coding is your friend. Unless it’s super super easy to implement, just hard code it. But hard code intelligently. I like to add a little bit of randomness to my hard coding so that it’s more convincing. For instance, if you’re writing an app that displays the temperature in Kansas City, sure you could pull data from a weather API, or you could hard code it, then randomize it by +-5 degrees.

Don’t feel like you need more people by the way. A classic quote by Fred Brooks goes: “Adding manpower to a late software project makes it later.” I’ve won prizes working just by myself and I’ve lost them with 4 person teams. It’s hard to get 4 people assembled who are all on the same page, good programmers/workers and who can work together effectively.

What You Should Not Do

Please don’t cheat. I know, I just went over a whole list of kinda dubious things like hard coding features or manipulating buzzwords to appeal to judges. But there’s a difference between playing the game cynically and cheating. Please don’t start projects weeks in advance then claim you did it all at the hackathon. Please don’t reuse projects. Please don’t copy projects.

It’s not cool and more than a little lame to be cheating a college hackathon.

A Quick Message To Hackathon Organizers

Hey organizers. I wanna give a quick message. First of all, thanks for everything you do. It’s a lot of work to run a hackathon, with the around the clock logistics issues, technical issues of maintaining a site and the constant hustle for sponsors.

But for recommendations, please factor health into your planning. For instance, please offer better dietary options like fruit and vegetables. I went to the Y Combinator hackathon recently, where they served plenty of vegetables with apples and oranges as snacks and LaCroix as drinks. And lemme tell you, eating apples instead of pizza makes all the difference when you’re up all night coding. I came into the hackathon already sick, but I left feeling not terrible cause of the great food. If I had Insomnia Cookies followed by Panera Bread followed by pizza, I would have felt horrendous by the end.

Another aspect is sleep. I really think hackathons need to emphasize sleep more. It’s just not healthy to stay up all night. And sure, hackathons are a once in a while deal. But it’s selling a lifestyle, which has far broader implications. Have plenty of places to sleep for people. And maybe reduce nighttime activities/actively turn off the lights.

Finally, please vet your judges. Find people who are somewhat skeptical and have a little technical knowledge. Maybe give them a briefing on how to judge a hackathon project. It’s important that they have some barometer for the bullshit.


Hackathons can be great experiences and I definitely recommend that you attend at least one in your CS career. But they’re not exactly essential. If you don’t like them, then there’s a whole bunch of other ways you can spend your time.

  1. I had a member of a team do exactly that at a recent hackathon and their work was extremely valuable. Turns out asking “do people want this?” before presenting is a good idea! 

  2. Just because I use it doesn’t mean you should. 

This project is maintained by torchNYU