I run a software development company, I am considering hiring a QA person, what are the traits I should look for in a candiate? And what are the traits I should avoid? (extra credit for how you can test for these traits)

  • 1
    Have you read sqa.stackexchange.com/questions/55/… and sqa.stackexchange.com/questions/616/…?
    – user246
    Commented Jul 19, 2011 at 1:05
  • Thanks, they are pretty good answers, especially the first one, just didn't come up in the list as I wrote out the question. Commented Jul 19, 2011 at 1:32
  • 7
    Note - in your job posting, you might not want to use "to QA" as a verb. Instead, use "to test". Candidates will like you for that. Commented Jul 19, 2011 at 20:11
  • As the answers you have already suggest, you could do with thinking carefully about what you're hiring a tester for. Have a look at redcanary.mypublicsquare.com/view/hiring-software and think about what sort of company you run, and what sort of tester would be a good fit for you.
    – testerab
    Commented Jul 21, 2011 at 20:29
  • 1
    Also note that you will get a much different application pool using QA Tester vs something like Software Development Engineer in Test (SDET or SDE in test). A QA Tester usually writes test cases and executes them manually or uses an automated test runner and has limited coding/software design skills. An SDE in Test would have the equivalent skills (and pay) of a full developer, but focuses on the ability of your system to be tested at all levels (test hooks, unit testing, functional, integration, performance, security, etc).
    – Greg Bray
    Commented Jul 25, 2011 at 3:08

5 Answers 5


This is going to sound crazy, but... it depends.

What you want from a tester who will be doing a whole lot of routine, pre-defined tests (one hopes this isn't the case, but sometimes it is necessary) manually isn't what you want from a tester who's going to need to handle a highly dynamic system.

Assuming you're looking for someone who will be good with the latter, I'd suggest you look for puzzle/problem-solving experience (and ways to test this are many and varied, including pointing them at a website with known problems and getting them to report what they see as the killer bugs after some set time testing it. That gives you a quick-and-dirty thumbnail on the person's ability to prioritize bugs as well as their ability to find them. (I wouldn't put more stock in this one than 'quick and dirty', because interviews are high-stress situations and not everyone does their best at this kind of challenge when they're stressing over whether or not they'll do well in the interview).

Then you can ask them how they'd communicate the problems they found. That gives you a thumbnail on whether or not the applicant is going end up being seen as a valued team member or a bloody nuisance by your developers.

The next test of the tester I'd suggest is to give them some generic software design documents with known problems, give them time to examine the documentation, then ask them what they think. Here you've got an honesty test (in that you probably don't want someone who will try to give you the response they think you want), a tact test (can they tell you it stinks in a way that doesn't make it sound like a criticism), and you can see if they're good at picking out gaps (In my not at all humble opinion, picking out gaps in a specification is a critical skill for a good tester - because no-one wants those gaps to find their way to production). This is really more of a filter between the good and the not-so-good, and between the most adaptable and least adaptable. Someone who's very good but slow to adapt may not find the gaps, where someone who's a bit faster to handle new material probably will.

All of these are thumbnail suggestions to get a quick impression of how your applicant performs at some key tester-like activities. They don't substitute for experience or know-how, but they can be a useful supplement. Again, my opinion only, not to be taken as the Infallible Truth.

I hope this gives you some ideas.


Just as you would for any other role in your software development company, you decide what you want the new hire to be able to do, then seek people qualified to fulfill that role.

If you already know that you want to hire a "QA person", then you must have some sort of idea about what this QA person will do?

There are no magic traits/questions here, just as there is no magic for other software roles. There's no trick to hiring, just hard work.

Look for a candidate that is technically capable of filling the role you have in mind. And look for someone who would be excited to fill that role for an extended period of time.

If neither you nor anyone in your group has any experience working with professional QAers, you should talk with people who do. This will help you hone your job description, and help clarify what it is you will expect from your QA person.

These might help: http://strazzere.blogspot.com/2010/04/what-do-qaers-and-testers-do.html http://strazzere.blogspot.com/2010/04/testers-and-developers-at-fog-creek.html http://strazzere.blogspot.com/2010/05/slideshow-optimistic-developers.html http://strazzere.blogspot.com/2010/04/optimistic-developers-pessimistic.html

  • Agreed - make sure you identify the holes in your team that can't be fixed by a process (instead of a person) & recruit to fill those holes.
    – DuncN
    Commented Jul 22, 2011 at 21:40

I'm a workmanlike Tester who's had the good fortune to work with some excellent people over the years. When I hire people, there are some key characteristics I look for:

Eye for detail

This is the obvious one. Testers need to be able to see the little details that others miss. You know those Facebook questions? The ones that go:

Spot the mitsake : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

A good tester will see these right away.

Knowing how to test

A tester will need to be able how to quickly determine how to efficiently test a range of new services and products.

During an interview, I'd pass the candidate a fountain pen and say "Test this". More importantly than their answers would be how quickly they stepped up to the task and started to disassemble its function and construction.

Dealing with conflict

If you're lucky, a tester will be constantly finding ways to improve your product. Part of this task is to go to a Development team and to tell them that they've made mistakes. If this isn't handled appropriately, it can lead to problems down the line.

In the same interview, I'd hand the candidate a piece of paper with a logic puzzle on it and say "How would you improve this question?". The logic puzzle would be a standard one but it'd be worded badly, would have typos and layout issues.


This is one that I've learned the hard way. The interviewee would need to demonstrate that they knew how to structure their testing efficiently to target the high risk and/or value areas of a product.

I'd give the candidate the description of a large project with a few problem areas (high volume areas, ones that have been announced in the press and one with new developers) and ask them to sketch out the first few weeks' work.

Knowing when to stand up

Sometimes a tester will be given something impossible to do. I try to hire people who are willing to say "no" to me, to challenge when they think something is unreasonable. For this, I use the simplest question of all.

"The development team have written a new integrated communication service covering e-mail, text chat, file storage and file transfer. We will be demonstrating this at a conference next week. How would you approach this project?"

If they don't say "Advise that the time scales are too short", they lose marks. :)

  • I don't think the last test is right. A tester is not a manager, he should not have to deal with time issues. If the product is being released next week, well, so be it. Commented Jan 21, 2014 at 12:50
  • This all comes down to personal preference, I suppose. When I hire a tester, I want to find someone who will fight for product quality, who will speak up if they think it's necessary. I wouldn't want someone on my team who would sit passively and not challenge decisions that're going to lead to a poor quality product. If you have a strong management team, this level of awareness may not be necessary but I think it's better to assume the worst. (A true tester's mentality <g>)
    – Dave M
    Commented Jan 21, 2014 at 16:40

You should be getting the tester to "think like a tester'. The way I like to do this is to give them a scenario and then have them come up with test cases for how they would test something.

If you want some examples, Trish Khoo and I covered this topic at length in this episode of our testing podcast ... http://www.testcast.net/archives/show-03-do-i-get-the-job/

  1. Good Communication skills.
  2. Conviction.
  3. Grasping capability.
  4. Inquisitiveness and exploring the software and business requirements.
  5. Diplomacy(specially to handle developers).
  6. Basic programming skills.

Not the answer you're looking for? Browse other questions tagged or ask your own question.