A Short Guide to Hackathon Success
Time appreciation, asking the right questions, undigitize, scoping… a partial recipe for success
I’ve had the chance to attend a few hackathons over the past few years either as a mentor, volunteer, or sponsor. This past weekend I was at UCLA for LAHACKS, a huge hackathon focused on social innovation held every year. Hackathons are gatherings of people who spend a short time solving problems in teams and are sometimes competitive. Typically, it means building something (hardware, software, anything really) that addresses a need. Hacks can be pretty broad with little guidance provided other than the assessment criteria organizers establish to determine the winning teams (if any, they aren’t always competitive and don’t need to be). Hence, participants experience a fair degree of stress, which is completely normal, especially in hackathons where problem statements are open ended or undefined.
How can you operate effectively in this kind of environment? This article offers a few practical tips.
Time appreciation
Hackathons are highly compressed development cycles, in a crowded space. The first thing you might do as a team or individual is establish some timelines for sprints, working backwards from the delivery (usually a pitch). Leaving time for rehearsal, divide your time in to 4–5 phases that can be devoted to ideation, development, and iteration. It doesn’t need to be a hard schedule, but a rough guide to manage your time appropriately and remain mindful of time-consuming tasks that need to be dropped in order to progress. Remember, it’s not about perfection; making substitutes (of data, for example) or shortcuts is encouraged to arrive at something tangible by the time you pitch to any judges. Consider that you might be foregoing sleep to complete work by a given deadline. LAHACKS 2019 kicked off at 11 PM Friday night and wrapped up at 11 AM Sunday morning, giving hackers 36 hours to come up with something they could showcase. It’s important to account for how you work, and (when possible) devote the time when you’re most rested and alert to abstract, high-order problem solving and times when you might be more tired to less cognitive work (coding? ;) ).
Asking questions and chasing bounties
Sponsors might put up prizes for specific bounties that you and your team can pursue during the hackathon. Be very careful here. Much of the time, this might revolve around using a service offered by a vendor. At the outset, I noticed many teams asking what APIs were being offered, and how the pursuit of any side challenges could be incorporated in to their hack. I recommend waiting to find out what integrations and bounties exist, at least until after you ideate in the initial phase. That way, the why is (mostly) established and you can see if any technology providers can help you to achieve the how. Don’t build with a bounty in mind. Build with solving a problem in mind; if a specific side challenge doesn’t support that, then move along. So, rather than asking what bounties are being put up, ask if there’s any challenges or integrations that might support the idea that you intend to build.
Undigitize
Bring a notebook or sheets of graph paper and a mechanical pencil or pen to take notes, sketch ideas, draw a user journey map, or come up with a business model canvas. Don’t underestimate the power of moving away from screens to work around paper or a whiteboard to ideate and iterate. In the same vein, walk around, explore the area, and don’t sit for too long. It can be tempting to stay in one spot focused on a screen, but generally will not yield results, especially if you’re stuck on something. The pursuit of a hardware hack, which tends to be very tactile, is another way of breaking free of screens and code editors. Don’t let a lack of experience with hardware deter you, especially when there are mentors around.
Scoping
There will be pressure to do something big, from sponsors, organizations, and yourself. During the ideation phase, it will be key to distinguish between what you can demonstrate tangibly, versus the larger system in which it fits. Meaning, you can’t build it all, and nor should that be a goal. Identify a scope of work — the requirements you intend to meet — that can be reasonably completed in the time allotted. Scoping is an art and a science: experienced product managers at big companies struggle with it. You can overcome scope creep by articulating your requirements and keeping them where everyone can see them (see undigitize, above). Building a product that connects 12 data sources? Integrate 3–4 to show the potential and simulate (e.g. mock-up or wireframe) the rest.
Conclusion
Your success at a hackathon will largely depend on team dynamics and making best use of your time to tackle the requirements that comprise your solution. I hope the four tips are helpful, and practical. These aren’t hard and fast rules; they’re guidelines. Some might come naturally, while others you’ll need to remain conscious of throughout.
I think that hackathons are a terrific way to prepare for a technical interview: you’re under pressure to apply your skills in an artificial construct with uncertain and changing inputs. It can be uncomfortable, but the consequences of failure are nil. So don’t be afraid to go for it, even if it’s just to be on a team to observe the process and participate as a notetaker or sketch artist.
Use the comments to post your own hackathon guidance! Thanks for reading.
