Hailing from the same alma mater that proudly hosts Hack In The North every year, they have been a constant inspiration and a formidable force to be reckoned with in any hackathon. Considered to be the team that was promised in their alma mater, they have captured many forts throughout the country namely, Smart India Hackathon, Hack36, Topcoder Humblefool Hackathon, Prototype IIITA and yours truely, Hack In The North. Hyperbole aside, these humans of IIITA can easily charm Thanos into killing himself through their quirky, witty and polished answers to any posed question or circumstance. In a quick interview with the sudo code, they relive their experience as we slip into the nitty-gritty of hackathons.
Abhishek: Very humbled to be sharing our little experiences with you. Thank you for having us. So we are a team of 4 - Abhishek, Souvik, Madhurjya, and Himanshu. We all went to IIIT Allahabad together (Batch of 2015) and spent a few semesters attending a lot of hackathons. During the process, we made some cool shit and a lot of memories and – all in all, had a great time (and some horrible nights :P).
Coming to the specific roles, generally, I handle the design and Madhurjya plays around with React to give life to my designs (and sometimes rewrite my ugly code). Himanshu takes care of the backend, the software architecture and integrations. Souvik’s project manager whose only job is to make sure that the team doesn’t implode.
Q. You guys have had the same team for hackathons for quite a long time. How much do you think bringing together a "right" team is important for a hackathon?
Abhishek: Really important. There are two aspects to building a team in my opinion. First, have people with a complementary skill set so that you can build an all-round product. Ideally, your team should have a designer, a front end dev, a backend dev and someone with good product knowledge and communication skills who can refine and pitch the idea. These could be different persons or a combination. For example. In our team, I am normally the designer and front end dev.
Secondly, I feel it’s also important to have people in your team who share the same skillset as you (or have at least some idea) so that whenever you’re stuck you can ask for help from your fellow team members. Himanshu and Madhurjya used to help me in frontend debugging (because I write shitty code). Also, Madhurjya used to give me design inputs.
Himanshu: Apart from “skillset” and “workflow”, we were close friends and have developed great trust and respect for each other which I feel is the ingredient of the right team. We always had an idea what one of us might need/be thinking about in any case and were nearly predictable in terms of how we will function during the hackathons. Over the years, the coordination was just obvious. We didn’t have to make the same push as the first hackathon.
As Abhishek usually says, “A team that stays together, slays together”, and we were there.
Souvik: If the intention is to just have a good time, I think it’s better to team up with strangers; but if winning something’s the objective, then obviously it’s much better to have people on your team who know different parts of the tech stack.
Madhurjya: A right team is made from quite a few factors such as different types of skill sets (design, frontend, backend), having open ears for one another. One of the important reasons why we made a good team was that we were good friends in and outside the hackathons.
Abhishek: After registering for a hackathon, we always promise that we shall meet and brainstorm ideas. Although we do meet, 100% of the time we end up goofing around on silly ideas with no tangible outcomes. So it’s mostly on our way to the hackathon venue or during the first few hours when we decide what to build. The next few hours are mostly spent in speccing out the features and dividing the initial work amongst ourselves.
Himanshu: I’d still want to have those goofing-around-silly-discussions because they were really fun. Although there were no immediate outcomes, discarding a lot of ideas helped to figure out what stuff we care about building and what we don’t care about. We bonded well and tried to develop our own “authentic” taste about what is a cool idea to work on together.
Souvik: Zero prep every time. 😎
Madhurjya: We tried brainstorming a lot before the hackathons when we first started. Later on, we gave up since all of the brainstormings didn’t produce any conclusions. Sometimes, we started with some inspiration from sources like ProductHunt, TechCrunch, YourStory, etc. and In the end, went for ideas that we could relate to which ultimately helped us do well.
Q. What was the most treasured hackathon of your team? What was your strategy and idea for the project? Is there something you would do differently if you had to do it all over again?
Abhishek : For me, it has to be Hack in the North 2.0. It was my first-ever hackathon and the first one for sudo code. It was almost 3 years ago, so I don’t really recall the strategy, to be honest. We created a small utility called Moodmonk , which basically ran sentiment analysis on voice to detect your mood and suggest solutions. Coming to doing things differently, I would probably not choose Himanshu in our team. Just kidding :P
Himanshu: For me, HINT 3.0 was a great one. This was the time when Consensys was the title sponsor and we decided to make a blockchain-based app -Aerially.
The app from an implementation point of view floats smart contracts when you are denied boarding a plane and fulfills the contract when other airlines give you a seat.
The strategy was simple - Sharma + Pegu would take care of design + frontend, Souvik would take care of backend + interfacing + any viz required, I decided to implement the blockchain part.
The best part here was the learning curve from being clueless about how smart contract works to make it work flawlessly overnight. This was long after I was tired of writing ReST APIs and wanted to make something different.
In case I had to do something differently, I would have asked for help more often. Ashoka Finley (one of the judges) helped us a lot with technical challenges we didn’t know about. But I wasted a lot of time being hesitant.
Souvik: Any of the ones where Himanshu didn’t fart in people’s faces.
The strategy was that Himanshu wouldn’t fart - especially in someone’s face.
If we had to do something differently, I would ask Himanshu not to fart in anyone’s face.
Madhurjya: There were many moments I treasure, from traveling to eating together. Discussing ideas for the upcoming hackathon which leads to random truth and dare sessions :p.
Himanshu: Via is another hackathon project I personally liked. We built it during HackInOut 2018, Bangalore. It was a web-app made for mobile which tracked the quality of the road using motion sensors on your phone.
For me, things that gave a feel about “Oh shit, this seems impossible to do” till the very end and then you work your ass off to make it happen (“surprise, it worked”) is a great experience.
This in recent times had been one of them where we had a tough time to figure out how we can judge road conditions from the motion sensor when the sensor has noise on its own. However, some fundamental concepts learned for exams - thresholding, high-pass filters, correlation theory - helped us figure it out.
Although we didn’t win here but felt accomplished from the experience + the trip experience we get from attending hackathons in another city.
Souvik: Any project where we had a clue of what the end product would look like was more fun. I think Dexter was the one where we were the most in control. Plus it helped that the rest of the projects at that hackathon sucked, so we won. 🙂
Madhurjya: In my opinion, Aerially is one of the most unique ideas we came up with together.
Q. What is the difference between a Hackathon project and a production-ready product in your opinion?
Abhishek: I approach the hackathon projects from a demo point of view. You work on bare minimum features and try to put out a Proof of Concept. “If it’s good enough for a demo, ship it.” On the other hand, production-ready projects are very different in the sense that you need to carefully look at them from scalability and security point of view in addition to taking care of all possible use cases.
Himanshu: Both are way too different. This was a very tough lesson for me and was one of the reasons I stressed others out during the demo. Being someone who usually writes backend code, I always wanted things to be functional and never ever wanted to compromise on code-quality (at least for the code which passed by eyes). (The definition of quality changed over time).
However, I realized that hardly anyone cared if my method is elegant, or I have the best engineering practices in place. There were very very few cases when the judge was interested in the software architecture/software design part of the hack.
It’s certainly very important for a real-world product and cannot be compromised. However, your due diligence again depends on what stage the product is in - beta, early adoption (aiming fast iterations), large adoption (aiming stability and scaling).
TLDR; If the outcome isn’t working, none of it matters - be it a project or product.
Souvik: No difference. Production-ready from the start. Himanshu writes the tests. 😛
Madhurjya: Hackathons have a much shorter time frame compared to production-ready projects. In hackathon projects, there is no good file structure, no tests, etc.
Q. For many people, participating in their first hackathon can be intimidating. What would you tell those people?
Abhishek: You don’t need to know everything before participating in your first hackathon. Just take a leap of faith and jump right in. You don’t need to have a kickass idea or be a know it all person. If you are a couple of friends thinking to solve a small problem, that’s more than enough to enter a hackathon. Normally, there’s enough mentorship and time available in a hackathon to figure and do stuff on your own. That’s also the best way to learn stuff in my opinion, pick a language/framework, decide on a use case and just search around – “How do X in Y language” and repeat.
Moreover, the demo didn’t present well (didn’t know how to extend display :P), the time-slot was over and my mic was cut-off right when I was speaking (time’s up!). Consider all happening at your first hackathon when you’re in the first year.
But that’s how it started. You didn’t run the first time you tried to walk.
Souvik: Have no expectations of winning, and go with the sole intention of getting as many stickers as you can.
Madhurjya: Hackathons can be quite useful for people who want to start software/product development. For the first few hackathons, I only learned how to use an API from 3rd party sources or make a simple one myself. To a beginner, it is one for the best to get into development.
Abhishek: Hack in the North will always hold a special place in my heart since it was my first ever hackathon. Over the different editions, I have learned a lot about creating products and met amazing people – Thanks to HINT. The biggest takeaway for me is to just focus on creating kickass stuff and having fun, everything else will automatically fall in place.
Himanshu: HINT has been one of the best experiences I had in my college so far. The biggest takeaway was meeting not just amazing, but truly great people and learning about how to do stuff IRL, with a team.
Kudos and thanks to Team HINT over the years for making it all happen.
Souvik: HINT has always been one of the more fun hackathons and it’s gotten better each year. The only thing I don’t like about it is that the acronym should be HITN.
Madhurjya: HINT has contributed a lot to my software dev journey. The organizers do an awesome job to keep the culture alive. Everyone should at least try to participate in HINT.