The Interview Roadshow

Recently I have been part of a recruitment effort for multiple roles. In May we posted two advertisements to the market: automation tester and infrastructure tester. Behind the scenes we had nine vacancies to fill.

This was the first time that I had been involved in recruiting for such a large number of positions simultaneously. Fortunately I was working alongside a very talented person in our recruitment team, Trish Burgess, who had ideas about how to scale our approach.

Our recruitment process for testers usually includes five steps from a candidate perspective:

1. Application with CV and cover letter
2. Screening questions
3. Behavioural interview
4. Practical interview
5. Offer

We left the start of the process untouched. There were just over 150 applications for the two advertisements that we posted and, after reading through the information provided, we sent three screening questions to a group of 50 candidates. We asked for responses to these questions by a deadline, at which point we selected who to interview.

Usually we would run the two interviews separately. Each candidate would be requested to attend a behavioural interview first then, depending on the feedback from that, a practical interview as a second step. Scheduling for the interviews would be agreed between the recruiter, the interviewers, and the candidates on a case-by-case basis.

As we were looking to fill nine vacancies, we knew that this approach wouldn't scale to the number of people that we wanted to meet. We decided to trial a different approach.

The Interview Roadshow

Trish proposed that we run six parallel interview streams. To achieve this we would need twelve interviewers available at the same time - six behavioural and six practical - to conduct the interviews in pairs.

The first hurdle was that we didn't have six people who were trained to run our practical interview, as we usually ran them one-by-one. I asked for volunteers to join our interview panel and was fortunate to have a number of testers come forward. I selected a panel of eight where four experienced interviewers were paired with four new interviewers. The extra pair gave us cover in case of unexpected absence or last minute conflicts.

We assembled a larger behavioural interview panel too, which gave us a group of 16 interviewers in total. Several weeks in advance of the interview dates, while the advertisements were still live, Trish booked three half-day placeholder appointments into all their diaries:

• Friday morning 9.30am - 12pm
• Monday afternoon 1pm - 3.30pm
• Wednesday morning 9.30am - 12pm

In the weeks leading up to the interviews themselves, the practical interviewer pairs conducted practice interviews with existing staff as a training exercise for the new interviewers. We also ran a session with all the behavioural interviewers to make sure that there was a consistent understanding of the purpose of the interview and that our questions were aligned.

From the screening responses I selected 18 people to interview. We decided to allocate the candidates by their experience into junior, intermediate, and senior streams, then look to run a consistent interview panel for each group. This meant that the same people met all of the junior candidates, and similarly at other levels.

The easiest way to illustrate the scheduling is through an example.

For the first session on Friday morning we asked the candidates to arrive slightly before 9.30am. Trish and I met them in the lobby, then took them to a shared space in our office to give them a short explanation of how we were running the interviews. I also took a photo of each candidate, which I used later in the process when collating feedback.

Then we delivered the candidates to their interviewers. We gave the interviewers a few minutes together prior to the candidate arriving, for any last minute preparation, so the interviews formally began ten minutes after the start of their appointment (at 9.40am).

Here is a fictitious example schedule for the first set of interviews:

The first interviews finished by 10.40am, at which point the interviewers delivered the candidate back to the shared space. We provided morning tea and they had 20 minutes to relax prior to their next interview at 11am. Trish and I were present through the break and delivered the candidates back to the interviewers.

Here is a fictitious example schedule for the second interviews:

The second interview session finished by 12pm, at which point the interviewers would farewell the candidate and collate their feedback from both sessions.

Retrospective Outcomes

The main benefit to people involved in the interview roadshow was that it happened within a relatively short time frame. Within four working days we conducted 36 interviews. As a candidate, this meant fast feedback on the outcome. As an interviewer, it meant less disruption of my day-to-day work.

We were happily surprised that we had 18 candidates accept the interview offer immediately. We had assumed that some people would be unavailable, as when we schedule individual interviews there is a lot of back-and-forth. Trish had given an indication of the interview schedule when asking the screening questions. The set times seemed to motivate candidates make arrangements so that they could attend.

By running two interviews in succession, the candidate only had to visit our organisation once. In our usual process recruitment process a candidate might visit twice: the first time for a behavioural interview and the second for a practical interview. One trip means fewer logistical concerns around transport, childcare, and leaving their current workplace.

On the flip side, running two interviews in succession meant that people had to take more time away from their current role in order to participate. We had feedback from one candidate that it was a long time for them to spend away from the office.

There were three areas that we may look to improve.

Having six candidates together in the pre-interview briefing and refreshment break was awkward. These were people who didn't know each other, were competing for similar roles, and were in the midst of an intense interview process. The conversation among the group was often stilted or non-existent - though perhaps this is a positive thing for candidates who need silence to recharge?

In our usual process the hiring manager would always meet the person that was applying for the vacancy in their team. In this situation, we had individual hiring managers who were looking for multiple roles at multiple levels - junior, intermediate, senior. With the interview roadshow approach, we had some successful candidates who were proposed to a role where the hiring manager hadn't met them. Though this worked well for us, as there was a high degree of trust among the interviewers, it may not in other situations.

The other thing that became difficult in comparison to our usual approach was dealing with internal applicants. We had multiple applications from within the organisation and it was harder to handle these in a discrete way with such a large panel of interviewers. The roadshow approach to interviewing also made these people more visible in their aspirations, though we tried to place them in rooms that were away from busy areas.

Overall, I don't think that we could have maintained the integrity of our interview process for such a large group of candidates by any other means. The benefits of scaling to an interview roadshow outweigh the drawbacks and it is something that I think we will adopt again in future, as required.

I personally had a lot of fun in collating the candidate feedback, seeing which candidates succeeded, and suggesting how we could allocate people to teams. Though it is always hard to decline the candidates that are unsuccessful, I think we have a great set of testers coming in to join us as a result of this process and I'm looking forward to working with them.

Using SPIN for persuasive communication

I can recall several occasions early in my career where I became frustrated by my inability to persuade someone to my way of thinking. Reflecting on these conversations now, I can still bring to mind the feelings of agitation as I failed. I thought I had good ideas. I would make my case, sometimes multiple times, to no avail. I was simply not very good at getting my way.

The frustration came from my own failure, but I was also frustrated by seeing others around me succeed. They could persuade people. I couldn't figure out why people were listening to them, but not me. I was unable to spot the differences in our approach, which meant that I didn't know what I should change.

Some years later, in my role as a test consultant, I had the opportunity to attend a workshop on the fundamentals of sales. The trainer shared an acronym, SPIN, which is a well-known sales technique developed in the late 1980s.

SPIN was a revelation to me and I believe that it has significantly improved my ability to persuade. In this post I'll explain what the acronym stands for and give examples of how I apply SPIN in a testing context.

What is SPIN?

SPIN stands for situation, problem, implication, and need.

A SPIN conversation starts with explaining what you see. Describe the situation and ask questions to clarify where you're unsure. Avoid expressing any judgement or feelings - this should be a neutral account of the starting point.

Then discuss the problems that exist in the current state. Where are the pain points? Share the issues that you see and draw out any that you have missed. Try to avoid making the problems personal, as this part of the conversation can be derailed into unproductive ranting.

Next, think about what the problems mean for the business or the team. Consider the wider organisational context and question how these problems impact key measures of your success. Where is the real cost? What is the implication of keeping the status quo.

Finally, describe what you think should happen next. This is the point of the conversation where you present your idea, or ideas, for the way forward. What do you think is needed?

To summarise in simple terms, the parts of SPIN are:

• Situation - What I see
• Problem - Why I care
• Implication - Why you should care
• Need - What I think we should do

A SPIN example

My first workplace application of SPIN was at a stand-up meeting. I was part of a team that were theoretically running a fortnightly scrum process. In reality it was a water-scrum-fall where testing kept being flooded at the end of each sprint.

I had been trying, unsuccessfully, to change our approach to work. Prior to this particular stand-up I sat down and noted some thoughts against SPIN. With my preparation in mind, at the stand-up I said something like:

"It seems like the work isn't being delivered to testing until really late in the sprint, and then everything arrives at once. This means that we keep running out of time for testing, or we make compromises to finish on time. 

If we run out of time, then we miss our sprint goal. If we compromise on test coverage, then we all doubt what we are delivering. Both of these outcomes have a negative impact on our team morale. At the end of each fortnight I feel like we are all pretty flat. 

I'd like us to try having developers work together on tasks so that we push work through the process, rather than individual developers tackling many tasks in the backlog at once. That way we should see work arrive in testing more regularly through the sprint. What do you think?"

To my amazement, this was the beginning of a conversation where I finally convinced the developers to change how they were allocating work.

Did you spot the SPIN in that example?

• Situation - What I see - It seems like the work isn't being delivered to testing until really late in the sprint, and then everything arrives at once.

• Problem - Why I care - This means that we keep running out of time for testing, or we make compromises to finish on time. 

• Implication - Why you should care - If we run out of time, then we miss our sprint goal. If we compromise on test coverage, then we all doubt what we are delivering. Both of these outcomes have a negative impact on our team morale. At the end of each fortnight I feel like we are all pretty flat. 

• Need - What I think we should do - I'd like us to try having developers work together on tasks so that we push work through the process, rather than individual developers tackling many tasks in the backlog at once. That way we should see work arrive in testing more regularly through the sprint.

In the first few conversations where I applied SPIN, I had to spend a few minutes preparing. I would write SPIN down the side of a piece of paper and figure out what I wanted to say in each point. This meant that I could confidently deliver my message without feeling like I was citing the different steps of a sales technique.

Preparing for a conversation using SPIN

SPIN in a retrospective

As I became confident with structuring my own conversations using SPIN, I started to observe the patterns of success for others. Retrospectives provided a lot of data points for both successful and unsuccessful attempts at persuasion.

Many retrospective formats encourage participants to write their thoughts on sticky notes. When prompted with a question like "What could we do differently" I noticed that different people would usually note down their ideas using a single piece of SPIN. Where an individual consistently chose the same piece of SPIN in their note taking, they created a perception of their contributions among the audience. 

Let me explain this with an example. Imagine a person who takes the prompt "What could we do differently" and writes three sticky notes:

1. We all work from home on Wednesday
2. The air conditioning is too cold
3. Our product owner was sick this week

All three are observations, the 'situation' of SPIN that describe what they see. Though they might be thinking more deeply about each, without any additional information the wider team are probably thinking "so what?"

Similarly, if your sticky notes are mostly problems, then your team might think that you're whiny. If your sticky notes are mostly solutions, then your team might think that you're demanding. In the absence of a rounded explanation your contribution can be misinterpreted.

I'm not suggesting that you write every retrospective sticky note using the SPIN format!

I use SPIN in a retrospective in two ways. Firstly to remind myself to vary the type of written prompt that I give myself when brainstorming on sticky notes, to prevent the perception that can accompany a consistent approach. Secondly to construct a rounded verbal explanation of the ideas that I have, so I have the best chance of persuading my team.

SPIN with gaps

There may be cases where you cannot construct a whole SPIN.

Generally I consider the points of SPIN with an audience in mind. When I think about implication, I capture reasons that the person, or people, that I am speaking to should care about what I'm saying. If I'm unable to come up with an implication, this is usually an indicator that I've picked the wrong audience. When I can't think of a reason that they should care, then I need to pick someone else to talk to.

Sometimes I can see a problem but I'm not sure what to do about it. When this happens, I use the beginning of SPIN as a way to start a conversation. I can describe the situation, problems, and implications, then ask others what ideas they have for improvement. It can be a useful way to launch a brainstorming activity.

Conclusion

SPIN is one facet of persuasive communication. It offers guidance on what to say, but not how to say it. In addition to using SPIN, I spent a lot of time considering the delivery of my arguments in order to improve the odds of people accepting my ideas.

Though I rarely have to write notes in the SPIN format as I did originally, I still use SPIN as a guide to structure my thinking. SPIN stops me from jumping straight to solutions and helps me to consider whether I have the right audience for my ideas. I've found it a valuable technique to apply in a variety of testing contexts.