A First Years’ Guide to Hackathons
Written By Sashrika Surya and Parasrawatjr
Hackathons are designed with innovation in mind. Many companies and educational institutions promote hackathons to encourage young developers to come up with unorthodox ideas. A lot of young students are excited about these events but don’t exactly know what happens at a hackathon or how to participate in them. Here, we try to answer some of these questions with the experience we gained at our very first hackathon.
ACM-VIT has been hosting hackathons for the past 3 years. The 4th edition of Code2Create, a 36-hour hackathon, was held from March 7th to 9th, 2020 in the VIT-Vellore campus. The application process was heavily based on our GitHub accounts and LinkedIn profile so we suggest that you engage actively in both these platforms.
Zeroing in on a Problem Statement
Ideas for hackathons are the main element. The innovativeness of an idea constitutes a major part of the judging criteria. To help along the ideation process, most hackathons release a number of tracks. C2C started releasing their tracks on its Instagram account about a week before the hackathon started, which included defense, space, construction, disaster mitigation, fintech, vision intelligence, women in tech and social transformation.
We decided to pursue the track of “Disaster mitigation” as we believed that it had a lot of scope for social impact as well as challenging problem statements to solve. Within disasters, we picked up “flood-like” calamities as we had the recent example of the devastating Uttarakhand floods of 2013. India faces major losses while dealing with such natural disasters. While studying the problem in-depth, we realized the importance of a faster, more efficient pipeline for basic flood relief operations. Since we were tackling the critical topic of “Flood Relief” and the stakes were quite high, we wanted to ensure that our solution covered all bases.
The Final Hack: BharatBeacon
“BharatBeacon” is a smart and efficient three-stage pipeline for dealing with flood disasters.
Stage 1:
The preemptive measure includes a logistic regression model to predict floods based on data such as rainfall during the pre-monsoon months, the average amount of rainfall within the first 10 days of the monsoon season, etc. The model was built to predict state-wise possibilities of floods, as in a tropical country like India, rainfall occurs at different times for different regions, hence the monsoon months tend to differ. It reached an accuracy of 89%.
Stage 2:
During the crisis, our team came up with the idea of a beacon, to be deployed across all of the flood-struck areas. Each of these beacons would be equipped with an ESP8266, a GPS module, an LCD and 3 pushbuttons. They would form a P2P WiFi mesh, where each node is connected to at least one other node, with the root node present in the relief base camp. On picking up this beacon, survivors would be presented with some simple questions like, “How many people are there?”, and “Is there any medical emergency?”. Upon answering these questions, the collected answers would be sent to the root node along with the longitude and latitude of the beacons. This helps the army to get crucial information in real-time from ground zero with a 100% accuracy. All the information was displayed on a dashboard in a simplistic yet effective manner for easy handling of data.
Stage 3:
In the post-crisis stage, we wanted to focus on increasing the speed and efficiency of information processing. We decided to make an abstractive text summarization model for summarizing long ground zero reports to small digestible chunks.
Dealing with the Judges
Coming back to the hackathon experience, the hardest and the most-nerve racking parts were certainly the check-ups. In total, we had 3 check-ups out of which 2 were elimination rounds. A technical team consisting of 9 or more people would come to each team and ask them about their idea and their progress. The very first non-elimination type check-up was mainly idea centric. However, our idea was whittled with questions like “Will you be able to pull this off?”, “Are you sure it can be done?”. Frankly, it was quite frightening as none of the questions were technical so far and the organizing committee was more worried if we would be able to pull this massive project off in 36 hours.
The second check-up and the first technical check was exactly what we expected. More than half the teams were eliminated and the criteria for the check-up included an 80% completion rate for the project. Since we had been solely focusing on our own parts, we were much ahead of 80%. Both our machine learning and deep learning models were ready and giving accurate outputs. Our beacon was almost ready, with only a few backend issues remaining. What really kept us afloat was the fact that we had a demo ready for the judges.
The last check-up was our best claim to fame moment. The judges wanted to check our git log, usually, this is done to ensure that the code is not a blatant copy of someone else’s project. We were asked repeatedly if that was the case and when they finally entered the command, there were more 50+ commits in our repo. The sheer happiness after the judges left was a mark of our own hard work since hour 0. We had finally made it to the top 11 teams who got to present their solutions.
The Final Countdown
For the final pitch, an external judge was called to decide the final winners. While the idea of standing up in front of all those teams was nerve-wracking, we were also excited as we were confident about our project. After a 5 minute pitch with a presentation and a live demo, we were finally done with our very first, 36-hour hackathon. Our hard work was rewarded with the title of ‘Best First Year Team’.
Few Nuggets of Wisdom
- The idea does not have to be elaborate or complicated. A simple yet innovative idea, which preferably helps the society positively, goes a long way.
- The idea should be well presented. At each inspection round, all our members pitched our parts, and the more confident we were, the happier the judges were. Speaking skills, presentations and beautification of the project are very important.
- WRITE WRITE WRITE your own code.
- Experience is the best teacher. The same way you can’t be taught to drive without having the first-hand experience behind the wheels, you won’t feel ready enough for a hackathon unless you actually attend one.
