Your development team is ready to hire a new software tester. What questions can you ask in the job interview that (a) are not lame and (b) actually help you determine if this job applicant is qualified? If you have no idea what questions to ask the candidate, this article serves as a useful cheat sheet.
Your company is ready to hire a new QA tester. You need someone with the eye of an eagle, the nose of a bloodhound, and the curiosity of a child who wonders why Santa Claus looks a lot like Uncle Bob. So how do you find the right eagle-eyed, bloodhound person?
The same way you find errors when testing code: by asking the right questions.
It’s fine to ask interviewees the obvious questions first. It makes sense to confirm domain knowledge based on statements made in the job applicant’s résumé.
However, several people likely can check-off items on a “tools used” list. Ultimately, you want to know if the person is a good fit for your company’s tech culture – and whether you want to hang out with them at the next office happy hour.
If you make the right choice, then lucky you: You won’t have to read another résumé for a good, long time.
Have you worked in agile or waterfall conditions? Does the word “scrum” mean anything to you? Do you make it to the finish line when you sprint?
“The interview is where I learn if you’ve only had simple jobs,” says Egor Bulyhin, project manager and team lead at Smart IT. The interviewee may have been a QA tester for ten years, but that doesn’t mean the candidate has the depth and breadth of experience your demanding company requires.
Asking candidates to explain which methodology they prefer—and why—demonstrates how well they understand the benefits and drawbacks of each. Plus, it proves communication skills, and as we know, being able to clearly communicate is one of the few things that makes people superior to puppies.
Selenium. IBM Functional Tester. TestComplete. Katalon Studio. Functionize (especially Functionize). Your interviewee’s familiarity with a brand of test software may be the difference between them getting the job at your company and getting the fabulous opportunity to work somewhere else.
It’s fine if the job applicant knows more than one tool; if nothing else, it suggests they understand the pros and cons of each one. Even better: If the candidate lives and breathes the software your company uses, no one (especially not you) has to spend time training the newbie.
Though a lack of familiarity should not be a reason to escort the person off the premises. Tools change; you probably aren’t using the same software you were five years ago. It’s useful if the candidate knows your current tools – but in the long run, it’s more important to find someone who loves to learn new things.
Here again, it’s helpful to choose someone who’s familiar with your current business processes – whatever they are – and also to incorporate the diversity of someone who has another mindset. If your company is adopting test automation, it’s good to know that this isn’t a foreign concept; on the other hand, experienced QA staff understand that QA needs humans to fill in the work where machines fail. QA testers can find hard-to-spot errors and communicate to the users who ultimately judge this product. (Suck it, Megatron.)
But the issue really is whether the job applicant has a hidebound approach – “we’ve always done it that way” – and if that suggests a reluctance to adopt new business practices or different tools.
This question gives your interviewee the opportunity to put on his bragging pants. Like the time when Colin Ma, who works at the OC Tech Alliance and is a former QA team leader, noticed that his system processed 8% fewer transactions than normal. He decided to investigate.
“After three days, I found the culprit. Under a certain condition, a payment processor would shift over account numbers, which usually caused the account to not exist,” Ma says. “We fixed the bug by correcting an IF statement in the code.”
Had Ma not found the error, it would have cost his company several hundred thousand dollars’ worth of fines. That knowledge alone is enough to turn your interviewee into a fellow co-worker.
It happens, even to you, the experienced, long-suffering QA team lead. You go toe-to-toe with software and you get knocked back. Errors: 1. Your ego: -1.
Asking this question gives your interviewee an opportunity to tell you what went wrong, how she responded to it, and how this particular problem never happened on her watch again. Here’s hoping she keeps her tale to “an amusing anecdote” and not “I accidentally executed code that wiped out a backup server and deleted 90% of Toy Story 2.”
This question is the opportunity for the potential QA hire to tell a story and cast herself as the scrappy underdog who eventually becomes the star. Besides: Storytelling can get nervous interviewees to relax somewhat, and to speak in their own voices.
Naturally, you want to see how your interviewee engages with technical problems, including those that are new to her. Ask your candidate to test something arbitrary, such as a soda machine or a mobile phone app with which you’re both familiar.
Soda machines are interesting test cases, because the sum is made up of multiple parts: an alphanumeric keypad, a refrigerator, a dollar bill validator, a soda dispensary, an advertising display, etc. Also, a repairperson approaches the machine differently than does a customer who wants a pause that refreshes. QA testers who think well on their feet will consider these different functions and user needs. And it tells you, the interviewer, how the job candidate approaches the issues, from security testing to user interfaces.
Even if in the back of her mind, all she’s thinking about is how much she needs a soda.
Of course you want someone who can write a test case as easily as they can drink quarantinis. But not every interviewee gets an A+ and a gold star, particularly those who are new to a software testing career.
Don’t expect the applicant to have the answer, Bulyhin says. But the discussion can show what the interviewee considers important. “You should see attentiveness, clear articulation of thoughts, and how comfortable they would be when working.”
It isn’t their answers that matter as much as their questions. “What I look for here is for the potential QA tester to ask a question,” says Shayne Sherman, CEO of TechLoris. “I want them to ask what platforms we support. Anyone who has done any QA on web applications knows that there are significant differences between the different browsers and devices. QA shouldn't sign off on any test case until it has been tested on all [supported] device/OS/Browser combinations.”
So even if QA newbies flub that part of the interview, they might still walk away with an offer...as long as they flub it the right way.
You can ask this in several ways. “Do you use checklists? Do you add to the checklist as you go? How do you arrange your priorities? Do you start with requirements? (Please tell me you start with requirements.)” There are yet more questions that provide a window into the way your interviewee works without having to resort to carpentry or trepanation.
“QA is a repetitive process that requires maximum attention,” says Alexandra Marin, director of design at CodeCrew. As Marin sees it, the more organized a person is from the get-go, the more productive they are.
Of course, any tester wants as much time as possible. But the luxury of time exists only in a perfect world, and you don’t see this world populated only by Hemsworth Brothers, do you? Still, it’s an opportunity to set and learn expectations about how much time they are used to, and what time or process they prefer.
Ask your interviewees to speak to their experiences about getting a job done under pressure—and to explain the other steps they would have included if the team was given a few more days.
If they resist the urge to sigh dramatically, so much the better.
QA teams can work in many ways. Some are part of a larger development team, where data center operations gets together with programmers for regular meetings (or for beer). Others are used to communicating largely among themselves. Similarly, some QA teams come in long after the application design process is complete, while others get involved from Day One. That isn’t to suggest that one process is better than another, but both the interviewer and manager should know what the other person expects and desires.
A candidate who forgoes planning sessions in favor of some much-needed bug hunting might be focused on the task at hand—and nothing else. Is that good or bad? The answer is up to you. One QA tester may expect to be part of sprint/development planning sessions to better understand the context of each task, and thus to assess each feature’s risks and complexity. Another might feel that it’d be more productive to invite goats to a Zoom meeting.
As you know, planning sessions are a good way to get in front of theoretical problems before they become actual problems. We hope your interviewee knows it too.
Good luck with those interview questions. And remember that the answers will lead you to your next QA hire.
One possible set of questions for job candidates is how they go about writing test cases. You might as well bone up on those processes by reading our white paper on test case best practices.