How I interview: An exploratory approach

Recently Michael Bolton posted some Interview Questions as a thought experiment. This post prompted a bit of a discussion on twitter about how people interview. Like most I’ve interviewed and been interviewed countless times so I’ve experienced a wide array of methods, techniques, and approaches. Beyond that I minored in Human Resources so I’ve studied interviewing in-depth. As one might expect some interviewing methods are better than others and often what is best is based on the specific needs of the role and company. With that said I thought I would share my approach which has served me well over the last 8 years, your mileage may vary.

I use a framework that I adapted (stole) from testing, I call it Session-Based Exploratory Interviewing (SBEI). It’s based on Session-Based Exploratory Testing (SBET) created by Jon and James Bach. The Session-based portion of the name refers to the amount of time spent. A session is a limited amount of time, known as a time box. By design interviews are time boxed, usually between one to four hours depending on the role and the number of people involved. The exploratory portion refers to how I conduct the interview. Instead of a list of canned questions that I that I ask each candidate I instead consider topics I would like to cover within the time box. During the interview I use these topics and I keep notes about what was discussed so I can refer back to them later. After the interview is complete I meet with everyone involved and do a debrief.

So when I’m hiring someone I come up with a charter or end-state goal for the interview (could be written down if you like). For a tester I want to understand their background, how they think, their skill-set, and if they would be a good fit for the team. I then consider more specific areas (topics) I would like to cover during the interview. For example interest in the job, career path, motivations, preferred type of work (structured vs unstructured), chaos management, view of software testing, and experience (if any). Beyond that I like to cover “day in the life,” company culture, team dynamics, and how we view software testing. After the “traditional” interview then I wrap up with a short testing exercise (the dice game which James Bach taught me).

No two interviews are alike and this is important because no two people are alike. To ask the same set of canned questions for every interview contorts the discussion and risks not discovering the one thing that might make them a good fit. During the interview you want a natural flow so you can learn about the person but you also need to balance that with your charter and coverage (I don’t always cover everything, sometimes more interesting things come up which trump my charter or coverage. These are called opportunities). Ultimately interviews are meant to be conversations not a set of prescribed questions with numerical ratings of responses. For me I prefer an exploratory approach.

Dice Game for Interviews:

The reason I do the dice game with candidates is because some people are so nervous during an interview that it disguises their intellect and testing ability. Doing an exercise allows me a glimpse into how they might approach testing problems without worrying about saying the right thing.

How I play

First you need to experience the dice game first hand (I suggest attending CAST or hunting down someone in the Context-Driven community). I time box the game to 15-20 minutes and preface it by saying that I don’t expect them to solve it in this short amount of time but I would like them to work through it. After the time box has elapsed I bring in someone who acts as a Product owner or Project Manager and the interviewee then gives a report about their testing. The Product Owner or PM are allowed to ask questions of the tester to better understand what took place.

Advertisement

Explore posts in the same categories: Software Testing