The Agile Architect

Conducting the Agile Interview

Finding the right people to work in an agile shop takes just as much energy and enthusiasm as it does to actually work there. Our Agile Architect shares some of his thoughts and techniques for a more-than-the-normal interview.

• By Mark J. Balbes, Ph.D.
• May 7, 2013

I was in a job interview the other day. No, don't worry. I was conducting the interview. There were three of us in the room including my colleague Jason Tice (@TiceThoughts) and the candidate. Before we could start our discussions, Jason pulled out a pair of dice and said, "Let's play a game. You both can play. " Having no idea what he was up to and realizing that I was now a participant, Jason proceeded to explain that we would have to roll the dice as many times as it would take to get to a count of 21. The trick was to figure out strategies to minimize the number of dice rolls. We played the game for a few minutes and then moved on to other topics.

I asked Jason afterwards why he pulled out the dice. He responded:

"Dice games in interviews are an original creation of mine for how I use them -- although I'm pretty confident that other folks have done them before. My inspiration to use them comes from Deming [as in Edward Deming]. Dice, as well as cards, prove to be a great mechanism to demonstrate many of Deming's key ideas about quality and systems theories.

Use of Dice in any setting [including an interview] can serve as a great exercise to judge critical thinking abilities -- by this statement you can use dice a 'right' way and a 'wrong' way in an interview -- the 'wrong' way is to use them as a skill test; the 'right' way is to use them in a critical thinking exercise which ideally stimulates thought and collaboration around some kind of a context that might resemble the type of role that person is interviewing for.

"Another angle you might want to integrate into your piece is bringing dice and/or cards and using them in your interview if you are a candidate. I have some experience with this, from which I can share that you'll usually get the odds heavily in your favor."

For my part, my thoughts about interviewing techniques have changed over the years. In my early days, I would spend the majority of the interview asking technical questions to probe the limits of a candidate's knowledge. While I still do some of that, I prefer to spend the majority of the interview solving a shared problem. I'm much more concerned about how a person can creatively solve problems, their approach and their ability to collaborate to reach a satisfactory conclusion. Specific technical knowledge is fleeting due to the incredibly rapid rate of change in our industry. Hunger for knowledge and a passion for solving problems, coupled with technical aptitude, are much more valuable.

For developers, the shared problem will take the form of a pair programming exercise. Most interviewees have never done formal pair programming, so I may end up teaching them as part of the interview. I don't care that they don't know how, but I do care how they take to it and how well they collaborate.

For customers/product managers, I'll usually present some kind of high-level problem to solve, work with them to break it down into stories and design a simple UI to enable some of the workflows. It's important that they actually solve the problem at hand and not just talk about how they would solve it. It's easy to say something like "I'll write the stories and then work with QA to create acceptance criteria." It's much harder to actually do that in the interview. I am looking for them to actually produce a couple of somewhat fleshed out stories so I know how they think through the problem at hand.

For quality assurance analysts, I'll do the same exercise as for customers/product managers but then work with them to add acceptance criteria to the stories. The telling point of the interview for me is to then see how devious they can be in designing tests to break the system. I'm looking to see how creatively they think in order to stretch the capabilities of the system. It's not enough to discuss simple functional testing.

Of course it's important to realize that the interviewees are under stress during the interview and will probably not perform as well as in the real world. It helps to put them at ease when you truly work with them on solving the problem rather than grilling them with a bunch of questions.

One other thing I've learned is that I need to change the problem I give them. After I've been through it in a couple of interviews, I know the problem and solution space too well and I can no longer effectively collaborate since my mind is racing ahead based on what I already know. Instead, I've taken to asking the candidate what hobbies they have. We then come up with a simple application based on that. The candidate is more at ease because they are on familiar ground and I have to collaborate because they are now the expert, not me.

If you want to hear more from Jason about using dice for interviews and other activities, leave a comment and I'll ask him to write a guest column.

It occurs to me that nowhere in this article did I talk about the interview from the candidate's side. Perhaps that's a topic for another time.