For a long time I was wondering about attending some Hackathon. I didn’t delay it into action when my good friend told me about one in their bank! With a long background in developing software for embedded systems, I was arming myself with web and mobile applications development. I had experience of developing platforms for Samsung and Nokia mobile phones for considerable amount of time which let me borrow some experience of building team and handling the pressure.
RBS have developed banking APIs as a sandbox for developers for the hackathon. With appropriate registration, one should be able to use these APIs after the hackathon. These APIs provided dummy data and adequate enough to support developing a serious application. APIs offered functionality for machine learning, banking services and many more. With those features, one would be easily confused with options for developing the application. In addition Josh Long(@starbuxman) made some talk on Java Spring, it was over the head extra bouncer for a C programmer me, and scouted to kill someone using emacs. Being sheer minority, I immediately closed my vim sessions. 95 participants with 25 teams set the APIs to best of its use. Just before they announcing the result, there was a bonus session of meditation from hearfulness.org.
Experience at hackathon was a very good learning and I felt it is something worth sharing. I hope that few might be inspired to take it up.
- This is a time bound event with a well defined frame of rules. Understand the rules and strictly adhere to it.
- It is a high pressure game if you want to WIN. You’ll have about 20% of total time to think about the solution. Best way to overcome the anxiety is to cut down your expectation.
- Understand the relevance of the hackathon early on. In this case it was easy since we knew the solution had to be on banking.
- Forming a team is important and identify exact roles and responsibilities. This is the essence of leadership and younger the team better this is observed.
- One has to develop “WORKING PROTOTYPE”. Few had developed a hard-coded solution instead of the real one. However it clearly showed their solution towards the problem they had highlighted. Judges don’t see your code and architecture.
- You’ll certainly meet new interesting energy pills who are smart and committed to make the world better place to live.
- Your presentation should be crisp and neat. Spend about 20-30% of the time for timing the presentation. This is very important.
- show the problem in least possible words and with numbers.
- spend most of the time showing the demonstration with a clear emphasis on how you are solving the problem.
- emphasise on the uniqueness of your solution in the hackathon itself.
RBS was courteous letting us team up. We formed a team then and there. In my team there were two engineers churning numbers from the Internet aiding our topic and I was the programmer and bringing up the demo. We won a special award by Fujitsu and it was exhilarating.
People at RBS had arranged this fantastically. All the way from food till the last drop of water it was well planned out. Certainly a big big congratulations to their team. They had many experts flown all the way from UK. Alan Lockhart had boatload of patience to talk with ‘everyone’ and record video interviews by asking the same questions. He was very determined to study the experience at the hackathon and take measures for next one. Needless to say that this is an experience to relish until the next time!