The "Silent Partner" in the Interview

A friend of mine has been recently interviewing. In the process, they have had to face the sometimes enjoyable, sometimes frustrating, and occasionally anxiety ridden "silent partner" of the process... the whiteboard.

In the past few years, it seems that the whiteboard and its quiet involvement has become the primary means of interviewing. I think there are several reasons for this, the most basic being that you can't really script for it. We've all had the opportunity to hear the constant refrain of generic interview questions over the years, to the point where people are automatic in their responses. They are also uninspired; I can't say I blame them, I hate answering those canned questions, too, so I look forward to the whiteboard experience. It should also come as no surprise that I'm the "whiteboard interviewer" on my team today.

Now, before I get something thrown at me, let me explain why I think the whiteboard is so important. I'm a software tester, and one thing that we know well in our field is that there is no "one correct answer" (all right, sure, if you are asked what 2+2 is, I will expect you to answer 4, and if you answer something else, you'd better be prepared to really entertain me ; ) ). For most things, though, there isn't a pat answer. There's a lot of variety, and much of it can be seen by examining the history and experience of the tester. That's why generic questions are terrible, but creating a wire frame of an application and asking someone "how would you test this?" is a lot more interesting.

As I said, I'm not really interested in the "correct answer" as I am to see how someone thinks, how they process information as it comes in, how they pivot and adapt to that information, and what they actually believe. Yes, in software, I want to know what you believe in, and what you will fight for. We use a phrase in testing. We call it "Bug Advocacy". What it really means is "Can you sell me on why this issue is important?" One of the experiments I like to do (and I owe Cem Kaner for this idea) is to build a wire frame of an application, usually rudimentary and missing a bunch of stuff, and see how far the candidate will go. If they only say "well, I'd do this and this and this..." and jut talk about the features they see, that gives me an indication of their level of involvement and their focus. Note: I'm not being critical here, some testers really will focus on exactly the cases they can see, and they will perform them flawlessly. What gets me excited, though, is when I post the question "so, do you think we're ready to ship this?"... and they stop, at first apprehensively, and then you see it, that wicked little gleam in their eye, where they say "hey, I know that the requirements call for this, but what if we added this option? I think we are not being consistent if we don't have this control..." and they start looking at the requirements both explicit and implicit, and start proposing additional ideas, and how they would test them.

You might think that this would be a clincher if they do this, and often, it's a really good indication, but I do keep one more trick up my sleeve (and again, Cem Kaner gets the credit for this approach). After we discuss the areas that they would test, and how they would offer improvements, if they made the suggestions, I then go back and make a second revision of the wire frame, and I will deliberately leave out the item that they made the biggest deal about. This serves two purposes. The first is that I want to see if they will remember what they suggested, and if they do, will they make a point about bringing it up to remind me? If I offer resistance to putting it in, do they just shrug and go on, or do they try to sell me on why it should be there. When I see someone willing to make a case for a feature they suggested (not argumentatively, but making a clear and informed case as to why it deserves to be there), that's when I know I've got someone I want to talk to more in depth, or make a serious effort to get on board with us.

For those who are programmers or who produce art, this may not be your experience, but if you are hiring testers, I would absolutely suggest making the whiteboard a silent partner in the interview. The secrets the board will reveal may prove to be way more valuable than you might think.