Q
Manage Learn to apply best practices and optimize your operations.

When resume padding hides true software tester skills

What do you do when that job candidate is a little too perfect? Resume padding is on the rise, unfortunately. Here's what expert Matt Heusser offers as a solution.

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?

I'm sorry to hear that -- resume padding seems to be an increasingly common problem in testing these days.

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?

Behavioral interviews

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.

Next Steps

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?

This was last published in May 2016

Dig Deeper on Building Software Project Teams

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What is something you would never lie about on your résumé?
Cancel
Resumes are hard.  Outdated industrial revolution thinking, and keyword scanning have caused resumes to be a very bland form of communication.  Its a way to get your foot in the door, but we must be careful, not to let detail obfuscate who were are.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close