Evolving trial day to the next level using pair programming

When we are looking for a new mate to join our team, a lot of questions always arise. Will the candidate feel fulfilled with the values of the team and fit with the rest of the people? The already existing team, will love the new member or not? How experienced will they be? How much can they teach the team? How well can they adapt and learn from others? Here I will explain how we check and clear all these doubts.

Ángel Costela
Docplanner Tech
5 min readJan 21, 2020

--

The context of this article is about the backend position hiring process based in the Barcelona office.

First of all, we try to avoid the traditional interview approach, videocall and technical test. We think that this way is very error prone and we want people know how we really are and to be happy with us once they join the team. We are not scared about changing our processes and iterate over our ideas/solutions. In the first approach we decided to create a trial day, so the candidate will visit our office to check how is a day to day with us. You can find more information about this trial day here.

After few months applying this solution we were happy enough and we found a lot of new people for our team. Furthermore, every new member was amazing and people were thriving. But if our team is characterized by something, it is for wanting to reach excellence and we never stop iterating over a solution if we think that we can improve it, even when we have the feeling that they are good enough but not exceptionally good.

So we gathered the problems that we had in the past with the trial day. We noticed that sometimes we had the feeling of not being fair enough with the candidates and we couldn’t check how they can really work within a team and the real potential of having them on board. Some candidates were super nervous or blocked during the trial day. Being alone, facing a technical test in our office can put a lot of pressure on candidate’s shoulders. Furthermore, some of them were shy or scared about asking questions to people from the team. This fact, lead us to not get enough information about working together as a team with the person doing the trial day. Also sometimes when a candidate was leaving the office, the whole team still had a lot of doubts and clearing them was hard after this day. After every hiring process we asked for some feedback to candidates. It was a valuable tool for us and some of these problems were also pointed by some of they after the whole process.

While we started doing this trial day, our team members were joining together some days in order to practice different development techniques and share some knowledge. So we created our Docplanner Coding Dojo where we meet and practice some katas using pair or mob programming. “ A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there to have fun … in order to improve their skills.” You have more info in this link.

Our team improved a lot with this coding dojo and not only technically, we also discovered how it’s working hand in hand with colleagues from different teams and projects. This is very valuable, because it’s the perfect opportunity to understand the mindset of other people and different ways of working.

Our team doing Mob programming during a kata

Maybe you wonder why I’m speaking about coding dojos now. The reason is because the team decided to improve our trial day doing a kata with the candidate applying pair programming. We have a list with different exercises always related with the problems that you can find in our everyday work. The team will decide which problem they want to solve and sit together with the candidate to work on the solution.

What are we looking for with this exercise?

  1. Can we talk about our different ways of thinking?
  2. Technical level and knowledge about software.
  3. The process to solve a problem not only the result.
  4. Which techniques are followed by the candidate to solve the exercise (TDD, DDD, Split dependencies…)
  5. Is the candidate accepting other people’s suggestions?

To have success with this approach is fundamental creating a proper atmosphere. It’s super important working in a real pair programming environment, avoiding supervisor/candidate relationship. This exercise is a real developer /developer opportunity to learn from other professional’s vision and experience. Sitting next to the person in silence reviewing every word typed is not the way to go and will only create a tense situation that won’t give real information about the skills and competences from the candidate.

We also checked the cost of pair programming during the hiring process and is not a big deal. In the past the candidate used to spent a complete day working on its own with a buddy assigned from our dev team, who was helping in all the doubts regarding the repository to send the solution, clarifying doubts about the exercise and also with other things, such as lunch time, solving doubts about the company, teams organization and so on. After the whole day three devs from the team checked and discussed about the solution of the technical task. This usually took us between 1 and 1,5 hours. Furthermore, we had some blind spots with this method. We could check only the solution and not the way of arriving there, whilst the process of solving a problem is very valuable in software development.

Pair programming during trial day usually is done in two hours with two different devs from the team. After the first hour we change the pair colleague for a new one. In some cases we used three hours and we changed the mate with a third developer. In this way after 2 hours we will have a clear idea about the skills of the candidate the way they work, thinking, speaking and sharing ideas. And as a bonus, we are reviewing the code as the candidate is working, so later a review is not necessary. With this pair programming session, we also have a clear picture of the whole problem solving process and the logic applied by the candidate to solve the exercise. All these facts will give us tons of valuable information, but this is not only positive for us. The person doing the test can get an accurate idea about how we really are and if they can learn and grow working with us.

To sum up, pair programming with a candidate is a good idea if you want to check all the soft and technical skills from somebody. It’s also a fruitful experience for your team and they will learn a lot of new things in every hiring process. Also candidates can get tons of insights about how it’s really working with us day to day.

--

--

Ángel Costela
Docplanner Tech

I'm a software engineer. Currently working in Docplanner as team leader.