This was my first time winning a hackathon and I am so grateful to have worked alongside such smart and creative teammates. I had so much fun brainstorming ideas, discussing designs, and coding together! Through our project, I also learned how to use Qoom and improved my web development skills. Here is what I’ve learned from my first two hackathons that I think helped me win this one.
- Find teammates with similar skills early. Your team and how well you will work together determines your entire project. For my first two hackathons, my focus was to find teammates who had the same “experience level” as me regardless of the type of experience. As a result, we all had different skillsets and had to follow the only person who knew how to code in the language we decided to use. For example, in my last hackathon, my team did not have common skills so I led everyone in using Flutter despite the fact that I barely knew how to use it. This ended up not working at all so we turned in a Figma mock-up that I took no part in so I felt that all my effort in Flutter was wasted. I learned from these mistakes and during this hackathon, I formed a team of three with almost the exact experience as me: Java and HTML/CSS/JS so we would have options for our project and we could all contribute. Side note: try to find people in the same (or at least close-ish) time zone as you. Don’t think that having someone in a different time zone is good because you can “take shifts” coding-it doesn’t help. Also, by forming your team early, you can start getting to know your teammates more before you take on a full project together. You can also brainstorm ideas and plan meetings early on to get a head start.
- Brainstorm individually and speak up during the group brainstorm session. In my first hackathon, we decided to make a website for vegan recipes and despite my doubts about it, I went along with it since everyone else in my team liked the idea. However, I felt that it wasn’t unique and the features we wanted to add were not feasible for our skill levels. On top of it, I wasn’t passionate about the idea. Regardless, I ended up doing most of the work since I had the most coding experience and I couldn’t even finish it since no one could help me. I think the problem here was that we did not come up with ideas on our own so we just peer pressured each other into going along with an idea. This time around, my team took time to brainstorm as many ideas as possible (we had five) individually prior to the hackathon and we compiled them into a Slack channel in our team workspace (Google docs works for this too). We made these ideas as thorough as possible with objectives and long descriptions. This allowed us to effectively discuss each idea during our first meeting one by one. We focused on usefulness, uniqueness, and feasibility to rule out ideas and narrowed them down to the top three, and voted. For example, we ruled out creating an insurance storytelling game because of how there were many possible insurance plans and it would not be that useful since companies provide employees insurance. We ended up voting on a finance storytelling game since financial literacy is a big issue that is not too hard to research and we could make it as simple or as complicated as we wanted. During the meeting, none of us were afraid to speak up and directly oppose an idea. One idea I opposed was an app to remind seniors to take their pills since it was generic and not useful to seniors who do not use phones. Despite my other teammates supporting the idea at first, I continued defending my point and one of my teammates agreed although the person who came up with the idea still defended it. This brings me to my next point.
- Do not be personal about ideas and skills. If you came up with an idea, do not defend it blindly. Listen to your teammates’ reasoning as they may be thinking about your idea more objectively since it isn’t their own. Your project is not for yourself, it’s for others so this is not a time to be biased. Additionally, do not support ideas if you are only doing so to be polite or to make your teammates like you. In my first hackathon, our discussion turned into somewhat of an argument so I backed down and agreed with the vegan recipes idea to release the tension. This only made matters worse because I felt unhappy doing so much work for a project I didn’t like and we didn’t end up having a working product. Who cares whether your teammates think you’re nice and supportive? They’ll like you way more if you argue for a better idea and win, trust me.
- Simplify, simplify, simplify. I cannot stress this enough. In my first two hackathons, I spent most of the time creating a login system and barely created the core features. DO NOT DO THIS! If you can easily make a login system, great! But if not, focus on the meat of your project and try to make that as good as possible. At least make it work. In this hackathon, my team simplified our website by only creating one story about budgeting and polishing it up to be the best it possibly could with educational descriptions and images. For the other stories (insurance, retirement, joint finance), we only made descriptions and let their start buttons lead to an “in construction” page. You do not have to turn in a full-fledged project; as long as you show that your project is useful and unique, the judges will appreciate that. And showing that your project can be expanded even without actually having those features exhibits potential that will not be overlooked. In our case, it would be easy to create additional stories based on our first one so our project is definitely expandable, but we did not implement those for the sake of time. Instead, we showed what the additional stories would be about on our home page. The most important thing here is your idea.
I hope reading about how I won my third hackathon motivates you to attend hackathons (or apply these tips to other competitions). This was my favorite hackathon so far and I can’t wait for my next one!
Check out Coineage on Devpost and on Github!