Hacking your first hackathon: Learn from my mistakes!

Going to your first hackathon? Going to your first hackathon ALONE?

I would like to flatter myself as a functioning introvert. I understand the anxiety and fears of going to a hackathon for the first time all alone and feeling inadequate. I have no great interest in FinTech, nor am I very financially saavy. On top of that, I do not have coding skills, and I do not have a strong math, law or finance background. You know, the useful stuff for a hackathon with a finance theme. What the hell can a measly PhD candidate like me contribute? Hindsight is 20/20, so here are lessons I have learned to implement for next time and how I would redo my experience, given a magical edit button.

I was extremely blessed to find a group of students mainly from Cornell Tech who offered me a position on their team. I have a feeling they were also confused at what a PhD student in Pharmacology could also contribute, but they still gave me the benefit of the doubt and welcomed me into their group. (Seriously, I’m really appreciative of them for being so nice to me!) After a small casual chat to get to know the rest of my teammates, who knew each other already, the hackathon took off!

Apparently hackathons start by asking people to come up to the front and presenting their ideas. The two topics you could pick from were anti-money laundering or financial inclusion. I was somehow under the impression we were going to get a prompt that would narrow down the field and then we can start working on ideas based on the prompt. Amateur assumption. Hopeful naive amateur assumption. I didn’t even know what the topic was until I got there. After sharing ideas, there is a brief lecture by an expert on the topic to give his perspective and insight.

REDO #1: Know what the topic is and read a bit about the background beforehand so you don’t frantically read articles on your phone instead of paying attention to awesome informative lectures. After you feel like you comfortably understand the background, brainstorm a few ideas or even just what problem you want to tackle. Don’t come COMPLETELY empty-handed. It’s OK if you do, but if you are already scared and alone, it helps. 

Ideas that are presented aren’t always fully fleshed out, so you don’t have to feel pressured to come up with a brilliant one. If you have a wisp of an idea but no team, you can describe it to everyone (remember: desperate times call for courageous measures) and express your need for a team. Other people will come empty-handed and may approach you to be on your team. Just a hint of an idea can spark something in your teammates to join and strengthen your train of thought. It’s always fun to fully flesh out the product as a team so it becomes everyone’s pet.

REDO #2 (redo, meaning do it again): Try to be on a team with people with a diverse background. 

Pulling from the expertise from people with diverse backgrounds (computer science, MBAs, lawyers, even PhDs too) will build a strong and awesome product you will be confident in. My teammates were pursuing their MBA, a masters in computer science, or a masters in connective media. One thing I will say is that students from Cornell Tech (or hackathonat least the ones I met) are well trained by their curriculum to do these types of events. They are such a valuable resource to have on your team! There’s so much to learn from them, so please take advantage of the opportunity. Again, they are very nice, but also they work really well as a team, which is critical for a 3-day hackathon. If you are interested in leaving academia, take notes on their soft skills.

REDO #3: Bring your own K-cup. Coffee at Cornell Tech is weak. 

You will be there for a long amount of time.

REDO #4: Don’t apologize or feel bad for your inability to contribute. 

You may not be able to contribute to the back-end or front-end development, but the value of a PhD candidate is to help during the conceptual development of the product, the content of a slide deck, and the presentation. We are trained to be critical and to ask the right questions to approach a problem. It’s the same approach to your scientific investigation. I’ve been to so many industry career talks where they have some spiel about how PhDs are so cool because they can gather a lot of information at once and distill them down into several digestible concepts. All I have to say now is, damn it they’re right. We know how to do a thorough background analysis and ask the right questions that are important to the task at hand. Just do it. You’ll see. I was a skeptic once. I found that my main contribution was to understand the background, identify potential hurdles and advantages of our product, find supporting information for our claims, find convincing reasons why your need is an important one to address, get an idea of the market and competitors, and see if your product is viable (legally, practically, would your target audience even want it). Also, I found my R skills useful to make graphs and do some quick stats. My Adobe Illustrator game was on point and I quickly made some awesome looking figures to clearly diagram how our product worked. This was important to help in the product development and business development side. Sure, we may not be able to help with the actual creation of the product, but what’s the point of making something if you convince people it’s important? Also, thank god for the MBA student (refer to REDO #2) who has experience with non-academic presentations and with a good sense of aesthetics. I can barely put together a matching outfit. (I’m so cool. And yes, I know how cool it is to declare “I’m so cool.” I’m the little one in the picture.)

REDO #5: Avoid foods that will put you into food coma. Avoid consuming quantities of food that will put you into food coma. 

This is not a trivial task. Food is free. You will be there for a long amount of time.

We did not win. We were all very confident about our product, and I think we had one of the better products out there. Our issue was that we didn’t sell it well.

REDO #6: Practice your 4 minute pitch. 

We ran out of time before we could get to the best part of our presentation and got cut off just halfway through it by the slow clap of “4 minutes is up”. I think the presentation was what killed us, not our genius-ultimate-awesome product. But anyways, we had a great time, learned a lot and we are proud of ourselves anyways.

The best thing about the hackathon is that it is over after 3 days. You aren’t creating a real company. Ask yourself what you want to get out of this experience and remind yourself when you feel insecure. So go all out and don’t be afraid to crash and burn! Even if you’re only there for the free food, shirts and/or cups.

One comment

  1. Thanks for the awesome post, Bonnie! I relate definitely on feeling lost at a hackathon, but unlike you I didn’t find my niche in time, especially after someone took my idea! Grrr! (Moral: trust your instincts, find people who are trustworthy and not just schmoozers. Working for 3 days is intense and having faith in the people you’re working with is uber important.)

    Re: Redo 1: Yes. At my hackathon I was completely thrown off by my topic and its intensity (human trafficking), and had I had a few more days to prepare, I would have felt more mentally resilient. This is such an easy small thing to do that makes a big difference.

    Re: Redo 2: I’m super excited about this aspect of hackathons. Non-academic types are different to work with than academics, what better way to learn!

    Re: Redo 3: Good to know.

    Re: Redo 4: Still insecure about this. But I guess I don’t know til I try. I was definitely concerned about my background, and I also thought I’d have to learn front-end and back-end development on the fly and I got really intimidated. But I think we can all learn to start with what we know, work with what we’ve got, and slowly build up the skills we don’t have before an event.

    Re: Redo 5: Also good to know.

    Re: Redo 6: Something for a data science club meeting, perhaps… 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *