Pamela doesn’t have any perceptible flaws on her resume, except for the time she took off from work to go to school. She has great references. Okay, she’s a geek, but a socially acceptable and technically astute geek.

No one will phone screen or interview Pamela because she doesn’t have all the toolset vendor acronyms on her resume. She has experience with parts of numerous testing tools, but not more than a couple of months’ experience with any piece of one. Pamela’s not comfortable putting the tool names on her resume because she doesn’t have even one year of experience with any of them. Hiring managers and internal recruiters seem to be looking for tool experience rather than a person who can learn about a tool.

What a shortsighted mistake.

Why does this happen? One of the reasons many hiring managers and HR staff rely on tool experience is that they don’t know how to define the requirements for the kind of employee they want to hire.

I recommend against filtering resumes for specific toolset experience. It eliminates some of the most talented people, people who can easily learn a tool—who are already great testers, but not familiar with your toolset.

This mistake is not restricted to test managers or other technical managers. However, as technical people, we are more likely to depend on HR for initial resume screening. And, because most HR staff don’t understand what testers do, or understand the desired experience, they screen resumes based on things they can easily check off as a "yes" or a "no" (e.g., toolset, operating system, compiler experience, etc.).

Instead of letting your HR staff filter out promising resumes, try some or all of these alternatives.

Talk to Your HR Staff
When I have taught HR staff how to read technical resumes, I would write down a grid of the kinds of technical experience I expected to encounter on resumes. I listed the potential operating systems, compilers, and tools experience I wanted. Then, I talked to the HR staff. I explained why I was looking for this experience. I explained the relative importance of each kind of experience. In addition, I explained which personal qualities (such as perseverance, initiative, focus, curiosity, skepticism, problem identification, problem solving, goal orientation, adaptability, etc.) were important, and how those qualities ranked with the technical skills. I discussed what I was willing to trade off, in terms of tool experience vs. other experience. For example, I’m much more interested in knowing that a tester knows how to describe a defect so that a developer will fix it, rather than in which tool she has written scripts. In my experience as a hiring manager, once someone has learned a tool or two, learning another tool is trivial. I’m more interested in a candidate’s personal qualities, so I have a group that works well together.

Screen Resumes Yourself
Even when I’ve had the discussion with HR, sometimes they can’t help us. Some resume-screening tools categorize resumes by acronym, not by what the candidate has done. Or sometimes my HR person is a junior employee, someone who hasn’t worked long enough to understand what I’m saying. Or sometimes the HR staff is too busy to screen resumes in a timely fashion.

If that happens to you, then you can screen resumes yourself. Whenever I hire for an open position, I always screen the resumes myself. I create three piles: Yes, No, Maybe. I screen relatively loosely based on skill, and much more tightly based on how the person has worked, keeping in mind those personal qualities I want. I don’t mind phone-screening lots of people, because I can learn more from a brief phone conversation than I can from a resume. I phone screen the "Yes" resumes, respond via HR for the "No" resumes, and after I’m done with the "Yes" resumes, I decide whether to pursue the "Maybes."

Clarify Required Experience
One of the reasons many hiring managers and HR staff rely on tool experience is that they don’t know how to define the requirements for the kind of employee they want to hire. If you’re in this boat, don’t feel bad; you have plenty of company! After all, there’s a huge difference between someone who’s a whiz at testing GUIs and someone who tests embedded systems.

Many hiring managers have never analyzed their open positions, to define the requirements. However, you can define the skills and personal qualities you want in a candidate relatively easily. Here’s a quick technique for analyzing the job:

1. Define the roles this person plays, and at what level you think the interactions lie.
2. Define the activities and deliverables of the job.
3. Take a look at your current staff, and identify the personal qualities that make a person successful in your group. If you’d like some ideas for this, review the list of talents in First, Break All the Rules, by Buckingham and Coffman.
4. Define anything that would prevent you from hiring a candidate. I’m not talking about your preferences, I mean anything that would make the candidate not fit into your organization at all. Examples are people who can’t work overtime at release time; people who aren’t available to travel and the job requires travel; classes of people your company doesn’t hire, such as felons; or whatever is specific to your job.

You’ll notice that education and toolsets are only a small part of this analysis. If you absolutely require some specific minimum of education (because your clients demand it) or tool experience, then add that. However, I’ve never found specific tool experience worth hiring for.

So, here’s my plea: Make sure you’re looking at the whole person, not just a tool. Pamela, and all the other Pamelas out there are ready, willing, and able to work. Let’s give them a chance to prove themselves in an interview.

Show this column to your company’s hiring manager(s), people in HR who scan the resumes, and everyone else involved in hiring. Help your hiring managers and recruiters look past the tools to the person.

Acknowledgement
I thank the following people for their helpful reviews of this article: Esther Derby, Elisabeth Hendrickson, and Dwayne Phillips.