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 a lot of candidates and spent a lot of 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 a techs at once. 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 the CTO went: — Welcome Flavian — Hi! — 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 to transfer 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.
The article continues here if you want to know how pair programming can be extended, and what its rules are
Hope you enjoyed the read!
submitted by /u/fl4v1
[link] [comments]
April 22, 2017 at 10:10PM
from /u/fl4v1
No comments:
Post a Comment