Notes from a hackathon

Imagine you’re a developer, interviewing at a new company. The process consists of filling in a form which outlines why you are the most suited candidate for this particular position and, if you are successful at this stage, you will get an opportunity to deliver a presentation to a hiring manager.

No chance to show your coding style, no pairing, no collaborative working with real “doers” in the organisation. Does this seem like the sort of organisation where you would like to work? These days it’s the norm for any recruitment process for a software delivery team member to include some practical demonstration – a practice that is essential to the EE hiring process.

Yet when companies hire suppliers (which is a much bigger commitment than a single hire), an approach like this is definitely not the norm. Instead they send out an RFP, documents are submitted in response, and managers get to watch vendors present (usually pretty boring!) powerpoint slides. Code is not produced, and the clients don’t get a chance to see how the candidate teams actually work.

So it was refreshing to be involved in a “Hackathon” bid a few weeks ago! A client decided to forgo the usual process and instead invite vendors to send over teams for two days of working with the client to produce working software.

Let the hackathon commence

I was part of the EE team. They gave us a problem, the wifi password, a room, and told us to get cracking. We started by trying to understand the problem. We stuck post-its and whiteboards on the walls and asked various stakeholders hundreds of questions. As the problem became more defined we came up with a proposed solution and began to code. We stuck to proven practices – we had a CI environment, wrote unit tests, and managed our tasks with a sprint board. At the end of two days we presented a basic system complemented by a clickable prototype that demonstrated our vision.

We also attended our competitors’ presentations, and the difference in approaches was surprising. While we organised ourselves using physical tools and verbal communication, the other teams used online work trackers such as Visual Studio Online. One of the teams abandoned TDD to “move faster,” and neither of them produced web-based solutions, instead favouring thick-client Windows applications.

Where organisations are hoping to embrace more agility in their delivery processes, it seems like common sense to choose partners using a process that focuses on Individuals and Interactions, Working Software and Customer Collaboration.

At EE we love this approach as it allows us to showcase our team’s focus on collaboration, short development cycles, and delivery (which, so far, has presented a strong contrast with other vendor approaches).

As it stands, we have a 100% success record in ‘hackathon’ style selection processes, so let’s hope this becomes a trend!