Interviewing for an Agile Team

by John Turner

Posted on November 15, 2010


Over the years, I have been involved in interviewing candidates for lots of different roles and companies. I say involved, as it is normally the case that I am rolled in to help assess the technical competency of the candidate and provide feedback in this regard. Typically this involves quizzing the candidate on roles and technologies outlined on their curriculum vitae and technologies utilized by the hiring company or team. Very rarely does the process go beyond this.

More recently, I have been seeking to hire for a specific role and have been receiving curriculum vitae from a number of different sources.

Having more influence on the process, I decided I would screen candidates via a 30 minute phone call during which I would introduce the role, and ask a number of questions from a predefined list. If the candidate displayed any particular in depth knowledge of a specific area, I would “go off piste” and deviate from the predefined list. The aim of this approach was to reduce the amount, or weight, of subjective opinion when evaluating the candidates familiarity with the technology stack. I felt it was less disruptive for all involved than having a face-to-face screening interview.

For candidates who progressed beyond the screening, I decided that for this particular role, I would take a more novel approach to the interview. I felt that at this stage, I had already established (as much as I could without sitting them in front to of a keyboard) that the candidate was familiar with the technology stack so I wanted to assess their approach to problem solving and design.

My approach was to present the candidate with a popular board game (Monopoly) and ask them to design an online platform for the game. There was a short brief but everything they needed was in the box. So what was I looking from the candidate?

I was looking for the candidate to display a willingness to take on the challenge, be pragmatic in their approach to presenting a design in the short time frame available, and be able to present a coherent explanation of their solution along with the decisions they had to make along the way. I also expected the candidate to have an appreciation of how the solution would further evolve.

I was also looking for other less desirable traits, such as the temptation to dwell too long on the instructions, or an unwillingness to have their design challenged.

Overall, I think the approach worked well and though some within the team were originally skeptical, everyone soon appreciated the benefits of this approach over the more traditional Q&A approaches. I will certainly be more willing to try alternative interviewing techniques in the future.

I’d be very interested to hear feedback on this approach or on other approaches people or companies have taken.