Let's not forget what makes a good tester a good tester

In the past year or so, I've spent more time than not trying to find really good "agile testers" to hire. In this search, I have also had many conversations with other people about what I am looking for, what they are looking for in hiring, and how we can find what we are looking for.

Lanette Creamer asked a question recently about whether people searching for agile testers seem to be starting to focus too much on technical skills over *testing* skills. (By the way, Lanette will be looking for a job soon -- if you have an opening or might during this year, I suggest taking a look at her blog, Testy Redhead, and contacting her for further discussions.) As someone who has and will continue to hire testers to work on agile teams, I'd like to lay down my priorities in what I look for, and make an appeal to other hiring managers not to forget the qualities that make a really great tester.

So, if I had to lay out a bulleted list of what I am looking for in a person to join my team, it would look something like this:

• Passion: I am looking first and foremost for someone who is passionate about what they do. I want someone who enjoys testing, someone who will be on my team for the long haul and not just use it as a stepping stone.

• "The testing mindset": This one is hard to quantify, and I am relatively certain that I won't do this description justice. But here's a shot at it: I believe that many great testers are naturally curious, naturally analytical, and are critical thinkers. I believe they are particularly good at seeing through a problem down to its root issue. I believe they usually enjoy puzzles and logic problems. Many very good testers I have known are the kinds of people that see a typo or grammatical error on some publication and it stands out to them like a sore thumb.

• Technical ability: Coding ability is icing on the cake for me. I love to have it, but if it's not there explicitly, something that indicates an ability to learn to code is all I really need. I've said for a while that I think it's *much* easier to teach coding skills than "the testing mindset".

So when I am sitting in front of a pile of resumes, what process do I go through to try to find these people? It is by far not a perfect process, but here is *roughly* how I try to find great testers.

• Before I have resumes, I must have posted a job description. I try to make my job descriptions stand out from the norm. My classic role model for this is the Atlassian QA Engineer job description: http://www.atlassian.com/about/careers/listing.jsp?jobID=48 I do not require experience on an agile team or automation or coding skills.

• A resume that stands out: (Let's assume I always do resume scanning/filtering on my own rather than using a recruiter) I found last year that a large percentage (just over 50%?) of the resumes I received were very bland. Many of them appeared to be nothing more than a broad list of technology keywords squished onto a few pages. Unfortunately, listing a whole bunch of technologies you have heard of (they can't possibly be masters of all of these technologies!), tells me *nothing* about what you actually *do* or how you do it. I look for a resume that describes your accomplishments and tells me what initiatives you are going to bring to my team. I also look specifically for signs of continuous improvement, both in themselves and in their roles.

• During phone screening, I can usually get a good feel for whether passion exists or not. I tend to ask candidates about themselves, what they do, what they like about testing, and what they don't like, and what made them apply for my position. I tend to ask the typical biggest accomplishment and biggest disappointment type questions. I learned this year to ask questions about what they do outside of work (favorite blogs, books, websites, etc) and to pause long enough to let them say more than just their answer. Some people make it pretty clear at this point that they really want to do something else (like be a developer) or that they just need a job, period.

• For those that I want to talk to in person, I've started giving them a testing exercise (thanks to Patrick Wilson-Welsh) to do between the phone interview and in-person interview. I've chosen to do it this way because I don't really want to filter out people just because they are nervous in an in-person interview. In this example, if they can follow and test Java code, that's great, but if they don't have that particular skill, I send them to just the target website of that exercise for testing, and ask them to jot down a list of what they found and questions they have. I encourage them to communicate with me and ask questions freely. I have actually had people "self-select" at this point and refuse to do it.

It's worth noting that this exercise is what gives me the most information about their analytical and testing skills. Their responses to this will tell me a few things. I will get to see how well they think through the problem and which things they have questions on. I'll get to see how comfortable they are asking questions (I want someone who is not afraid to ask questions). Hopefully, I will also get to see them find some bugs and evaluate how they report those bugs.

• The in-person interview: It has been suggested to me that I work through the testing exercise in more detail with them in person -- kind of like a pair-testing exercise. In the future, I believe I will incorporate this more, because it makes sense. In general, though, by this point, I am fairly comfortable with the major qualities and fundamentals. During this stage, I tend to describe the current environment, along with the biggest challenges and hurdles to jump. I ask them how they would approach some of the real problems or tackle some of the actual challenges.

Obviously, there are many many resources available out there on how to find good people. Social networking has become a really great resource for recommendations for job applicants and shouldn't be overlooked as a source of finding people who can be specifically recommended. Johanna Rothman has an entire blog dedicated to Hiring Technical People. Books have been written on interviewing and lots of websites offer tips and advice on questions to ask. I'd like to hear from you about particularly good or bad interview experiences (from either side of the table) that you've had. What have I missed here?