How to make faster and better hiring decisions with a live mob programming session

How we leveraged new ways of working to make the interview process valuable for both sides.

By: Mathias Fringes, Principal Architect

Introduction

Hiring for tech teams can be cumbersome and slow. Complex processes, long (asynchronous) feedback loops, complicated scheduling, unclear requirements for the candidates — that usually means not too much fun for anyone involved.

Let’s change that! Reduce the feedback time for technical assessments to almost zero and be more accurate with decisions. Following Adevinta’s key value of “experiment bravely”, we introduced a live mob programming session with the candidates and this is how it went.

Homework nobody wants to do

For a long time at Adevinta, candidates applying for an engineering position in one of our technical teams have been given a so-called coding challenge from us. The task involved the creation of a typical backend service providing an API, which was to be implemented according to functional and nonfunctional requirements. We gave out a sheet with a few instructions, like data points for the performance and the API contract. With the request to send us a complete, executable program after one week, we left the candidates more or less alone.

In most cases, we received a proposed solution, which was then reviewed by two engineers. We gave feedback to the hiring manager and then they decided whether or not the candidate made it to the next round. This is both time consuming for the candidate (we expected them to invest one evening of their time, but we could see they often spent longer), and time consuming for us. Decisions were taking up to two weeks. Just too long for a simple API and a code review. And not even particularly helpful in making a decision either, as we’d still had no interaction with the candidate. They might even have had good answers to our review comments! Yet they weren’t getting a fair hearing, or any hearing at all.

Seriously, who wants to work like this these days? Being set a task, followed by two weeks of silent work without any interaction until the result arrives. And then it’s either 0 or 1, yes or no, success or failure. And during the code review, no discussion and no questioning of why takes place. Doesn’t sound very modern or agile, does it?

Photo by Paloa Chaaya on Unsplash

“Individuals and interactions over processes and tools”

Yes, the quote above is from the Agile Manifesto, and as is often the case, it’s great guidance for a job interview as well.

During our daily work at Adevinta, we regularly code in pairs and in mob sessions. These approaches work wonderfully even in a remote setting via screen sharing. As it uses the many eyes principle by design, in many cases, this method already replaces the code review. In addition, we “work out” the requirements together with the stakeholders, in order to deliver the right thing at the right time.

Indispensable skills for engineers who want to work in digital product development are therefore communication and collaboration, both on a technical and on a business level. Making decisions together, thinking iteratively, mastering a few technologies with confidence while other tech stacks are complemented by your co-workers, plus keeping an eye on the clock — that’s what we’re looking for in our future colleagues.

And what could be more natural than trying this out right away during the job interview?

We have been using mob programming sessions for technical assessments for almost a year now. As a team of three, the applicant and two of our engineers get together to build a prototype for a typical stakeholder user story in just 90 minutes.

Meet Stan, your client

(Illustration by my colleague Patrick Hund)

Stan is a successful used car salesman and now wants to put his offers on the internet. While having lunch together, he quickly sketches on a napkin, saying, “This is how I imagine my new web page. With prices and discounts.” Where does the data come from, we ask.

“Uhmm…. I have this CSV file here from my old system… that’s all I can give you… now when can you show me the first prototype?”

Does that sound like real life? Yes, and that’s why we are engineers. We solve problems. Stan is not a technician, but a brilliant salesman who knows what his customers need and at what price, and he has now hired us to bring his ideas to the customers.

Start coding please

Before the session, we ask the candidate to prepare an empty project, keep the internet connection stable and share their screen. If we are looking for a colleague for a backend position, we would create an API that provides the car inventory and highlights the discount prices. As long as the programming language and framework fit our tech stack, the candidates can freely choose what to use. So far, we’ve seen projects in Java, Kotlin, and node.js.

Now, since this is also an official assessment of the candidate, there is a bit of a difference to a regular mob programming session, as you’d expect. We usually have three people on call. The candidate does all the typing and explains what they are doing and why — they are leading the session. Two more colleagues act as a pairing buddies, discussing and questioning technical aspects, and can help with keeping things moving if we are stuck — even if it’s just googling for a CSV parsing library. At the same time, they observe the candidate’s skill and behaviour.

The pairing group can and should contact Stan at any time, because a good engineer listens to their customers and asks if anything is unclear. One of the interviewers may impersonate the client on demand, pretending to be a technically unsavvy manager type of person (which sparks the funniest moments). Together, the stakeholder clarifies questions and priorities with the engineers.

Towards the end of the 90 minutes, Stan “appears” again and reviews the work the team has achieved.

Learnings for both sides

After more than 20 such sessions, it became clear to us — we won’t go back to sending out homework. The insights you get about a candidate in a direct work situation are so valuable for a fair decision, and we get them instantly.

Through these sessions we get to know the candidates in a completely different way. Sure, hard skills are important, but how does the candidate interact with their pairing partners, how do they communicate with stakeholders, and how do they deal with uncertainties and time constraints? Skills that matter at least as much when working on a commercial, digital product.

The feedback we received from the candidates was indeed positive throughout. In particular, they mentioned that the session was less stressful, had a more realistic atmosphere, and gave a deeper impression of our daily work, in contrast to comparable application processes.

Tips for mob programming interviews

Shared for you now, five practical tips for conducting a successful mob programming interview session:

• Build your task around a little story about your business domain. It’s much more relevant than random artificial technical tasks without any relation to your everyday work. Plus, your candidate gets in touch with your product straight away — in our case they should not hate cars.
• As the interviewer, it is not your responsibility to finish the task correctly and in time. This is for the candidate to demonstrate. After all, you need to assess their technical expertise and ability to deliver. At the same time, as a pairing buddy and colleague, you are there to help and give feedback if they ask for it. You must be able to balance between different roles during the session.
• If you’ve conducted a couple of live coding sessions with the same task, you’ll already know the best practices and the little traps. You might quickly spot if the candidate is heading in a certain direction. But resist guiding the them to a concrete solution too early, especially if you’re getting impatient. Don’t tell them what to do, rather ask about their intention. Listen! And give them enough “silent time” — it’s hard to code, think, and be watched at the same time. You might just be surprised by the creative ways they solve problems.
• When assessing an interview, ask yourself: how did working with the colleague feel? Was it fun, or was it sluggish and tough? Did they bring something new and creative to the table? How did you settle disagreements? And ultimately, did you achieve client satisfaction when presenting your prototype to the client?
• And if you are the candidate in a session: make use of the help available from the stakeholder and your colleagues, it’s a collaborative effort — and don’t forget to have some fun. This is how we work here every day.

Photo by Alvaro Reyes on Unsplash

Try it yourself

Would you like to learn more or take part in a live mob programming session yourself?

Then just apply for one of our job offerings. You can find our vacancies here: https://www.adevinta.com/careers