Hackyness — lessons on how to approach hackathons from a personal experience

Photo by Alex Kotliarskyi on Unsplash

“A hackathon … is a design sprint-like event in which computer programmers and others involved in software development, including … designers, … managers, and others, …[to] collaborate intensively on software projects”.

One of the few positive consequences of having a Type-A personality and N-ach life-view is that I enjoy hackathons. My ideal workplace has always been a small controlled setting with clearly realizable goals with like minded goal oriented colleagues working on new and exciting technology, which is quite far from most professional work environments.

That’s why I jumped on the idea of attending the NYC Blockchain Hack sponsored by Consensys. It was pay-to-attend and only 1 day, meaning it was curated and I still got half my weekend. It was sponsored and there were judges, meaning actual companies were invested and the projects would get eyes on it. There were also workshops and tutorials; the range of talent would be varied and participants diverse. Finally, it was about Blockchain, which is the hot new buzzword that every recruiter and VC under the sun was trading. There was just one problem: I didn’t have a clue what Blockchain was.

Before the hackathon

Not knowing about Blockchain didn’t worry me, this wasn’t my first hackathon where I was clueless on the subject matter. There are always 3 steps to do before any hackathon:

First, read up on the source material. In this case, the hackathon was kind enough to send out guides, reading material and learning data. Finding additional data to play with was plentiful. Blockchain is “a powerful solution lacking problems to solve”, which is a wonderful place for a technology to be! It demands engineers to look at their own existing issues in a new light to see how unexpected new tech might help them.

This leads neatly to the next step, find a problem(s) to solve. We engineers are problem solvers, but when put on the spot, we often have no idea which issues need solving. Lacking a problem statement means a lot of time lost during the hackathon trying to figure out what to solve.

Finally, see how the hackathon is a space for the solution. The way to ascertain this can be anything from doing a detailed read of the sponsor goals or to read the hackathon agenda. With those steps in place, you’re ready and you can put your thoughts aside until…

The day of the hackathon

… the day you need to wake up at the cRacK oF GOD DanG DAWN ON A SATURDAY! Sorry, many hackathons sensibly start at 8 or 9 am; and lacking the same sense I went to a happy hour the night before. NYC public transport being what it is, I found myself running to get there on time. Plan your travel before hand.

At the hackathon the first hour or so was pleasant. The sponsors were kind enough to provide 3 meals, and even more kindly, plenty of coffee. During the day the food area is a hub of folks chatting and it’s a great place for recruiters to find ambitious and capable talent. Do remember to network. Even if you’re not in the market for a new gig, understanding who’s working on what and sharing passions helps understand the lay of the tech industry a lot. It doesn’t need to be elaborate with a resume or a profile, though that couldn’t hurt. The breakfast was followed by a brief welcome to the space, the rules and the agenda of the meeting.

During the open house phase most folks either put forth their ideas or hear ideas from others that they can team up with. It is really important to have an open mind and thick skin in this phase. With passions and ideas flying it’s easy for your brainstorming session to be unthinkingly dismissed. Additionally, it’s very easy to find an idea similar to yours but far better realized. It’s common for folks to start in one team and then leave it for another. Hey, at this phase it’s all fair game and everyone wants the best use of their time. But preaching this idea and following it is different, and I quickly got attached to my own idea having explained and justified it to others. With or without a team (I had to settle for without), I decided my idea suited me best and I was going to realize this. Having picked a location (pick areas surrounded by other teams; but bring headphones to zone others out when needed), I proceeded into …

The coding phase

… the most stressful section of the day. Most of this time will be split into trying to get a weeks worth of work done in a few hours. Most folks find themselves working without any clear design docs and navigating working with people they’ve never met before. Even working alone I found myself getting annoyed when tech I had never touched before didn’t work the first time. It’s important to remember the goal is experimentation and learning, failure in a hackathon is fine and expected. Most recommendations and suggestions I could have here are very specific to the actual technology being worked with. In the case of Blockchain, I was out of my depth very quickly, and reoriented to going to every session I could and learning how Blockchain would impact my idea rather than trying to get it built.

As soon as you have the basic design down, work on your presentation. In a lot of hackathons getting a working product is crucial, but for many, having a proof of concept and a good presentation is just as effective, if not more so, due to Murphy’s Laws. Most hackathon presentations will have a specific time limit and schedule so practice your presentation to ensure it’s within these limits as when you present…

Presenting and after the hackathon

…things will inevitably go wrong. It’ll take time to connect to your machine, demos will fail, links will break, people will stumble in their lines, or in my case, you’ll get the length of your presentation wrong and be cut off half-way through. The point is, code for fun and present professionally and you’ll have both the fulfilling experience of building something new, and the self-promotional aspect of sharing your ideas. If possible, make a video presentation/demo and upload it. That way it works on any laptop, is well timed, and you can double down with a live demo after.

And the day is done! But you’re not. Collect contact info from the members of your team that you worked well with, recruiters, and hosts. Folks who go to one hackathon might go to another and you might get a fun coding crew out of it.


  • Read up on the source material
  • Find a problem(s) to solve
  • Read the hackathon agenda
  • Figure out your location and travel before hand
  • Network
  • Have an open mind and thick skin
  • Failure in a hackathon is fine, almost expected. The goal is experimentation and learning.
  • Code for fun and present professionally
  • Collect info and contact

Good luck and happy hacking!