Tuesday, March 20, 2012

Off-topic: "Microsoft" questions in interviews

I've been seeing a bit of traffic around the net these days about the so-called "Microsoft questions" and whether they provide any value (most recently I think I saw this on a blog). The questions most often raised is "shouldn't my code speak for itself?" and "what could this possibly tell you about me?". The answers are - "no" and "a lot". Let me elaborate.
I've been on the hiring side of the table for over 15 years. I've interviewed several dozens of people and hired only a handful of that total number. Did I pass up very qualified individuals? Yes. Did I make what I think, even in retrospect, were good decisions? Yes. The reason is that I picked individuals who answered those "Microsoft" questions well. Not always correctly, but well.
The reason behind the "Microsoft question" is to find out how someone thinks. I couldn't have cared less if the candidate got the right answer. Rather, I was looking to see how that person thought and approached the question. One of my favorites was the following:
Sherlock Holmes is looking for a new Dr. Watson. You are placed in a room with 3 light switches. Down the hall is another room where Holmes is sitting with a single lamp. One of the 3 switches controls the lamp. You can't disassemble the switch and can't see or hear anything outside of the room.You can play with the switches as long as you want but when you enter the room with Holmes you must tell him, with 100% certainty, which of the switches operates the lamp. How do determine which switch controls the lamp?
I love this question. But why? Because it requires the person to think creatively and "outside the box". I don't really care if you get the right answer. I want to know how you think. I always ask my candidates to think out loud so I can understand what their thought process is. How are they attacking the problem? Are they finding the obvious and hidden information in the question?
I was a Windows developer for several years and one thing that I learned pretty quickly was that if you didn't want to just make another version of Word with the Microsoft Foundation Classes (MFC), you really needed to find alternative solutions. MFC didn't always do things in ways that you thought it would. It often required some creative solutions to make the MFC do what you wanted. If someone approached the problem above with a straight-forward approach they'll fail. Same thing with MFC (or any other technology for that matter). Which means they'll get stuck easily and need some help. Which means that I or one of my leads would be spending a lot of time trying to teach this person how to solve problems, not just work through the hard problems of architecture and design. Just today I was talking with a friend about his experience in Drupal and the same thing came up. You can't always rely that things will work as advertised and sometimes you need to get your hands dirty to solve the problem.
The hardest thing I ever did on Windows was override a common dialog. If you're not familiar with these, suffice it to say that they are provided by the framework at a very low level in the system and that, while they provide some override functionality, what I got asked to do was not part of the traditional customization flow. I got some of the problem solved with some straight-forward work but it took some pointers from a senior developer to lead me to the final solution which required not one but two different class overrides. It wasn't just something I could Google (even though Google didn't exist yet). The final result was a small thing but it made the product manager happy and I learned quite a bit about how Windows messaging worked. Would someone unable to approach that problem above have been able to solve it? Possibly, but it have been far more challenging - and time-consuming. And for those people who just give up on the Sherlock Holmes problem they would have come back to me saying it was impossible (even though it apparently wasn't).
My wife's workplace has something of a mantra that there was one qualification you had to have and the rest they could just teach you (theirs was financially-based). I follow that same kind of mantra, but it's around creative thinking. If you can think creatively, you can usually work your way through or around almost any obstacle that pops up from a development perspective. Sometimes the answer is "can't be done" but if you have more than a hammer in your tool bag you'll have a lot of options to try before you come up with that answer. And that's what I like to see - meeting needs creatively and growing my developers.
So are the "Microsoft questions" important? The answer has to be "yes". They show that while you may not have the skills, you have the mindset to attack problems from a variety of directions. It shows you're tenacious and don't give up. That you have a variety of ways of framing a problem. To me, they're not just important - they are pretty much the entire interview.

PS - If you're interested in the answer the Sherlock Holmes problem, just post a comment and I'll vet your solution or send you the correct answer.