Fantastic Testers and How to Hire Them, Part 2

Introduction

Welcome back to the blog, and welcome back to this series on hiring fantastic testers. Previously in part one, I talked about what to consider before you even start the process of hiring a tester. To find a good candidate, you have to look for certain traits: curiosity, creativity, tenacity, organization, and a meticulous nature. I also talked about the importance of writing a job posting that tells potential candidates why they would want to apply to your available position rather than just listing what they’d be doing.

This time around, I’ll talk about what I look for when I’m screening candidates, how I handle phone screening, and a general overview of our interview process. Keep in mind that I’m coming from the context of hiring a purely manual tester to work in an agile environment with weekly releases on software that is designed for visual thinking. Despite that unique context, I think there are a lot of generally applicable lessons to be learned from our approach.

The screening process

Writing a job posting that speaks to why your position is unique rather than focusing on job requirements will draw in a lot of candidates from diverse backgrounds. Likely some of those candidates won’t have experience with testing, but that’s what you want. Diversity among testers helps ensure that you are better able to catch a wide variety of bugs. The screening process is where you start to narrow in on finding a fantastic tester.

It can take a lot of time to sift through all of those applications, review each resume, read the cover letter, and pick the candidates that you want to interview. You probably don’t have a lot of time. So how do you cut through the applications quickly? I do it by looking for red and green flags, those being negative and positive indicators for success respectively. I don’t have a clear-cut threshold of how many red flags is too many—you’ll know it when you see it.

For each candidate, I begin with a glance over the resume. I look at the format of the resume first. I know that sounds odd, but I need testers who aren’t going to sugarcoat things. A resume that uses an unusual format or includes big elements that don’t convey meaningful information can be a big red flag. For example, if the skills section includes some sort of progress bar, that is just taking up space and not really telling me anything. I want my testers to be straightforward, open, and honest about things. Just give me the facts in a nice clean format. If they can’t do that on a resume, then maybe they can’t do that with a bug report or a regression test.

Next, I’ll review their work experience. If the candidate has prior experience, then I want to scrutinize that for red flags. I want to determine if an experienced candidate might have some bad habits that wouldn’t fit the way we work. If they don’t have experience, then I’m looking for any of the desired traits reflected in their previous work history.

Finally, I will look at their education, but I don’t put too much emphasis on this given that there is no actual degree for testing. Also, seeing that a candidate has some sort of testing certification is not an indicator that they will be good at testing, but it does tell me that they are interested in the role—they were curious and wanted to learn more about testing.

After I take a quick glance over their resume, I will read through their cover letter. This is the part that matters most to me. I want to hire testers who are passionate about doing testing. If a candidate doesn’t bother to write a full cover letter that explains why they are interested in the role and the company, then I’m not terribly inclined to move forward with said candidate. A candidate that wants the job will be eager to learn, and in testing, that can matter more than certification or prior experience.

In both the resume and the cover letter, I’m looking for correct spelling and grammar—yes, that matters. If a candidate cannot be bothered to pay attention to those details in their application, what reason do I have to believe that will pay attention to the details in our software? When I see a cover letter that is short or poorly written, I don’t believe that the candidate is seriously interested in joining our team, nor are they likely to have the desired traits I’m looking for in a tester.

A few more green flags:

• Candidate has a unique background that is different from the rest of the team—variety in testers is extremely valuable since no two people will approach a problem in the same way.
• Candidate is looking for a change in careers. I have found that people who are looking for a new career are motivated and excited to do something new. They are often eager to learn new skills and new tools.
• Candidate has a scientific background or has worked in a laboratory. The Scientific Method is valuable to testing, as it helps someone think about edge cases. It also implies an ability to write clear steps to reproduce, an adherence to process, and an eye for detail.

Perhaps the biggest red flag of all is when the candidate mentions that they view a testing role as a stepping stone to development or otherwise see the QA Department as a way to get a foot in the door at the company. This bothers me greatly; I’m hiring for a particular role because I have a particular need. Candidates that view the testing profession as a stepping stone are basically insulting the work you and your team do day in and day out, and that means the candidate is wasting valuable time. If I hire that candidate, I know that I’m just making more work for myself since that candidate will want to leave the role in 12-18 months. At which point, I’ll be back to square one. Why would I hire someone who I know, from the start, doesn’t really want to be on the team or do the work? This is also the reason I am very clear about our testing needs for manual versus automation testing.

Let me be very frank. As a hiring manager, automation and the industry attitudes around test automation can be the bane of my existence. I get applicants that look good during screening but when I talk to them, they make it clear that they only want to do automation. And if the candidate doesn’t already have automation experience, there’s a chance they’re expressing interest in automation only because they’ve been told “that’s the thing to do” or that “manual testing is dead.” Be clear about what your team’s needs.

The phone screen

I pretty much never skip this step because it is one more sanity check to perform before you bring a candidate in for an interview, which is a process that can take hours out of people’s workday. The phone screen is your first real chance to gauge the candidate’s cultural fit, communication skills, and interest. The call is usually short, around twenty minutes or so depending on their questions. Schedule a time and be punctual. If you call the candidate late, you may have put them in a higher state of stress which can negatively impact their performance. The phone screen isn’t the time to test how they act under pressure—that’s for the audition, and we’ll have more on that next time.

I start the call by giving a brief introduction to the software we test, more of an elevator pitch than a summary of features or use cases. Then I talk about the company’s culture, conveying how it makes us who we are and is extremely important to us. With testing, the candidate’s fit to the company and team is usually more important than their testing knowledge; we can teach anyone with the right mindset how to test. I want to get the candidate talking about the culture points and how they are of interest and value to them. At this point, I’m listening to how they articulate their point. Are they succinct or do they ramble and start over, never really getting to a meaningful answer? This is important because their communication style is what everyone is going to be dealing with if I hire this person. Communication is a major part of being a successful tester.

Next, I’ll ask a very simple but opinion-based technical question about their favorite operating system, streaming platform, web browser, word processor, etc. I want to hear them explain why it is their favorite, and in this instance, I’m listening for how detailed their answers are. How much thought do they put into the question? Then I’ll follow up by asking what they would do to improve that product, again listening for the same things.

Finally, I turn it over to them, and ask if they have any questions. A candidate with a lot of questions can indicate a higher degree of interest, though it doesn’t mean the opposite is at all true. Listening to the types of questions they ask  can help you get a feel for whether they’re genuinely interested in joining your team or if they’re just looking for a foot in the door.

What about asking technical questions about how to test? I don’t bother with questions like that because the in-person interview digs into that knowledge in far better detail. Also, in this day of the internet, the candidate could just look up an answer online. The phone screen isn’t about assessing technical capability—unless they tell you that their favorite web browser is Internet Explorer because it is written in Java.

That’ll do it for this second installment of Fantastic Testers and How to Hire Them. Next time, I’ll talk about the format for the interview, interview questions, involving your existing team, and the importance of including a technical audition (the testing equivalent of a programming test).