Which is the best way to interview for a software tester job? Jon has been pondering this question for many years, and recently he came across a new format that could be a game changer...
One of the other teams in my company invited me recently to assist in interviewing a tester. I accepted, but went in with a familiar feeling of dread because on whichever side of the table I sit, I’m not a massive fan of job interviews (who is?).
I hate seeing the panic on someone’s face when a difficult question is asked, and I get monumentally bored when someone rattles on for fifteen minutes hoping that, if they cover enough of the English language, they will eventually, accidentally, happen upon the answer they think I’m looking for.
There are problems as an interviewee too. I really hate that they don’t expect me to answer questions honestly, but instead want me to tell them what they want to hear, which are improvised answers that, I suspect, play to their own personal biases.
But on this particular occasion, I was very pleasantly surprised, and for the first time felt like I’d been part of an interview process where the applicant really could shine, and the interviewers could really sell the company and product. Why was this situation so different? I’ll break it down for you.
There was an Introduction
Yes, an the interview process started with an introduction, but probably not the kind you’d expect. In a relaxed environment over coffee and pastries, everyone circulated, starting with the interviewers where we were encouraged to give brief overviews of our careers so far, how we came to join the company, and what kinds of projects and technologies we enjoy working with.
This immediately put everyone on a level playing ground, and removed most of the tension that both parties carry into a formal interview.
Product Overview
Next, the development lead gave a high-level overview of a product design (you could use an existing company product, or a hypothetical or prospective project), focusing on the product’s architecture and technology stack. He made it clear that questions were very welcome, but no pressure was placed on contributing.
Doing this took even more pressure off the candidates, as they were not the one doing the talking. It also gave them an opportunity to show-off in places where they felt confident, either with comments or questions relating to the technology or design of the product.
Test Approach
Following the overview section, the candidates were asked to run through factors that would influence their test approach. Everything they mention was written down on a post-it note and put up on the wall.
It was made clear that this was a very open question that gave candidates an opportunity to use their experience in highlighting information that would help them test. You can start to get a good picture of a candidate’s technical level here, and because it’s an open question, you can move on as soon as you see them struggle to think of more suggestions.
Prioritisation
With the previous section being more of a brainstorming, the process was now brought more into focus by asking the candidate to prioritise the factors they outlined. This allows them to reflect on their previous ideas, whilst showing what they deem to be the most, and least important.
This is definitely a two way conversation though, as the interviewers should be asking questions, clarifying parts, and contributing their own thoughts. This is to ensure that the format remains conversational, rather than slipping to a formal, one-way presentation.
Non-Functional Requirements
Once the prioritisation has been done, the candidate was then asked to run through which non-functional requirements they would need to consider, and how they would be defined and measured. This allows them to talk through things like security, performance, usability etc. and demonstrate their skills and experience in these different areas. During this section, you should expect a lot of questions relating to customer expectations and pre-defined requirements.
Test Planning
Following the non-functional requirements section, the candidate was then given two requirements (either from the list generated in the previous section, or some predetermined ones specific to the product under discussion) and asked to plan how they would test these two non-functional requirements, and how they would report their findings.
How they wish to present this plan is completely up to the candidate; it could be on paper, using post-it notes, as a list or even a mindmap on a whiteboard, however they feel most comfortable.
Retrospective
Finally, we reach the part that was my favourite in any job interview I’ve been a part of: the retrospective. As with retrospectives used in an agile development methodology, it’s a time for everyone to reflect and say what they think went well, and what didn’t go so well. It does not relate to the candidate, but to the interview itself. Criticisms and positives are welcome for helping everyone to understand what could have been done better, whether that’s a format change, better timings, or a better intro.
The fact that this style of interviewing concludes with a look back at the interview format itself and not the interviewee, gives candidates the chance to show that they can be critical, and that they can confidently and diplomatically communicate that criticism.
That’s all folks!
Then we said goodbye, hands shaken and saw them out, and it’s at this point that everyone involved in the session takes a quick poll. No sitting on the fence, everyone gives a thumbs up or a thumbs down, that way we got a good idea of where we all are. More discussion follows, of course, but the initial vote can steer that conversation.
What I didn’t mention was that the dress code was casual, we had regular breaks, and constantly offered drinks to ensure everyone was comfortable and not preoccupied with worries about needing the loo or being thirsty.
Overall this approach worked brilliantly, with applicants that day saying that they’d never laughed so much or felt so comfortable in an interview, which is massive, and tells us that we saw the real people, not them in applicant mode.
I would definitely recommend this approach!
