How we ran our first hackathon

We’ve just held our first ever hackathon, and had a great time. Croissants were eaten, beers drunk and (a lot of) documentation was read, culminating in company-wide demos and 3 delighted winners. We’re planning to host a lot more of these, so we took the time to reflect on what went well and what we could do better next time!

Why did we do a hackathon?

Hackathons can deliver some real benefits, on top of being good fun. In our case we wanted to run it for 3 main reasons:

Give our engineering team some creative freedom, outside of their day-to-day job

Let them explore new languages and technologies

Work with people they wouldn’t typically team up with

How did we run it?

We wanted to start simple - and have bigger plans for our next one!

Over the 2 days we kicked things off with a great breakfast for the whole company, with pastries, cereals and fresh coffee to get started on the right foot, full of energy.

Work started for teams of either 1 or 2 engineers. Since many of our employees love coding, we also had a couple of people from both our sales and product teams joining in on their own projects.

Some called it a day as usual at 6pm. Some went all in and were still polishing (or bug squashing) at 2am. Pastries were long gone.

The 10 projects were showcased during an all-hands hackathon demo on the Friday. Beers made an entrance, shortly followed by the first technical issues that mysteriously show up anytime a live demo takes place. Live bug fixes were a crowd favourite (less so for the presenters)!

In the end, 3 projects were rewarded and Andrew (for his real-time game), Rob (for his mobile app) and Aleks (for his sales automation) each got a great prize…

… With BB-8 another crowd favourite!

Playing with front-end real-time tech

Andrew, one of our backend engineers, wanted to work with modern front-end real-time tech like websockets. He thought the hackathon would be a good opportunity to see how Javascript had evolved in the few years since he’d last touched it, and build something interactive that people would have fun playing with.

Andrew started building a multiplayer version of the British game of Dobble, in which players must match 2 symbols. His focus was making it both as real-time as possible (no polling) and allow an unlimited number of players to join a same game.

Things went smoothly - although Andrew realised he’d under-estimated the time it’d take to get the math right to generate sets in which only 1 winning combination was possible. With some time left at the end, he polished his game by adding in sound effects and the logos of some of our vendors!

Andrew quite liked his front-end experience: “Javascript has come a long way since I last did it seriously: the tooling is much better and the language is really nice to use. I definitely plan to do more with it”. He also had a good time playing with event driven PHP framework Aerys.

His main goal was to explore whether these tools could be interesting to help us better understand customer behaviour on our checkout and ultimately increase conversion for our vendors.

Setting up the Javascript required to fire up events from Paddle.js to Google Analytics was straightforward. The hardest part was probably figuring out the format of data that Google Tag Manager expected to make the ecommerce tag work!

Mike was overall quite satisfied by his experiments: “It was really satisfying to see the data appear and to play with the funnels. Next time however I’ll probably do a more funky project that’s less related to work!”

Save time by running SQL queries within Slack

They both shared a same pain: getting a Slack alert at 1am and lacking context to know whether this was a critical problem. Every time an alert would come in, they’d need to start investigating, which took a lot of time (and repetition of manual steps) and wasn’t easy to share back to the team.

Their solution? Build a way for queries to be created within Slack, pulling data from a variety of sources (our database, our data warehouse Periscope…) and bringing in the required context within the Slack channel to make the whole team aware in situ.

The project was built using Go and AWS. Using Slack command API was easier than anticipated, and most of the roadblocks came from figuring out how Go could deal with the complex use case.

They’ve continued working on it after the hackathon, with the goal to let more teams use the tool to answer questions such as “how many fraud transactions did we have today?” or let the customer success team find relevant information about a vendor ID. Making the tool GDPR compatible and prevent personal data from being shared is however the main priority before it can be used.

What’s next?

We’ve learnt a lot in the ops of running a hackathon. Go was a very popular choice, and our engineers mostly chose to tackle vendor-related projects.

We will probably make some changes for our next hackathon, which we intend to run once a quarter. Including the whole company rather than simply the engineering team, setting a theme or getting external companies and vendors to join in are all options we’re thinking about!

When it comes to checkout conversion, the faster the better - but the country of your customers plays a big role. To help you grow revenue internationally we've greatly sped up the response time of our checkout worldwide.