Friday, March 13, 2009

My Favorite Interview Question

I do a fair number of interviews for various QA positions. And there's one question I ask of anyone who is going to be testing:

Tell me about your favorite bug.

I ask this because it's a hugely open ended question, and almost no one has thought about it beforehand. It's amazing the different responses I get, and just how illuminating they are. People talk about:
  • how they can't think of anything (for the record, this is a bad sign).
  • how very very many there are (also a bad sign - you really can't differentiate?).
  • who found the bug (was it them alone? a team? did they really take the lead here? was it a customer and you did the after-the-fact diagnosis?).
  • what's important about a bug to them (hugely visible GUI issue? funny but embarrassing problem? subtle issue that shows how smart and thorough they are?)
  • why that problem stuck with them (a recent thing that was the first that popped into their head? - not generally good, by the way)
I find this a good opening for conversation, and it can lead in all sorts of directions. Plus, it's nice to get people off a well-rehearsed path.

What do you ask in your interviews?


  1. "and almost no one has thought about it beforehand"... things may change after this post esp if your interviewees check out your blog :-)

  2. That's probably true! I hope it'll still be useful, though, and I like to think I have a few other unexpected questions up my sleeve.

    What's interesting to me is that I'm generally surprised it's unexpected - when testers get together I feel like we talk about past bugs all the time. You'd think that would be expected in an interview conversation. I guess it's just no "tell me about your weaknesses...".

  3. I ask people to test something during the interview. If it's a face-to-face interview, I give them a buggy application and ask them to develop a series of tests and report back on their findings. I then give them fifteen to twenty minutes to test.

    If it's a phone screen, I'll ask them to analyze an application like a shopping cart or search - something that gets them talking about how they think about testing and how they structure their tests.

    With both exercises I'm interested in getting people "off the well-rehearsed path" (as you nicely put it). I'm also interested in how they communicate their findings, how they justify the possible issues they find, etc... It surprises me sometimes how few people have ever been asked to test as part of an interview.

  4. We also ask people to test something, if they make it as far as the interview. We give them an app, a "spec" (read: bulleted list and a note that in general it should follow the model of X program - also installed on the machine), and 45 minutes. Only a few people have ever finished (and they generally did pretty poorly). For everyone else, it's interesting to discuss what they found, how they found it, and why they didn't find the things they didn't see.

    I'm with you - it's amazing to me how many people comment that this is the first time they've been asked to test anything in an interview. I'm not really sure how anyone else manages to hire testers!

  5. Great question. I will probably be interviewing a tester at some point (hopefully we'll grow to reach that point) and I'll certainly ask that. another one I'll ask is:

    "Why is it called a 'bug'?"

    You'll know immediately if they don't know the real answer, and it will be interesting to see them try to come up with a reason. I think.

  6. Jacob, that's an interesting question. I'd hazard a guess that even among the people who have commented on this, you'd get at least a few different answers.

    What's your answer?