peshkova - Fotolia
I'm having a problem with hiring lately. The resumes look perfect, but when I get the person in, the software tester skills don't match and only about half can actually do the work. What can I do?
In programming, expertise may be a little easier to measure. In testing, there is an idea that smart people can figure it out, but the hiring companies want specific buzzwords. As a result, the only people who can get an interview have the exact right set of buzzwords for the right length of time. Because work environments are so different, people make them up. On the extreme end, they make up the entire background -- something I have seen before.
My first thought is to fire all the recruiters and contract houses that are sending you the bad candidates, but you might be able to do better than that.
Let's start with your next interview.
One thing you can do is ask the candidate if this is their resume. In some cases, the staffing firm will prepare the resume themselves, which will be obvious to the candidate. To figure out if the resume has been doctored might take a little more time -- two minutes or so. If the candidate admits resume padding occurred without their permission, you might not want to punish them for someone else's mistake. If they don't admit it, but you suspect some discrepancies, then you've got a bit of a challenge. If the resume looks too good to be true, it just might be. One of my peers, a test manager in New York, tells me she simply assumes the resume is a bunch of half-truths, throws it away and tries to assess software tester skills herself.
So, you throw the resume away -- now what?
I fondly remember my first interview as a programmer. It was the late 1990s, and there was a scramble for technical talent. The CEO started by learning about my background and living situation -- I would have to move to work there -- then he started selling me on working for him, talking about how if I wanted to get an MBA, he would pay for it.
At no time did he actually ask me to code anything, or even any design questions.
I guess that was OK; the starting pay wasn't high -- though the bonus opportunities were. If I didn't work out, he would ask me to leave and he wouldn't have spent a lot of money. Still, four years later, my interview at McGraw-Hill entailed me answering what a code sample, similar to the one below, would do:
double d = 10.231224;
printf("the amount is %2.4f\nThe amount is %2d\n", d, (int) d);
McGraw-Hill had a much higher chance of knowing if I could do the work.
To do similar work in testing, find a screen, data set or API, preferably a real one. Ask the candidate for ideas to test it. Make the problem as realistic as possible -- just not so detailed and realistic the candidate thinks you are asking them to work for free. You'll be amazed; some people's eyes light up and they dive in, while others who look perfect on paper shut down, coming up with just one test idea or two. Sometimes, when this happens, the candidates really do have test experience, but it is test execution-only experience -- not test design. In most cases I see this, the company wants to hire someone to both design and execute the tests. Executors-only get stuck. It is rare that I would recommend hiring an executor-only role. If you must, use an intern. They are cheap.
If you have behavioral tests, talk about why they aren't filtering out the right candidates. It may be time to improve them.
A few things to look out for
Be careful with phone screens, as that can be a real risk when assessing software tester skills. In the past, I have heard typing of keys, which might mean using Google for answers, or even, occasionally, what sounds like someone else whispering.
When possible, try to meet the candidate in person. If you can't do that, at least try Google Hangouts; it is cheap and free, and even works for remote employees.
Also, take a hard look at those skills sets that are required. If you've had some people flake out who were unqualified, chances are a few liars slipped through who faked it until they made it, which means those skills weren't really required. Try dropping some of the keyword requirements and filtering through a larger resume stack. It might be work, but it might be worth it.
Good luck; I hope these ideas help weed out candidates who are resume padding.
What all software developers' résumés should have
Be ready for your next cloud security manager interview
Are you on the right cloud career path?
Dig Deeper on Topics Archive
Related Q&A from Matt Heusser
Through unit testing, software developers know source code works at the atomic level. Read why unit testing is important and valuable, as well as how... Continue Reading
Your boss has jumped on the bandwagon to automate software testing. Don't despair. Software testing expert Matt Heusser walks through what to say -- ... Continue Reading
Common software security mistakes include testing at the last minute and not testing open source code and VMs. Expert Matt Heusser suggests ways to ... Continue Reading