Prior to heading out to MHacks I envisioned having the time to catch up on some tech and non-tech reading over the course of the event. However, this was not to be.

(And no, I’m not disappointed in the slightest that I was occupied the entire time)

I spent a majority of my time helping and mentoring teams participating in the event. I had volunteered to answer any web development related questions. Here are some of the problems I helped solve and technical concepts I explained:

  • How to architect a website that used in-browser video conferencing as a key component. I suggested using WebRTC as it is something that I’ve used in the past. The team chose to use the excellent PeerJS library as an abstraction over WebRTC.
  • How Ajax + callbacks work in JavaScript. The team’s algorithm needed nested callbacks (3 levels of nesting if I recall correctly) because of dependency issues, and the phrase “callback hell” did come up.
  • Given a set of documents, how do you determine, for a particular document, what are the similar documents? This is the problem of semantic similarity. I also explained some basic NLP concepts to the team.
  • How to create a website so that it has a responsive design. My suggestion was to use Bootstrap (I love this framework) and have it do the almost all the heavy lifting.
  • How to use Flask to build backends that are not coupled to the frontend (web v.s. text message)

This was probably the most mentoring I’ve ever done at a hackathon. It was a great experience, and I would definitely do it again.



(All my MHacks posts have been terse because I’ve been either very busy or tired)

Helped and mentored teams at MHacks until 3.00am on the 13th. I was exhausted by the time I got back to the hotel.

We got back to the venue around 10:30am and I spent the rest of the day in final judging. It was lots of fun walking around and watching teams present their projects. There were a lot of very cool and impressive hacks.

Overall, MHacks was a phenomenal experience. I’m very happy that I got a chance to be a part of it.


So, you want to win a hackathon?

In the past 3 years I’ve taken part in 11 hackathons. Of these, I’ve won 4 and have reached the finals in 2. Here are a few things that I’ve observed that I feel should increase your chances of winning a hackathon:

Cool tech does not always equate to a cool product: Regardless of how awesome your tech is, if you don’t have a great product you’re probably not going to win. Use the clever algorithm you came up with or the sweet new tech stack you’ve invented in a product or application that other people can use and love. For example:

DON’T do this: We solved the P v.s. NP problem and then solved the graph coloring problem.

DO this: We solved the P v.s. NP problem and used that to create an application that determines which of your friends you are most likely to start a company with by finding a solution to the graph coloring problem.

That was a pretty bad example, but hopefully I was able to get my point across.

Respect the demo: The demo is the most important part of a hackathon. This is where you convince the judges, in 2 or 3 minutes, that you spent the last 18 to 24 hours creating a product that is the best thing since sliced bread. Make sure you practice what you’re going to be showing the judges! Having a well thought out demo is key to winning a hackathon. Focus on the main features of your product, why it is awesome and why people would want to use it. Since time is limited try to show the most important and/or impressive features of your application.

Did I mention you should PRACTICE, PRACTICE, PRACTICE your demo?

Don’t be afraid to ask for help: Most hackathons have employees (of the company organizing the hackathon) being present during the event as mentors for the competing teams. Don’t be afraid to ask them for help. These employees are an excellent source of knowledge and you should always reach out to them anytime you’re stuck on a nasty bug, can’t figure out how to use a new technology or library etc. Since hackathons give you limited time to work on your product it makes sense to get rid of roadblocks quickly. Of course, make sure you spend some time trying to solve your problem on your own first before turning to the mentors for help.

Try to make your product look pretty: Having a product that is polished and looks good is key to winning a hackathon in my opinion. Make sure you allocate some time to work on the UI and UX of your product. If your team lacks someone with design skills, or you’re simply running short on time, use something like Twitter Bootstrap or jQuery UI to add polish to your application.

Again, these are just my personal observations and opinions. Adhering to them in no way guarantees you a win.

2012: Year in review

2012 was a great year for me for 3 reasons: The world didn’t end. 4 Hackathon victories: 3rd prize at Greylock, an award at an internal hackday at LinkedIn, 1st prize at the Facebook Hackathon at UIUC and 2nd prize at the Facebook Hackathon finals…

2012 was a great year for me for 3 reasons:

  1. The world didn’t end.
  2. 4 Hackathon victories: 3rd prize at Greylock, an award at an internal hackday at LinkedIn, 1st prize at the Facebook Hackathon at UIUC and 2nd prize at the Facebook Hackathon finals. We were also one of the finalists for the LinkedIn Intern Hackday 2012.I worked with Sam and Onur on all the hackathons apart from the LinkedIn internal hackday for which I worked with my awesome mentor Jim.I also love how our Computer Vision technology evolved over time for each hack: we started with object tracking using colors (we wore  colored socks on our hands for dance()), next we were able to pull of object tracking within a bounded region (we were able to track a finger in ABSees) and finally for StreetCoders we were able to have a system that didn’t require colored socks or a bounded region!

    I’m extremely proud of what Sam, Onur and I achieved and it was great working with them.

    What didn’t improve though was the quality of our Javascript code :(. Each of our hackathon projects started with us working on the computer vision first. This usually took the most time. Once we were pretty confident that our computer vision components worked locally (no images coming over the network), we started working on the Javascript portions of the code that actually talked to the computer vision servers. It was also at this point that we used to realize that we have 10-12 hours to build a majority of our application. This scramble to the finish line usually ended up with us having Javascript code that is functional but littered with code smells. Our overall tiredness towards the end didn’t help either. Oh well.

  3. I got an opportunity to intern at an awesome company. My Summer at LinkedIn was phenomenal.
  4. There was a new addition to my dog

Looking forward to a great 2013.