Learning from My First Hackathon 

Going to your first hackathon is a bit nerve-wracking. It was for me at least. I had absolutely no idea what to expect. It was an awesome experience, one I hope to repeat soon, but next time I want to be able to use what I learnt to help me get the most out of the next opportunity that comes my way.

Zopa, a London-based fintech company were the hosts, and the theme was “How can we make interest rates more interesting?”. I really liked this theme, but not for the reasons you might expect. When I told my friends how I was spending my Friday night and half of my weekend, I got several sympathetic looks and a few raised brows, as if to say “Really? You didn’t have anything better to do?” But that’s why I find it interesting! Most people switch off when you talk about interest rates or finance. It’s such a huge part of modern life and I don’t believe that people are nearly as engaged as they could be in understanding their personal finances. This brings me to…

TIP 1: Don’t be put off by the theme. Instead, see it as an opportunity to learn something new. If it really doesn’t float your boat, you can always attend as a spectator - that way you’re not obliged to stick around.

There was also alcohol involved...

Things kicked off at 5pm. After initial introductions, we were split up into pre-assigned teams. This was a fantastic idea by the organisers and ensured that each team had a mix of different skills. It would have been easy to form a team with my Makers graduate friends and be on familiar ground, but I loved being thrown in the deep end and working with a totally new group of people. It was also my first experience working with much more senior developers. Sure, I felt way out of my depth at points, so I just kept asking questions and at least I know more now than I would have if I hadn’t gone.

TIP 2: Not all contributions are dependent on technical ability. Get stuck in with the brainstorming, share your ideas and be willing to take on any task. I wish I had contributed more to tasks like the presentation. I think there were points when I recognised I wasn’t being productive and should have either taken a break or switched up tasks.

We started brainstorming over dinner and we kept converging on this idea of helping people become savers. We felt that people who wanted to start saving were either struggling to find places to cut back on or were too tempted to spend as soon as they had saved anything. Our idea was to hook up to an Affiliate marketing site like Quidco and take the accumulated savings and invest it in an interest-paying account. The customer would then get notifications when they’d reached particular savings goals and would be asked if they wanted to boost their savings which would encourage them to adopt positive saving habits, rather than spending £100 just to save the 1% they’d get back from Quidco. Well… that was the plan. It didn’t quite work out that way.

TIP 3: Plan well! It was around 11pm when we realised that we wouldn’t be able to access the Quidco API or the API of a similar alternative. We had had our suspicions early on, but these were only confirmed after a lot of researching and by then it was already quite late in the evening. While this wasn’t the end of the world, it probably would have been a good idea to assess whether we were happy to focus on the front-end only and pitch with a non-functional, but super-slick-looking app, or whether it was time to pivot.

There was a lot of this...

We decided to try and build a full stack app based on what we thought the API might return if we had access to it. And we decided to use Rails to get it up and running. This was probably an error to be honest, given I was the only person on the team who had recent experience with it. Luckily, there were people around who were willing to chip in when we did get stuck.

TIP 4: Make use of the expertise in the room. Don’t be afraid to ask your friend in another team for help, and be willing to return the favour. If other companies’ APIs provided, chances are there are also employees from those companies around the room who understand them much better than you do.

About 2 hours before the final whistle, we unfortunately had to bail on all our backend work because we couldn’t get the Monzo API working with our Rails app and as I couldn’t stay for the presentation, we wouldn’t have had any laptops to present from on which the app would work! This comes back to planning well - half the team hadn’t been able to install ruby and run the server from their laptops. We probably should have stuck to a stack which most people were comfortable with.

Team stash hard at work!

All in all, I had an awesome time. I was knackered by the end of it, and gorged on way too much food, but it was a fantastic experience and I highly recommend going to one if you’ve never been to one before. But before I finish, here is one last tip…

TIP 5: Accept that this is no normal working scenario and EMBRACE IT! Expect to have to make difficult decisions at silly o’clock in the morning when you’re tired and groggy and your brain isn’t be functioning properly anymore, but enjoy it. It’s a  challenge and it’s a laugh. HACKATHONS ARE NOT THE PLACE FOR NORMAL WORKING ROUTINES. For example, usually if I have to make a big decision or if I hit a massive road block, I like to stop what I’m doing and sleep on it before I continue with it. There just isn’t the time for that in a hackathon, and accepting that means you can really start enjoying yourself.