Pamela, an out-of-work tester, has a master's degree in computer science and is most of the way to a doctorate in quality. She has eight years of experience in testing. Pamela has been unemployed for the past six months, and no one will even interview her.
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
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."