What I learned competing in 20 over the past 5 years.

Introduction

A hackathon is actually more a sprint than a marathon. Where talented people form small teams to collaborate on ideas and sometimes compete for prizes over the course of a weekend. There are many variations and it all depends on the organizer's choice.

Why should you attend a hackathon?

• If you're a student in high school or college, it's a great opportunity to work on real problems with more experienced people. Who knows, maybe it could lead to an internship. Some hackathons understand this dynamic, and accept resumes so sponsoring companies can recruit you.
• If you're already employed, then it can still be all of the above while also presenting an interesting challenge in which you can sharpen your skills.
• If you're more senior in terms of experience, hackathons should still be of interest to you because of how valuable your mentorship and subject matter expertise can be. Plus, it could be a great breeding ground for an intrapreneurial endeavour, or practice for launching your own company.

At the risk of sounding hokey, whatever level of experience you bring into the hackathon, you are not going to regret attending. The cherries on top of building something you're proud of with a tight-knit team, are all the new friendships and connections. And if prizes, money (in the form of giant checks), and swag are more up your alley, then those abound as well.

Remote vs. In-person hackathons

We should distinguish between the in-person kind and the remote kind. I've participated in both, and must wholeheartedly admit that the in-person hackathons are where the magic happens. Especially if it's going to be your first one. I couldn't recommend finding an in-person one more.

Remote hackathons offer the same benefits that remote working does. However, these work best if you are already on a team that has built up rapport. Hackathons are highly collaborative, and working remotely just doesn't cut it. There has been a ton of innovation in multi-player tools and video chat tech, but it's all relatively low bandwith compared to working in the flesh.

The rest of this article will assume you are at an in-person hackathon with little to no experience attending one. My hope is that there are some applicable bits of advice to follow.

Preparation

• Will you be working solo? Is that allowed? Is there a minimum or maximum number of team members allowed? On this note, check other rules to make sure you are eligible. Some hackathons are for students only, others are corporate hackathons meant for employees of the company.
• Read the entire description of the hackathon on their event page, then read it again. There should be an agenda, look it over and visualize yourself going through those events. Get familiar with the directions, decide if you're going to take public transport. If you're driving, do you know where you're going to park? If it's remote, will you have stable internet connection and a channel of communication with your team (Slack, Discord, Telegram, etc.)?
• Did you pack a laptop charger? A secondary monitor (if you like using one)? How about a mouse? Earplugs or headphones? Refillable water bottle? Take santa's well-worn advice - make a list, then check it twice.
• Generally hackathons don't allow any code or design to be begun before the official start time. However, this doesn't mean you can't research the prompts or general topics of interest. You can even start preparing and sharpening your tools. Prepare for a distraction free browser experience and block social media sites. Download any frameworks, packages, or software you will be needing (but don't go overboard because you may not end up using all this).
• Get plenty of sleep (8 hours) leading up to the event. Normally these hackathons are on weekends, so try to catch some solid z's Thursday and Friday night at the very least. On the topic of sleep, do you want to go without sleep during the event? Will the venue allow you to crash on the floor or sofa with a sleeping bag? Or will you stay at a friend's place or AirBnb? Decide ahead of time and make arrangements appropriately.
• Some of these things seemingly have nothing to do with hacking, but have everything to do with your mindset leading into the event. You don't want to be lost, late, or uninformed before you've even begun.

Early phase

• If the event is well organized, there will be an M.C. welcoming you profusely, and instructing you on the next steps. There will be introductions, a short word from key speakers, and then a summary of what is normally already written up in the description for the hackathon in case you missed it. Keep your ears perked for special announcements.
• Find a good spot to bunker up. This means a table that comfortably seat you and several others. There should be outlets nearby for your various electronic devices. Beware of glaring windows without blinds. Also try to avoid being near a doorway or highly trafficked area of the event space, corners and out of eye-sight nooks and crannies are always more comfortable. My preference would be a sound proofed meeting room, whiteboard in tow.

Team Formation

• If you aren't already on a team there may be a short team formation sesh, in which you speed date with others like you. There is always time before the actual start of a hackathon to introduce yourself and team up, so put yourself out there and team up early.

• If you already came with a team, then you're ahead of the the pack. You can start getting situated with a head start.

• Which hat would you prefer to wear? This doesn't mean you need to have X number years of experience, it's more a question of what role would you like to take on during the hackathon? Maybe you're a closeted designer that works day to day as a product manager, but misses getting their hands dirty. Make it be known how you'd like to contribute.

• Product Role: At the bare minimum you need a product person, this could be a no-coder, coder, or designer. Ultimately, the product is whats being pitched, you can talk all you want with fancy slides but judges want to see a demonstration.

• Presenter Role: The next important role is the presenter, who tends to be more business minded. Most judges work in the corporate world, and there is a certain level of professional delivery they expect.

• Technical Role: Depending upon the hackathon, you may also need a backend developer. This would be somebody who understands how to create APIs, query databases, or even uses fancy machine learning frameworks.

• Project Management Role: You may be thinking - "Why is there a need for management? We're all in arms reach of one another, shouldn't all hands be on deck?" You'd be surprised by how useful it is to keep everyone on the same page. I've seen plenty of teams diverge and have a difficult time tying everything back together into a cohesive project. Even if you don't necessarily have a dedicated PM, someone should play this role alongside the other things they are doing.

• You should be prepared to wear multiple hats, especially if your team has fewer than three people. In an ideal world no one is stepping on each others toes, and everything runs smoothly. But I have yet to encounter such a legendary team. It is all about feeling each other out, keeping your cool, and approaching everything with a certain lightness. As soon as you start thinking selfishly, relationships break down.

• Leadership. A leader can naturally arise, due to either their casual confidence, years of experience, or charisma. But if your entire team is on a similar plane and comparable, nominate a person who would willingly take on the challenge. Most importantly, once this is decided, ensure everyone is on board full heartedly. In most of my previous hackathons, this topic was never explicitly broached, because it may be a bit awkward. No one likes being told what to do, especially when they're doing this for fun and sacrificing their weekend. A weekend only comes up 50 times a year, which is 2/7ths of their week. A leader is not a dictator, they are kind, selfless, and serving. A leader understands the motivations of everyone else and takes themselves out of the picture, only serving as the mouthpiece for the group. A leader isn't doing this to take credit, become famous, or avoid nitty-gritty stuff. They roll up their sleeves, and are on the front-lines. There is no need for generals in an out-numbered and out-gunned battle.

• The beauty of a small team is that you get to see directly what impact you're making. In a company setting, you play a highly specialized role and may never get to see how your changes impact the overall company. In a hackathon, everything you do has repercussions in the final product. If you're a student you've probably only worked solo on essays, and if you've done team activities they were always structured by what the teacher assigned. In a hackathon, you decide, you prioritize, and you define the scope. Embrace this freedom and power because this is what 'real life' sans curriculum is like.

• Default to action. Instead of discussing what the possible colors and logos could be. Just generate one and even if the entire team isn't set on it, go with that until someone makes a better one. If you've got a gripe, come up with an alternative or suggestion in the same breath. No unfounded complaints allowed. Everyone's a critic, we need filmmakers.

Start with the end in mind

Close your eyes and imagine your team is presenting on stage. What does it feel like? What reaction are you getting from the audience and judges? What do you envision on the slides? What is the demonstration like? Work backwards from where you want to end up! If ever you run into a dilemma in prioritization, ask yourself, will this even matter or be visible in the final pitch? That design language you're conjuring? Scrap it. Those acceptance tests you're writing? Delete. That commoditized log in screen? Unnecessary. Reduce until all you're building, is all you need.

Create the simplest and easiest version of your end goal, and then spend the remaining time on iterating and refining it. Don't start the foundation to a skyscraper, and only get half way through building it. There's no use in a half finished skyscraper. One can however live and work in a renovated house with extended attachments on either side.

Middle phase

Design Thinking

• Utilize sticky notes, whiteboards, rough sketches, to get anything and everything out into the air.
• Clarify what the underlying assumptions and key questions are.
• Iterate, jump off each other ideas, mix one and one together to take an idea somewhere completely new. Forego judging each other, and don't self-edit. You aren't looking for a revelation or eureka moment, just relax, have fun and feed off of each other's energy. Prepare yourself to be surprised, because no one can predict where you will end up. That is the heart of unbridled creativity. New understandings from different perspectives will ensure your team stands out from competitors who are starting off with the same information at the same exact time as you. Being original isn't what wins, but it sure is compelling.
• Do early user testing, talk to others and get them to speak their thoughts aloud. Your entire team might be drinking the same Kool-Aid, so you need to brace yourself for first contact with the outside world.
• Observe any patterns or glaring issues that were present in testing, and iterate! Prioritize and come to agreement on what should be improved or removed, and tweak your product.
• Most importantly, try to quickly document this process either with photos, screenshots, or screen recordings. Because judges always love to see the process at how you arrived at your solution.

What is your deliverable going to be?

Prototype

• The great thing about a prototype is that it's super easy to make. There is a whole spectrum from low fidelity paper and pen sketches, to ultra high-fidelity clickable prototypes that are almost indistinguishable from a fully operating application.
• I'd recommend you check out Figma, Adobe XD, Sketch, or InVision.

No-Code

• There has been a cornucopia of new no-code platforms and tools these days. Some of the popular ones out there include Bubble, Softr, Universe,
• There are just too many to call out, here are some directories of tools to get you started. Makerpad. No Code MBA. Nocode Tech tools. Nocodery. No Code Resources Trello Board. No Code Founders Tools.

Full Stack

• If there is no off the shelf solution where you can plug and play, then you've reached the end of the road. At this point, all you can do is pave your own way forward. That's where coding languages come in. I'll spare you the definition of what a full stack application can look like, check out this article for an explanation. There is no right way to build a full stack application or website. I mean just look at all these acronyms of software stacks on wikipedia.
• When there are separate teammates working on either the front-end or back-end there is often a risk of disconnection. Oftentimes you can fake a whole lot with just a front-end, but having a scalable and working back-end makes your demo that much more viable and impressive. Be sure to sync up between the front and back, just as waiters are constantly entering and exiting the dining room to the kitchen.
• There will be instances where the tools every individual is comfortable with aren't capable of tightly integration with one another. The earlier this is discovered the better. If it's discovered late in the process, then make do with what siloed elements you do have working, and tie it together with an artfully woven story.

Breaks

• Remember to take frequent walks, stand up and stretch. Don't stay crouched over a computer all day and night. Better blood circulation leads to a happier and clearer mind. Intense focus notoriously fogs the mind, and can make it feel palpably sluggish. Take a few deep breaths through your nose, as breathing through your mouth will aggravate an anxiety response.
• Avoid additional screen time on your smartphone, because you've probably been using a screen all day.
• Go meet other teams. Don't bug them, just ask them how its going. Chat with people you run into on the way to the bathroom, or grabbing a snack. Don't prod about what their idea is or anything they aren't willing to divulge. This is not about scouting out the other teams, but to share in the struggle. As tempting as it may be to speculate on what the competition is doing, ignore them. Looking in your back-mirror won't help you get to where your team ultimately wants to end up.
• Normally there will be mentors walking around, or seated in a special area of the event space. Be sure to take advantage of their presence. Get the most out of your question, by succinctly representing your idea, telling them what you've tried already, and by listening to everything they say before you respond.
• Hackathons can get stressful, I recommend you leave the premises ocassionally and observe nature. Watch the squirrels and birds outside if there's still daylight, and people watch drivers-by if it's night time. Just get good at taking your mind off of things. It isn't normal to be so singularly focused for such a prolonged period. Look forward to what you'll do when this hackathon is all over.

Converge

• Be sure to occasionally check in on each other, and take stock of your progress. Shorten the feedback cycles, because you're staring at a very tight deadline. Don't over do it though, I once observed a team do stand-ups every 30 minutes and I overheard one of them complain about how time-sucking these were. Be self-aware and team-aware, only incorporate these tactics if you see a return on them in the form of either increased clarity or motivation.
• Teams need to talk in order to get on the same page about things. But in order to implement what you talked about, you need to get quiet and put your heads down. Be on either side of this coin, but don't be in the middle. Make very deliberate and conscious choices as to whether you are converging or diverging. Working with a team can be like a game of telephone. It is a fine balance that you and your team will need to feel out. I've never pre-scheduled out this time, normally our team would converge when one of us is confused or at a road block. We would diverge once clear on the next incremental step.

Dealing with fall out

• There may be a situation in which a member wants to leave the team or give up. On the other end of the spectrum, there could be 'mutiny' in which someone opts to take the team in a completely different direction.
• Whatever the case may be, try to de-escalate, have a third-party mediate. Most small disagreements can be worked out with a broad enough perspective on the matter. The good news is, if you can see this through to the other end, the bond between the team will be even stronger. Always try to see the underlying reason, and see if there can't be some sort of compromise.

Ending (Submissions)

• Inevitably teams submit down to the wire. There may be an elevated sense of annoyance at any interruptions by the MC who is constantly reminding you to submit something to be eligible. Of course being done early is always best, but we all know this is hardly possible. Don't rush things, this is a guaranteed way to forget small pieces and make silly mistakes.
• Assign a single person ahead of time to be responsible for this phase. They will gather all teammates contact information and email addresses, other required documentation, and be responsible for doing a short write-up. Being able to put into words what you did is incredibly valuable and normally overlooked by other teams who see it as an afterthought. Therein lies the opportunity to differentiate. This should be a simple 1 or 2 sentence way of describing, to someone completely unfamiliar with your problem space, your solution.

Presentation

• Set aside atleast an hour to either pre-record or go through the pitch together as a team. If it is just one person pitching, give them copious feedback. Keep their confidence, while trying to poke holes in their logic as judges will undoubtedly do themselves. Reduce, remove, less is more. You don't want to be talking at the speed of an auctioneer, just so you can get through all your points. People remember things in three, so try to limit your key points.
• Organize your slides by Problem Statement, Solution, Demonstration, Future Considerations, Our Team. Use software like Slidebean, Google Slides, Prezi (etc.)
• Be aware of the time limit if there is one, normally it's something like 2-5 minutes. You may be cut off abruptly, as to be fair to all the other teams pitching. Better to have extra time for Q&A rather than to eat into this Q&A with the finishing touches of your already too-long presentation.
• If you're presenting. You don't have to memorize your pitch verbatim, I've seen past successful presentations with notecards or iphone in hand. You could even occasionally glance at the slide deck being projected on screen. You should however be completely familiar with the timing, order, and major points of every slide. There are tactics for memorizing such as the memory palace (link). Before you go on stage, don't compare yourself to the team that just went before you, or the team that 'killed it'. This is your time, and a great result can only come from you being 100% present and focused on delivering what your team worked so hard on.
  • Be enthusiastic, exude some energy and the audience will return the favor. Convince strangers that this solution could solve whatever problem you set out to fix.
  • Make eye contact, no one will pay attention to you if you aren't paying attention to them.
  • Use your hands, it helps you get into the delivery but also engages the audience.
  • Don't talk too fast, emphasize what you want everyone to remember and avoid filler words.
• If you're not presenting. Try to join the presenter on stage and provide emotional support. Placing your full attention on your pitching teammate and an occasional head-nod will work wonders on the audience and judges who are watching your every move. Don't be distracted by anything else, and be ready to swoop into to assist or help if the pitcher has some nervous breakdown or technical issue. If you're doing a live demo, there will also need to be someone 'driving' the demonstration. This 'driver' should be prepared to alt + tab between slides and demonstration (be it a browser or application running locally). The 'driver' should also clear their desktop of any messy files, and turn off notifications to streamline the presentation and show exactly what you intend to, nothing more and nothing less.

Awaiting Results

• You've done it! Take a breather and relax. The deliberation process could take anywhere from 30minutes to an hour or even longer. So take your mind off things, make any finishing touches on your submission if edits are allowed. Take this time to brush up on the documentation of your project. Self-examine how your team pitched, and maybe even discuss how other teams did. What was your overall impression of the competition if you were the judge. What could your team have improved upon? Where did your team excel? It can be fun to make predictions yourself, and see what ends up happening.

Victory or Defeat

• If you've beat all odds and come away with an award of some sort, congratulations! Sure feels good doesn't it? Smile, celebrate, take pictures with your team, judges, and newfound friends from the hackathon. This will be a memory you won't want to forget. Remember to stay humble, and thank the organizers for the opportunity. Sincerely thank any one who comes up to congratulate you. Soon after you will inevitably crash from the caffeine and exhilaration. Get a good night's sleep because you deserved it. But the next morning, take some quiet time to reflect on your victory. This is the moment when you'll have the most momentum. Your teammates will be bonded stronger than ever, especially with this public validation. Consider making your project open source, or investing the prize right back into your project.
• If you've lost and come away with nothing. Keep your head up. Be a good sport and go congratulate the winners. Network with them, exchange contact info, because you can always work together in the future. You may think that this was a waste of a weekend, when you could have been out enjoying the sun with your friends on the beach somewhere. But just reflect on what you've learned, the people you've met, and the fruit of your labor. You've learned what you and a team are capable of in such a short amount of time. This in itself is invaluable, because there is always that next hackathon or opportunity to exercise these lessons.
• Even if you stop working this and let the ball drop, you should document what just occurred. Put a line under accomplishments in your resume, add it to your portfolio site, at the very least write a diary entry about it. Your future self will thank you. This will ensure you have a better chance the next time around!

Links & Resources

• DEVPOST the home for hackathons

• NYC Mayor's Office of Tech + Innovation Hackathon Guide

• hackathon.com