I’m often surprised by the grand expectations that younger coders believe is necessary for success at Hackathon events. Here, in no particular order, are some of the most common misconceptions and tips I’ve learned.

Misconceptions

1. You need to know how to code

As I was waiting to sign in to StuyHacks, I often heard students bemoaning their lack of coding experience. They were wrongly convincing themselves to believe that because they don’t have as much coding experience, they couldn’t make a great end product. Personally, I believe this thinking is wrong. While a working prototype is nice to have, ideas are more important.

In the course of 5 to 12 hours, it is unreasonable to expect flawless products — even for professional Software Engineers. Instead, the potential for an idea to be a stepping stone to something greater is much more valuable. Earning the Innovation Award in December with a team that didn’t have the most coding experience proved that. In fact, our prototype had barely any lines of code at all.

I think the key insight is that programs are merely communication mediums through which we can express our ideas. What matters most — and what we were judged on the most — was the idea. It doesn’t matter how advanced or technical your program is as long as the idea is unique and solves something that people care about.

2. You need a team of “smart people”

For most fellow hackers, “smart people” seems to mean talented coders. But coding knowledge is not the most important. Instead, I’d argue that ideas are paramount.

For me, I believe that any team can be successful — but only with the right mindset. At most hackathons I’ve been to, successful teams weren’t the ones with the most coding experience, but instead people who focused most of the time perfecting their idea and connected their ideas to solving real world problems. As long as you form teams with the people you know would actually get work done, and who care about connecting solutions to “societal problems”, then honestly it doesn’t matter what their level of coding experience is.

In fact, I think, working with a random team is actually much better since being unfamiliar with the other members of the team encourages respect for one another, listening with an open mind, and accountability. Especially when working with a group of strangers, it’s easier to hold one another accountable. Plus, they often bring diverse backgrounds and viewpoints, which makes it’s easier to come up with unconventional ideas.

3. You can make almost anything

At some hackathons, there is often a theme that helps focus the ideas that teams come up with. However, at StuyHacks and other hackathons, the problem is often more general, or maybe there isn’t even a focus at all. With this these types of ‘open’ hackathons, I find that many students don’t spend as much time coming up with original ideas. In fact, I’ve seen everything from puzzle games to online price checkers to even a VR platformer. While I love these ideas, and there is no doubt that these teams put a lot of effort into the work they’ve done, the problem is that they’re not unique, and don’t solve a specific customer need.

From watching numerous entrepreneurial TED Talks to studying the keys to successful startups in my Entrepreneurship class, I now come to understand that the difference between them is not about the effort they put in, but rather the time they spent in researching the problem gaps that exist, finding existing solutions, and brainstorming key differentiating factors.

It is this step that is often overlooked. Yet it has the most profound effect for converting a good idea into a great one. Oftentimes, differentiating factors don’t have to do with the primary goal of an app. For instance, the objective of a quiz game is to entertain the user, but your differentiating factor doesn’t necessarily have to make the game the most entertaining thing of all time. Instead, you could add an aspect that helps realize another human need: self-actualization — the need to feel part of a greater cause.

As an example, the quiz game that won StuyHacks wasn’t necessarily the most entertaining game in the world. Rather, it combined the cause of global warming into a quiz that not only entertained users, but also raised awareness for the staggering carbon footprint of the average person.

Tips for success

1. Do your research

Especially when you have no idea what to do, always make sure to research your problem carefully. Start by creating a team document for your research. Organize it with headings — you can press ctrl-alt-1 to ctrl-alt-2 etc. to make headings. Make sure to make a special section to cite your sources — you’re not making a research paper, but you should at least have some way of going back to what you found in case you might need it again.

Any statistics or powerful quotes must definitely be placed in a section on its own. These pieces of information are essential for convincing any judge that your idea is worth considering — that other people have demonstrated that your problem truly necessitates a solution.

2. Get to know your team and delegate roles

Teams go through several stages — forming, storming, norming, performing, and adjourning. Of course, in the course of one day, it is almost impossible to go through all stages. However, assuming you are working with a ‘random’ team, make sure you at least start the processing of forming your team — getting to know them, becoming comfortable with working with them, and knowing the strengths and weaknesses of each other and the team as a whole. This is imperative for knowing to which parts of the projects you are best able to contribute. Then, divide responsibilities — it’ll help your team get a lot done faster.

3. Make a pitch presentation and practice it

You can have the best app out there, but without a strong presentation, no one will bother to figure out why your team’s app should win versus someone else’s. It’s your job to help judges understand what makes your app special. Start by presenting your problem. What does your app solve? Why is it important to be solved? Are there any statistics or facts and figures that illustrate how urgent or quintessential it is to solve this issue? According to some of the judges I’ve spoken to, too often teams don’t know what problem they are solving and end up scrambling for words when asked what their product solves.

Next, present competing solutions (optional, since most pitches are too short to include this). Here, mention what competitors do and why their solution may not be optimal. Try to be objective here, don’t say your solution is better in all respects, but rather frame it in terms of tradeoffs.

Then, present what your solution is. State explicitly how your app solves the problem and how its approach is unique in the way it solves the problem. Indicate to judges why your approach is better than others. The rest of the time you can demonstrate your app.

Practice your pitch multiple times with your team. You should also use templates from SlidesCarnival or from SlidesGo to help differentiate from teams that use default Google Slides themes.

Closing thoughts

I should point out that while it’s fun to win, don’t make winning the sole purpose of going to hackathons. Just make sure to have fun, meet new people, and do your best. Good luck!