Red Flags In Hackathons

Red Flags In Hackathons
As a participant and mentor in several hackathons, I will share some tips about ideation and general approaches for hackathons. This post is intended to be for participants but also for mentors/organizers. Some of the things may sound silly or really obvious but trust me, I have seen this happen many times. These tips are for any kind of hackathon, but mostly for Social Good hackathons.

Tips For Participants

Don't Reinvent The Wheel

This is the most common failure at a hackathon. Many times, unintentionally, participants come up with ideas that are just a re-branding of a product that is already out in the market.

Be Inventive

Think out of the box rather than picking up an idea that’s in the market and briefly adapt it to your problem. Think on the problem you want to solve, define a boundary, and then apply technology to solve it. Remember to keep it short, sometimes cool ideas arise in hackathons but they are enormous monsters that can’t be tackled in few days

Know The Problem

As an extern to a certain ethnicity, it is hard to have insights about what is a problem and what isn't. If you want to solve a problem that doesn't exist, then you fail right from the beginning. My suggestion is: if you come up with a cool idea, do a short research with people keen on the problem.

The "Social Network" Pattern

Usually, apps that only create a channel of communication among people are a bad idea. This is a pattern that I've seen uncountable times. This happens when an app relies on the network of people to do all the work and the app itself doesn't add any value.
There are some rare counterexamples to this, my favorite is "Be My Eyes": an app that connects blind and low vision people with sighted volunteers for visual assistance. The whole value of this app is in the people, and by the way, this is an incredible idea.

Take Risks

Hackathons are a safe space for failure. Great hackers are the ones who try. Every time you work on experimental stuff, you'll encounter a high chance of failure. Don't be afraid of failure, embrace it. Believe in your judgement and your skills to create something that will have an impact  on the world.

Don’t Login/Register

Spending time developing a login screen as well as presenting it and actually going through the registration flow during a demo is a waste of time. Login/register is a really well known flow by everyone and it doesn’t add any meaty parts to your presentation. This can be mocked and start directly with a story.That brings me to my next point.

Tell a Story 

Be prepared to present your app with context, not just explaining the features. This makes it easier to explain what you are doing and why.

Document Your Repo

Add a README file to your repo explaining the problem and listing team members, and possibly screenshots or a YouTube video demo.You can also providelinks to presentation or anything else valuable.

Be Ready To Present

Do a mock presentation and try your demo at least once before showtime. Have your laptop ready with the slides open and the emulators, if any, already loaded. Be sure to use all the screen, that the content is visible and readable.

No mic fights! When presenting and answering questions, give your teammates some space. It doesn’t matter if they are kind of struggling with it, if you go and interrupt them or show a completely opposite point of view of an answer, then everyone loses. Work as a team!
Also, don’t retain the mic answering all the questions. Maybe another team member is more keen on certain questions, so before starting to talk, shortly decide who wants to answer.

Moderate your language while presenting, and possibly always. Never use bad words or curse when you are presenting in the stage.

Disobey The Norms

My last tip for participants is to disobey the norms (even this post itself). Mentors and judges are professionals who have been in the industry for a while and have a lot of biases. On the other hand, participants are starting fresh. Show us new ways to solve problems!

Tips For Mentors/Organizers

Now I’m going to be a little bit arrogant and share some tips I’d like organizers of hackathons to take into account. I’m not the most qualified person to critique this, but still I’ll share my vision.

Avoid Conflicts Of Interest

If you have several stakeholders represented by the same person/company, this creates a conflict of interest. Roles like mentors and judges are antagonists and can’t be the same physical person.

Do Judge And Announce A Winner

There are some hackathons that are only collaborative, and after intensively working for one to three days no winner is announced. I think there should be always a winner announced, and this has nothing to do with making the ambiance thought or closing the doors to cross-teams collaborations. I have been in hackathons where there is a first prize with money, but still mentors have the clear goal to collaborate with others. After all, the event is to motivate participants to come up with cool solutions and also make them learn how to move in an extremely fast environment. “Keep the eyes on the prize” but if there is no prize I have seen participants getting disengaged after the second day if they having a hard time.

Conscious Mentors

Be sure that the mentors have great soft skills. It will lead to one of two things:

• They don’t properly know how to motivate participants and push them in the right direction.
• They make participants feel anxious or even panic.

Also, be sure to stand clear that mentors are not enemies and can collaborate with each other for a greater good.