From 2013 to 2016 I built a startup. It didn’t amount to much in the end, but we employed nearly 10 techs in total. How did we recruit them? Well we met with many candidates and spent significant time with each of them.
One time we made a mistake and employed an apprentice who did not have the right spirit. At some point things got out of hand and he started taking repeated sick leaves even though he seemed fine and healthy to us and still showed up to his school. This was our mistake. In short, we failed to see beforehand he wouldn’t fit the underlying company’s culture.
In 2015 we recruited a lot of techs at once — developers, devops, and ops. I had been the sole developer on the backend code for a year and a half, and suddenly, in the span of 1 month, we had 5 more people in the team working on “my” code. For 3 months I struggled to transfer the knowledge to them. For a startup, 3 months is forever.
Seems familiar? I’m going to share a practice that could have helped me do better at both moments.
Enters pair programming — for job interviews
After my startup crashed I applied for a job at Theodo. Here’s how one of my job interviews with Theodo’s CTO Benjamin Grandfond went:
— Welcome Flavian
— Today we will both work on a program where the goal is to compute the score of a bowling game. We will use test-driven development and implement the rules of bowling iteratively. I will set a timer to 3 minutes and we will take turns on the keyboard.
— But what do I do while you have the keyboard?
— You will tell me what I should write and I will execute. You will also watch for and correct any mistake I make. At the end of the 3 minutes I will give you the keyboard back. You will then say out loud what you are thinking about and what you are writing.
— Will you also help me detect my mistakes?
— Sure! This is what pair programming is all about: being completely focused on the problem and correcting mistakes early on. Shall we get started?
Two things blew my mind here.
One, the interview was short compared to what I used to do: it lasted 45 minutes.
Two, we communicated a lot. I used to give a mildly difficult problem to the people I was interviewing, and see them either solving the problem or struggle with it for a while. We talked about it, sometimes at length, but only afterwards.
In short, the practice of pair programming allowed the interviewer to get a clearer view of a coder’s humility, strengths, way of thinking, more efficiently than what I had ever done so far.
Second round — Training rookies
Well, spoiler alert, I got hired. And I was amazed a second time at how much quicker techs were trained compared to what I had been doing. At Theodo, new developers are put on projects after only a week, and it works very well! They spend two weeks on two different projects (with different technical stacks) doing pair programming with each member of the team. There’s no rule for how much time is devoted to pair programming, but it usually spans between 2 hours and a full day every day. This allows transferring business knowledge, knowledge about the specifics of the technical stack, and good code practices, faster than what I’ve ever seen or was capable of doing, with barely any reduction of the team’s speed.
Beyond pair programming — Pairing
I like to generalize this practice to other areas involving software use or even any domain that requires some transfer of knowledge or personality assessment. Let’s call this generalization pairing.
I’ve seen pairing used:
- To understand a client’s job concretely. My team spent an afternoon with the client to be pair trained on a technical process on a proprietary software we had to replicate. We learned many surprising details. As an example, we thought the replicated software needed to only support single IP addresses as input fields, when they used IP subnets regularly.
- To train new designers. A senior designer sat with a trainee to show her his design stack and how he used it. He taught her many keyboard shortcuts in Photoshop that he used regularly without realizing it.
Those examples are centered around software, but who doesn’t use software every day? The next time you see someone being faster than you on Excel, Photoshop, or company’s internal software, will you encourage this person to pair train you? As an executive, will you encourage this practice in your company? Let’s repeat the rules.
In practice — The rules of pairing
- Set a stopwatch to between 2 and 5 minutes, according to your taste. I usually set 3 minutes on timer-tab.com or the Interval Timer App.
- Every time the timer hits 0, switch sides and reset the timer.
- Only one person is allowed to be active at a time. Don’t get frustrated and take the place of the person you pair program with. Rather, be extra precise in your directions.
- Talk a lot. Don’t hesitate to be directive if you pair with a rookie, but keep it clear that you are directive because you care about the other’s progress. It will give her good reflexes, which is also what pair training is about.
- Switch partners after 1.5 hours to 4 hours