Approaching a Hackathon

Are you prepping up to participate in a hackathon?
Looking for tips to optimise your time and energy over the duration?

Here are a few things to keep in mind before you go in on day 1.

Hackathons these days (nights) are high packed with energy and enthusiasm. While the focus on fun is certainly great, don’t assume it to be just a picnic.

Most of the hackathons I’ve won involved working on a problem statement that the company had for a long time, but never a P0 issue. Your idea does not necessarily have to be a tech feature for the product. Think about the problems in the HR dept, an improvement to the hiring process, reducing overall carbon footprint? Bring out the engineer/designer in you – forget about the box.

If you do end up choosing a tech product – try breaking it into the set of features you need to implement. Prioritise your sub-features. It’s better to be able to demonstrate the end to end idea rather than have only the first part working.

Prepare for the hackathon early on. Think about the problems you can anticipate, this leaves room for unanticipated problems (trust me, there will be many).

Work on the presentation from the 0th hour.

Most teams which have done brilliant projects fail to showcase them owing to an improper presentation or lack of rehearsal.

The presentation/demo is one of the most (if not the most) important factors in deciding the winning teams. Tailor your MVP/Development around the narrative of the demo.

You might want to skip/abstract out the parts of the project which are not a focus area in the demo.

Lastly, remember that the real success of your project will be when you take it to fruition. Follow up with the org to try and create a plan around taking this idea to production. (albeit behind a flag). Keeping this in mind will help you write sane code.

P.S – do not rm -rf the project folder after you win *wink* *wink*

Go ahead hack on!

2wh52w