Note: This article was written for the Computer Science students at IIT Bombay. I thought it might be useful for a wider audience, so I published it here on my blog. I hope you enjoy it!

This article is a primer on hackathons - what they are, what participating in one will involve, and what you can do to maximize your chances of winning. Obviously, there is no sure-shot way to win a hackathon. But there are certain things you can do to stand out from the competition. In this article, I’ll enumerate these ways and explain why they help. I’d like to apologize in advance if this article gets too long. There’s a lot to talk about, after all :) If you’re short on time, take a look at the Summary section down below.

Firstly: what are hackathons, and why should you take part in one?

What is a hackthon?

A typical hackathon takes place over a span of 24 or 48 hours. You compete either alone or as part of a team, and build “something”. Typically there is a lot of leeway in what that “something” is. Most hackathons have a theme. Some restrict the “something” to be a mobile app, or maybe a web app. Others go further and provide you with an API that you must make use of when making your “something”. Once the 24 (or 48) hours are over, you are expected to stand in front of a panel of judges and present your “something”. Exactly how long you get to speak depends. Some hackathons allow you only 90 seconds. Others are kinder and give you a whole 3 minutes.

(As you can see, you don’t get much time on an absolute level. We’ll talk about the presentation bit later.)

So that’s what a hackathon is, broadly. Why would you want to take part in one? Who wants to stay awake for nearly 24 hours, anyway?

Why take part in one?

An obvious couple of reasons to take part in hackathons is because

1. They offer cool prizes, and everyone likes free stuff

2. Winning a hackathon is a nice résumé point, and everyone wants a nice résumé :)

Beyond these straightforward reasons, there are a few deeper ones.

1. Learning: Hackathons are a fantastic way to pick up a new technology or framework. Note, however, that this article is my personal account, interspersed with strategies for winning corporate-sponsored hackathons. As a result, I won’t really talk about the learning aspect too much, which anyway is more pronounced in hackathons conducted by college clubs, like the ones IIT Bombay’s WNCC conducts.

2. High-profile hackathons typically have recruiters and technical people from companies hanging around. They chat with teams, keep a close eye on the teams they like and report back to their bosses if they are particularly impressed by what they see. In other words: networking. Hackathons are a great place to get noticed, and by ‘noticed’ I mean offers for internships and possibly jobs. For example, the team that made Kapi (which I’ll talk about later) were contacted for summer internships by the Microsoft people.

3. From the perspective of a technical company, hackathons are a fertile source for interesting ideas. It’s common for companies to either overtly or secretly use some of the better ideas from a hackathon as pre-prototypes for products. Again: it’s easy to get noticed if you have a really good idea.

Hopefully this was enough to convince you. Now, who am I and why do I feel qualified to give advice on this topic?

Who am I?

I’m Rohan Prinja, a final-year CSE B. Tech student. Over the last three years, I’ve participated in four hackathons (and two ideathons, which I’ll also briefly discuss), and seen my friends participate in others. Out of the four hackathons, our team won top positions in all four. Out of the two ideathons, our team won top positions in both.

With the exception of one hackathon, all of these were only college-level events. Even so, my friends and I were able to observe a lot of things about hackathon culture that I’m summarizing in this article. This is by no means an exhaustive list and there are other people in the department who can tell you many more insightful things about hackathons. This article is simply my attempt.

In the next section, I’ll talk about my various hackathon experiences, and then list some observations. This section might be a little long. If you’re short on time, skim the paragraphs and focus on the numbered lists.

Experiences

Yahoo! Hack Hyderabad

My first brush with the hackathon world was in the summer of my second year. I was interning at Chronus, a SAAS company in Chennai that wrote mentoring software. One evening, when I was checking my mail, I saw an announcement posted on (I think) the WNCC group. Yahoo! was conducting an all-India hackathon in Hyderabad, and luckily enough, it was being held in the summer after intern got over. To sign up, I had to solve a couple of questions on Hackerrank. I did so and promptly forgot about it.

A couple of weeks later, I received an email saying I was selected. Cool, I thought. I returned home from my intern, lazed around for a week, and then travelled to Hyderabad.

The hackathon was held in the ballroom of the Westin in Hyderabad’s Raheja IT Tech park. It opened with a few talks from Yahoo!’s outreach people. Then they basically set us free and told us they were going to conduct training sessions throughout the day and we were welcome to drop in. I sat in a couple of them, but didn’t really find them useful. They neither taught me anything really cool nor gave me any ideas. More on this later.

At this point, we were roughly 2 hours into the hackathon, and I had no idea, and no team either.

It was then that I bumped into a guy named Sagar Pandey. Sagar was a second-year student like me, and he too had no team. He told me he had a couple of ideas, and we agreed to team up. We also pulled in two more people, let’s call them B and C. B was also a second-year student, and C was a software engineer in his early 20s at DRDO. We traded ideas back and forth until we settled on one of Sagar’s original ideas: build a mobile webapp that told a train traveler in real-time how far away the next station is, given just the PNR number. A simple, do-able idea that nevertheless was very useful.

Then we began to code. Two years later, the exact details are a blur, but I do remember having more fun in those 24 hours than I had in my entire internship combined. We coded until we grew dazed and tired. We took turns staggering over to one of the side rooms and falling asleep. When it was my turn to sleep, the seats were all occupied, so I laid down on the floor and slept. I was woken up the next morning by the smell of breakfast.

For the most part, we all coded together, although for some subtasks we would split into two groups. Periodically, B would roam around and talk to other teams or the Yahoo! devs, drumming up interest in our idea and seeking feedback. This would prove to be very important the next day.

We finished our hack well ahead of time. We then spent the remaining two hours or so discussing in excruciating detail the presentation we would give. We had only 90 seconds, so we had to make an impact. Our presenter, Sagar, was visibly nervous - we all were, for that matter. The presentation, however, was a rousing success. While Sagar presented, I actually heard some of the Yahoo! devs cheering for us! I realised later that B had anticipated that it would be hard to stand out and had pre-emptively chatted them up.

With the presentations over, the judges retreated to a separate room to deliberate. We ate a heavy lunch and returned to the ballroom once the results were in. Much to our surprise, we won the Best Technical Hack award for our use of JSONP to scrape from a site that itself scraped from IRCTC.

The aftermath was unreal. We had people coming up to us, introducing themselves and trading contact numbers - including a software engineer who worked at Google Hyderabad, and a journalist. There were the obligatory photographs: us standing awkwardly with silly, plastered-on grins as the shock of it all washed over us. None of us had had any experience with this sort of thing. But somehow, we had won.

Observations

Today, when I look back on that experience, I realise that we had done many things well. And we had also done many things incorrectly, things that would not become apparent until I participated in other hackathons and messed up.

For now, here are the things that made our hack a success, as evidenced by this hackathon:

1. Picking a good idea - this is universal across all hackathons. If your idea is good, you’ve won half the battle.

2. Having a good UI - this would be demonstrated much more dramatically in a later hackathon, but even so, this hackathon taught me the importance of having a good-looking final demo. Your team needs to stand out from among a few dozen others, after all.

3. Get the devs/organizers on your side - walk around and talk to people. Get their feedback. Discuss with judges, if possible: people feel more involved in an idea when they have contributed to it in some small way. Make sure they know your name (this ties back to point 2 - you need to be more than just another faceless team trying to sell your idea to the judges).

4. Use the right tools - this is mostly applicable to hackathons conducted by companies - more on this later. You are expected to use their products and software. It always works in your favour. In our case, we used some Yahoo! technologies - I don’t exactly recall which, but I think we used YQL.

5. Avoid in-hackathon training sessions - even though point 4 is crucial, 24 hours isn’t all that much time. A significant chunk of this time will be spent discussing refinements to your idea, discussing fallback plans for when some part of your idea doesn’t pan out, figuring out how to deliver a really good presentation, and yeah, sleeping :) So save your time, and ditch these sessions. Instead, make sure that you already have a working knowledge of the technologies you will use, or alternatively, grab one of the hackathon mentors and ask for help while you’re coding rather than passively sit in a session and take notes.

Yahoo! HackU, IIT Bombay

My next hackathon was another Yahoo! event, this time a university-level event. I was partnered with Anil Shanbhag, Rahul Singhal and Ashwin Paranjpe. To increase our chances of winning, we split into two sub-teams, each working on a single hack. If either of the two hacks would win, we would all claim credit. Rahul and I successfully used this trick later in another event. More on this later.

Anil and I made a dead-simple app: given a search query, we would search through a database of news articles and format the results as an interactive, scrollable timeline of news articles relevant to the query. Ashwin and Rahul made a tagger and recommender for Yahoo! Answers. We won second place with the timeline idea. The judges cited the “beautiful user interface” as one of the reasons for our win. This kind of amused me, because the timeline library we used did all of that. All we did was connect together a few libraries - in our case, Apache Solr, Python NLTK (for news article summarization) and the timeline JS library.

Observations

1. Make your hack look pretty - this was already noted before, but it’s so important that I’m going to repeat it. A good UI helps your cause enormously! You may have a strong and novel idea, but if your demo looks ugly or confusing, the judges might not like your hack, or worse, fail to see the point of your hack entirely. Conversely, with a good UI, a not-so-cool idea suddenly looks promising.

2. Do all the heavy lifting beforehand - I was already familiar with the Sinatra frontend framework, having used it in Hack Hyderabad. Anil already knew how to use Apache Solr to scrape news articles, and Python NLTK for summarizing them. We both knew about timeline.js, since we both read Hacker News avidly. The components for our idea were already in place. All we did was connect things together. This wasn’t trivial though, but imagine how much harder it would have been had we not had all this prior knowledge. This idea would appear again in a later hackathon.

Microsoft Code.Fun.Do. 2014: loss

In the beginning of my third year, Jayanth Jaiswal, Rahul, Ved Ratn Dixit and I formed a team to participate in a Microsoft hackathon. Jayanth was interested in using the Kinect to be able to detect mood changes in the user’s face. We would then classify the user as being happy, sad, or angry. Finally, we would recommend music from a pre-tagged set of tracks to match the classified mood.

The idea was good, but a number of things went wrong. Firstly, I could not contribute to the same extent as my teammates - I was bone-tired from a previous course assignment and I ended up sleeping through a large segment of the hackathon. Secondly, we spent a lot of time installing the SDKs and IDE (Visual Studio) required to make our app. Thirdly, none of us knew C# either, so we had the dual task of cranking out a workable app with a SDK we were all unfamiliar with, and learning a new language (that admittedly had a reputation for being well-designed and usable).

Somehow, we managed to get a barely-there prototype out. Our demo was passable. Miraculously, we came in fifth. I attribute this to a combination of luck and Jayanth choosing a strong idea to begin with.

This hackathon differed from the last two ones. As mentioned above, it yielded a laundry list of things not to do when doing a hackathon. Namely:

1. Have an inactive team member (me, in this case).
2. Be unfamiliar with the SDK you’re using.
3. Do not have the required IDEs and SDKs pre-installed.
4. Do not bother to estimate the difficulty of your idea’s implementation.

An unexpected side-effect of the hackathon, though, was that I learned more from it than from both of the two previous hackathons combined. After all, the observations listed for the two Yahoo! hackathons are to some extent common sense. They are not fundamental insights into hackathon culture or into the way companies think.

But this time, we were due to learn some very valuable lessons.

The winning hack in this hackathon was Kapi, written by Manish Goregaokar, Ranveer Aggarwal, Aditya Nambiar and Mihir Kulkarni. Their hack had a dead-simple premise: a note-taking app with in-built support for mathematical equations. The motivation for the app was straightforward:

1. Some people - especially programmers - are more comfortable taking notes on a laptop than on paper

2. Note-taking is hard for physics and maths. We have to use crude representations of mathematical formulae, like writing “x^2 + y^2” (which looks ugly) or resort to using Latex.

3. Latex is great, but it’s complicated enough that the overhead of juggling Latex and taking notes while the prof speaks in class makes it unusable in real-time.

Kapi sidestepped this problem by combining a Latex rendering engine with a simple Notepad-style app. It was an elegant solution to a widely-faced problem. The user simply had to type in the old, “crude” style and the app would automatically convert it to beautifully rendered Latex.

Our team’s first reaction to finding out that these guys had won was of shock: “Our idea was surely better, right?”, we thought. We trooped back to our hostel rooms, crestfallen. The last 24 hours seemed kind of worthless. Fifth place was essentially a consolation prize, especially given the small number of teams participating. This hackathon was essentially a failure.

This defeat would however prove to be a blessing in disguise. It’s easy to analyze a couple of successes and derive some sort of satisfaction, thinking you’ve understood the way a competition works. But then something like this comes along and you realise you have a lot to learn. Our poor showing proved that we still had a lot to learn about securing a top position in a hackathon like Code.Fun.Do.

So… what went wrong?

Microsoft Code.Fun.Do. 2015: victory

When the 2015 edition of Microsoft’s Code.Fun.Do. began to draw close, Rahul and I sat together and brainstormed heavily. We were acutely aware that we had messed up last year. Too many things had gone wrong, and more importantly, Manish and co. had done many, many things right. We were in the final semester of our final year and there was no scope for error now. We had to win. And to win, we had to do every single thing the right way.

A prerequisite for doing things the right way is knowing what the right way is.

What did Manish’s team do right? To answer this, we pored over their app. We picked it apart, compared it to our own, and asked ourselves just why they won and we didn’t. And along the way, we learned a lot. Without any further fanfare, here is what the Kapi team did right:

1. They had a strong idea that solved a long-standing and widely-encountered problem. Note-taking is so ubiquitous. Every one does it, in some form or the other.

2. They delivered a complete app. That is, an app that could be uploaded to the Windows 8 App Store with almost no polishing required. This was crucial to their victory. I don’t recall clearly, but the Kapi team were one of the few teams - maybe the only team - to have done so.

   Why was this crucial? Step back for a minute and imagine you are a Microsoft evangelist. You have been allocated a sizeable budget by your boss and have been asked to supervise a hackathon at IIT Bombay. Hackathons always cost the organizers a decent amount of money. You have to pay the mentors, you have to pay the caterers, you have to pay the judges and you have to pay the training session speakers. All that money down the drain. What do you expect to get out of this hackathon?

   Kapi’s win made it clear that what Microsoft wanted were complete products. It’s no secret that the Windows App Store is in a really bad state. It lacks many well-known apps, and even worse, it is poorly organized. If you have a Windows 8 or 10 laptop, try doing a search for ‘Facebook’ on the Windows App Store. Facebook is insanely popular, as we all know. Yet the official Facebook app for Windows turns up maybe 10th or 11th in the list, behind a roster of fake apps and spammy-looking Facebook helper apps. Unsurprisingly, Microsoft has been very vocal getting more developers interested in the App Store. It stands to reason that in a hackathon, they would give disproportionately higher preference to a finished, polished product over a hacky-looking, rough-around-the-edges prototype.

   It’s a little ironic that this is how things are, given that in theory hackathons are supposed to be primarily about idea generation and prototyping. But when competition is fierce, this is what you get. But I digress.

3. Kapi had the look and feel of a real Microsoft app. This, as Manish explained to me, was not really consciously enforced - it simply came about as a result of them copy-pasting example code from the MSDN docs :) Either way, the point was the Kapi team followed best practices. Again, very important. We realised that we wanted an app that was instantly recognisable as a “Windows Store” app. This would boost our chances at winning first place.

4. They had a fairly minimal GUI. A couple of buttons for loading and saving, and another couple of buttons for inserting various mathematical fragments, like square roots or exponents. A minimal GUI is great, because it is both a selling point for your app (“Look, judges, only three/four buttons! Anyone can use this!”) and it also means that your demo can proceed much faster. Hackathon judges are humans after all, and their eyes tend to glaze over when confronted with monstrously complicated GUIs. Bottom line: simplicity helps in hackathon demos.

5. An extremely important point - one that’s been pointed out already, in fact - in Kapi’s favour was that the Latex engine had been written long ago (by Manish, for a side project). Once again, an example of doing the heavy lifting beforehand. This is a strong argument in favour of having many side projects in your arsenal of code - you never know when some code you threw together in a hurry one boring afternoon months in the past could turn out to be exactly what your app needs. In fact, it’s not a bad idea to attempt to structure your hack ideas around code you’ve written previously - provided of course that the idea itself is strong.

6. The app had a memorable name. Kapi, according to Ranveer, was a deliberate mispronunciation of “copy”. It’s a silly, funny and easy-to-remember name. It’s also short enough that the files saved by Kapi could have a “.kapi” extension. This might seem like a really trivial thing, but it’s ultimately an exercise in branding. Having a unique, clever name and a separate file extension is a really inexpensive way for you to give your app the feel of being a real-world product. This in turn sets you apart from other hackathon entries that are just prototypes with no name.

7. Kapi supported sharing your files on social media. Whatever your own personal opinions are on social networks (I personally believe there’s too many of them around), they are ubiquitous today. It therefore can help to shoehorn in a social network component to your app.

8. (This is related to point 2.) Kapi had a splash screen. Once again, a low-effort time investment that can give any app a polished feel. This is a specific instance of a more broad rule: get the small things right, too. Computer science students sometimes look down on making visual enhancements because they perceive them as being trivial or uncomplicated (“kar sakte hain, kya badi baat hai?”). The truth is, each small feature that will make your hack better is worth implementing - especially when the time required to do so is so little (Visual Studio makes adding a splash screen to a project a matter of a couple of mouse clicks).

As you can see, the Kapi guys did a lot of things right. Somewhat hilariously, when I pointed these things out to Manish and Ranveer, their responses were more or less “really? We basically just sort of winged it!”. Whether this was an example of modesty or simply having a good intuition for what things to do right in a hackathon, it’s clear that their win was not a fluke.

Putting these lessons to use

The 2015 Code.Fun.Do. session was without a doubt the best hackathon experience I’ve ever had. Bolstered by the memory of our sub-par performance in 2014 and armed with the lessons learned from analysing Kapi’s win, we charged headfirst into the 2015 edition.

Our idea was in place well before the hackathon even began. In fact, we had been hashing out various ideas for nearly a week prior to the start date. Although we threw many ideas around, the idea we finally settled on was quite strong. Sometime in the past, I had signed up for a course on Coursera called Interactive Computer Graphics. The course was taught by Takeo Igarashi, a professor at the University of Tokyo whose research interests include sketching, modelling and human interfaces. It was a somewhat atypical Coursera course. Most courses on Coursera are structured around a syllabus of high-level topics broken down into manageable video lectures. In a sense, these courses try to mimic the structure of a traditional university course. This is not a bad thing, but in my opinion the video lecture format can be used for so much more than just replicating the traditional classroom style. The Interactive Computer Graphics course was a pleasant departure from this pattern. In each video lecture, Prof Igarashi discussed a single research paper that he was involved in. This format had two advantages: it exposed students to a wide variety of papers that spanned many sub-fields in the large and fascinating field of graphics, and each lecture was very self-contained.

In of the video lectures, Prof Igarashi presented a paper that explained how to rigidly deform a given input shape by triangulating it and minimising the sum of two energy functions on the triangulation. The USP of this method was that it meant that anyone could create convincing animations with very little effort. Rahul, Ved, Mayank and I were fascinated with this idea (Mayank Meghwanshi had joined our team since Jayanth had graduated last semester). It was a very cool idea, with many use cases.

We got started on our app well before time. We planned to market it as “an animation app for people who have no animation experience”. In the vein of Kapi, it would have a clean, minimal GUI and resemble an app that had the Metro look and feel. It would support saving and loading incomplete work, and exporting and sharing of the animations (in GIF format, which is ubiquitous on all devices and browsers). We split into two sub-teams. Rahul and I worked on the UI, and Mayank and Ved worked on the actual animation logic. By the team the hackathon kicked off, a sizeable chunk of our app was already done.

Side note: many hackathons require you to write all of your code only after the hackathon begins. This is a rule that is somewhat difficult to enforce, further complicated by the fact that it’s almost impossible to have a hack with code written entirely from scratch. If your hack depends on an open-source library, aren’t you in a sense using code written before the hackathon began? In any case, you can save a lot of time if you begin work on your hack before the hackathon formally starts.

The actual hackathon went smoothly. We made sure to seek out one of the judges, mid-way, and sell our idea to him. We finished our coding well ahead of time, even after adding little touches like a nice UI and a splash screen. The next morning, we rehearsed our demo thoroughly. We made a brief presentation and Ved screen-recorded himself creating some animations with our app and using the other app functions, like GIF exporting. The demo was great too. In short, we ticked off all the boxes we had planned to. Satisfyingly enough, we won first place, which vindicated our analysis and planning!

In the next section, I talk about what makes an idea good for a hackathon.

What makes an idea good?

1. A good idea scratches an itch.

   Let’s look at the apps discussed above.

   a. Kapi solved the problem of not being able to take notes in class on a laptop when the subject matter involves mathematical symbols.

   b. Dashpad, our animation app, solved the problem of not being to create a simple animation in a couple of minutes.

   c. The timeline app solved the problem of not being able to interactively browse news archives for reports specific to a certain person or event.

   d. The PNR app solved the problem of not knowing exactly how far away the next station is when you’re travelling by Indian trains.

   So choose a specific, common problem that is universally relatable. Ask yourself what inefficiences or annoyances you experience frequently that can be solved with code. Pick one and try to solve it with a specific set of technologies you are reasonably familiar with.

   By the way, notice how I left the Kinect face tracking app out of the above list. This was deliberate: does the idea really solve an itch? Probably, but certainly not a very common one. This, I later realised, was another reason we didn’t do well in that hackathon.

2. A good idea takes very little effort to communicate.

   It’s tempting to think big. As programmers, we tend to be drawn to creating ambitious, great new things. The problem with this is that despite all your planning and designing and coding you will ultimately receive a small time slot in which you have to sell your hack to a group of judges who have already viewed many hacks before yours and have many more waiting to be seen. If your idea is really complicated and as a result difficult to communicate succinctly, your hack does not stand out - and you lose a chance at one of the top spots. Notice how each of the apps discussed above can be summed up in a line or two.

3. A good idea is doable in 24 hours.

   This point is related to the previous one. A side effect of choosing a simple problem to solve is that you have less code to write. Of course, there is a trade-off between simplicity and impact. You have to deliver a good hack in only 24 hours, but it should be non-trivial. The ability to accurately estimate the minimum amount of effort expected from you in a hackathon comes from experience. Take part in small, college-club-level hackathons. Talk to other teams once the hackathon is well underway (as opposed to the very beginning, when many teams are invariably still settling on their ideas) to get a feel for what other people are working on. Accordingly, dynamically vary your own hack’s goals by adding in more features or slightly altering your course of action. If you find yourself finishing your coding, polishing and demo preparation well before the 24 or 48 hours are over, ask yourself if you have done enough.

In the next section, I summarise the observations listed thus far.

Summary

This is the TL;DR section. Here, I list down all the observations and tips for doing well in a hackathon that were scattered throughout the above text. Advice given without any context or explanation can sometimes be confusing, so please do read the entire article if something isn’t clear.

1. Pick a strong idea (read the above section to see what doing so entails)
2. Make sure you have a good UI.
3. Talk to the mentors/judges/organizers and try to get them to notice you well before the demo.
4. Use tools and technologies specific to the company organizing the hackathon.
5. Avoid in-hackathon training sessions/lectures.
6. Try to deliver a complete, self-contained product.
7. Choose a nice name for your hack.
8. Don’t leave out the small things, like having a splash screen.
9. Make your GUI minimal and unobtrusive.
10. Think long and hard about your demo. Make it impactful and concise.
11. Do the heavy lifting beforehand.
12. Hit the ground running. You should already have a good idea and some working skeleton code when the event begins.
13. Try to game the system in a legit way, like we did by splitting into sub-teams.

In the next section, I briefly discuss the ideathons as well, if only because they paralleled the learnings from the hackathons I took part in.

Ideathons

I mentioned in passing that I also took part in two ideathons. From a learning point of view, these ideathons didn’t really teach me anything new - if anything, they only vindicated some of the observations I had made from other hackathons.

Samsung Intern App Design

The first ideathon was when I interned at Samsung. We were divided into teams of four to five interns, and we had to propose ideas (and not necessarily implement them), as part of an app design competition. After much discussion, we settled on two ideas (just like my team did for the Yahoo! HackU event). The first was an expense calculator app for groups of people travelling abroad. The second was a subtitle detection app that would search a list of websites for subtitles, given a media file, and perform very rudimentary sound analysis to determine if the subtitle file matched the file. Very trivial ideas, but somehow we won first place. One reason I suspect we won was because Samsung was probably looking for implementable ideas. The other teams proposed really cool but somewhat open ideas that at the very least would require a significant amount of research and/or software engineering to bring to reality. Our ideas by contrast were fairly straightforward.

Samsung VR Appathon

The second ideathon happened this semester. Samsung was conducting a virtual reality/augmented reality themed “appathon”, in which the first stage was to propose ideas and the second stage would be for selected teams to implement the ideas they proposed. Once again, we split up. Shubham Mehta and I proposed a VR app for students to learn chemistry by visualising chemical reactions in a virtual world, using a Samsung Gear VR and some sort of arm movement tracker, like the Myo armband. Rahul and Mayank proposed an app for an AR headset that would guide people as they cooked a dish. The chemistry app was selected to participate in the next round, but as all four of us were really busy, we declined to take part.

Conclusions

This article represents pretty much everything I know about doing well in hackathons. I hope you enjoyed reading it, and gained something of value from it.

If you have further questions about this article or just want to say hi, you can reach me at <my first name> DOT <my last name> AT <google’s email service>. Other people who can tell you a lot about hackathons are the people mentioned by name in the article, especially Sagar Pandey (who has since taken part in many hackathons back in his own college, as well other national-level hackathons!), Rahul Singhal (who has also participated in an internal hackathon during his intern at Facebook), Ved Ratn Dixit, Mayank Meghwanshi and Manish Goregaokar.

Follow-up reading

1. The hackathon fast track
2. Lessons learned from Ford’s hackathon
3. Why some companies conduct hackathons, and why they could be harmful.