In a recent assessment of people applying for graduate and intern positions at my work we wanted a way to quickly assess them as a group. Ideally we wanted to see their individual skill at work, how well they worked with others and all in under an hour for groups of up to five. So I suggested we get them to do some Mob Programming on a Kata exercise. It wasn’t something we tried before but the idea wasn’t completely out of the blue.
Pairing when interviewing Testers
Six years ago, at a previous company, I was the sole tester in a team with about six software developers. When it came time to hire another tester I thought through what the job requirements were. I wanted someone who was different to me as I felt I was an inexperienced tester using all my coding experience to make up for it. But I also wanted someone who I could work with very closely every day. So when I narrowed down my short list to four people I invited them in for a one hour technical interview. At the time I was using Fitnesse to test the REST backend webservice. So we sat down and wrote a new test within the tool as a pair. We regularly swapped keyboards and talked through the problem. Sometimes I’d keep the test and sometimes I’d throw it away. The guy I hired ended up being the most interesting to talk to but we never got very far in writing the test. But he gave me a lot to think about for higher level strategies as well as insightful questions on how the test system worked and reported failures.
I figured it was a pretty unique situation so when it came time to hire the third tester in our little team I didn’t use pair programming to assess them. It was an experience I was glad I did but never saw it as something I’d recommend to others. The situation felt unique enough I wasn’t sure if it would apply anywhere else.
Pairing when interviewing Software Engineers
Five years later and my boss is asking about how to assess the “fit” for a bunch of software engineers he’s planning to hire over a short period. So I share my story about the pair programming task. It was a few days later he asked if I could do something like that with the software engineers we’re interviewing. So I put together a Kata type exercise in C++ and planned to be the pair in a pair programming exercise.
This time my work with the interviewee was a bit more focused to allow them to show their skills and less on how well they work with me. I worked on the Kata and refined it to a point where there was some code already in place but it had only solved the most obvious problems. I also wanted to have code that was good but could be improved through refactoring or evaluating the quality of the interface. And to better support the interviewee, I decided I would never directly reject something that they wanted to do. If they wanted to just write code and not write any tests I’d simply say “I would write a test first” and then support them in the direction they go. Anytime the progress would stall I’d ask open questions to see what they were thinking. If they were still stuck then I’d ask questions to hint them towards a solution I would apply. If they asked me a direct question I was happy to help get into specifics.
It worked out pretty well. I had two other observers in the room that conducted the bulk of the interview but were silent when we were coding. The interviewees relaxed as we got about 10 minutes into the exercise and started to be very open with their thoughts and ideas. I’ve done it across a dozen candidates now and I don’t think any had much pair programming or TDD before. Only one – so far – insisted in writing the code without updating the tests, the others took my hinting. The most impressive candidate refactored some of the messy parts in the code into clean C++11 style code before taking on the rest of the challenge.
These are my guiding rules:
- Make the candidate comfortable.
- Ask questions. Get them to voice their thoughts.
- Let them get stuck, ask a few questions on the problem. If still stuck then guide them out.
- Help them show their strengths!
Mobbing when interviewing Software Engineers
Then I joined a small group to help assess the intake for (paid) summer internships and our graduate intake. We wanted to build a specialised track for software engineers that did not exist before. Part of the process included a group exercise so we wanted to build a new exercise that was a better fit for software engineers. You know where this is going.
A group of five graduates was our first experiment. I facilitated and explained how we were going to have set roles of Driver, Navigator and Observers and those roles would switch every four minutes. I had three other people in the room assessing their performance. This was a bigger challenge for this group as they had very limited C++ experience so got stuck on a lot of syntax issues. But they still managed to get some progress and show good understanding of the problems and possible solutions.
The next day we repeated the exercise with two groups of five interns. We made some adjustments based on issues with had the previous day. We gave them 10 minutes just to explore the problem, existing code and discuss a plan of attack. We made it clear that we wanted the group to succeed and were assessing them on how well they supported and helped the group. And I got a lot more involved to ensure syntax challenges didn’t slow them down.
They did great! Both groups of interns were able to make significant progress and the collaboration and support was great to watch. It gave us some clear indication of how they would work with others, how well they could understand a coding challenge and how well the could communicate the concepts to others.
Process for Mobs:
- Give them time to explore the problem and plan an approach.
- Explain they are to support the group success not individual success.
- Explain the roles (Driver, Navigator and Observer) and that the Navigator can ask for help.
- Practice rotating roles before starting to code.
Where to next?
I need to have a better suite of exercises including some in other languages. I like that I have a problem already in progress because it gets past the “boring early bit” of any coding kata and allows the participate to make some big decisions. It also challenges them to read code that they haven’t seen before. Code that is clean but could be cleaner. We’re still actively using this approach in our interviews and will likely apply it again next year to further graduate and intern intakes.
Finding new places to collaborate!
Photo by: Esti Alvarez