First post of 2008!
Now on to the real post...
One thing that I look for in a QA engineer is an ability to understand the system under test on a number of levels. A successful QA engineer will be able to see the system as a whole and how its component parts may interact with each other. That same QA engineer will be able to describe the system as each component part sees it - imagine a package-level tour, with our friendly local QA engineer as a tour guide. This helps find bugs on a micro level (class X extends class Y, which allows for Z improper use) and bugs on a macro level (when component A goes down while component B is processing intake from the file system, then component A will not properly update component C and component C will eventually crash because it doesn't realize the file system has changed).
How do you find this out in an interview?
What Doesn't Work:
- Asking about systems they've worked on. I simply don't know those systems well enough to state whether there's true knowledge there or not. It's hard to probe them with any detail.
- Games. It can be effective if you ask someone to describe, say, Monopoly. The problem is when you run up against candidates who don't know the game.
What Does Work:
- Ask them to describe how a common household object works. I like asking how a blender works, or how a fridge works. These are things that most people know but don't know the details of.
- Ask them to describe a physical thing they can see but can't take apart. In this case I can hand them the object. I've done hair dryers and laptops. *
I'm still trying to figure out how to get it to apply to less mechanical systems and more software systems.
* In a few cases where the item has been a non-computer or other non-job related item, I've had good candidates get offended. I'm not totally sure why, but it biases the candidate against us and me against the candidate. More and more I'm trying to avoid non-tech subjects as unfairly prejudicial.