Moving On, and Interviewing Classes

It's that time again: moving onward.  At the end of the month (assuming all goes well) I'll be moving over to the Windows Lifecycle team, leaving the Hardware Evangelism team I've been with for about 8 months.  Although it's been a short stay, it feels complete and a good time to move on, with Vista/Longhorn beta 2 on the horizon I'm excited about being in the Windows division and the new team.  (And speaking of evangelism, your team lost the chance, Scoble, maybe next time ... :)  j/k)  I do enjoy the opportunity Microsoft avails internally.

Jason (director of the team I'll be moving to) related a fairly well known story about Longhorn, but it was the first time I've heard it.  Whistler (codename for Windows XP) and, of course, Blackcomb, the next OS post-Longhorn, were named after a couple of mountains (ski resorts, too) in BC, Canada.  This part I knew, but what I did not know was that the next big OS post XP was Blackcomb -- and it was a fairly lofty project.  An interim OS release was necessary to bridge the gap.  So, between Whistler and Blackcomb (in the Whistler Village) is the Longhorn Saloon and Grill.  And the rest is history.

Of course, a small, interim release it is not, but that's how it goes in software and the internet under Moore's Law. 

I've taken a number of interviewing classes at Microsoft as we gear up to fill positions on my team and I realized something quite profound.  The way I interviewed candidates in the past was just plain wrong.  Not wrong as in inappropriate or illegal, but wrong in that many times, I could've asked better questions and could've been more objective, not relying on just personality, chemistry, or intuition to guide me.  It's a fact that we tend to hire people like ourselves, and the goal is to try and step outside ourselves as an embassador for the company.

I'm surprised that more companies don't have a more formalized interview process.  Quite often, the process is: throw a bunch of people at a person, compare notes at the end of the day, and hope that consensus yields the right answer.  Maybe it does 80% of the time, but that means 2 of every 10 hiring decisions is a bad one.  And when you factor in that we hire people like ourselves, consensus doesn't mean a whole lot.

In my past roles as interviewer, I have usually been tasked with assessing technical skills.  While that isn't completely cut and dried, most of the time it's pretty straightforward.  Many times it's simply answering the question, "Does this individual have the skills to do the job?" and a yes or no answer is all that is required.  The larger challenge is to look beyond wrought knowledge to assess problem solving skills, adaptability, and forethought, and there are very effective ways at doing this.

In case someone is wondering, Microsoft does not recommend interviewers use brainteasers.  However, problem solving questions are fine.  What's the difference?

It's subtle.  Problem solving, in my opinion, involves logic, deductive reasoning, a bit of "street smarts," math, and the courage to make decisions.  Think of some classic questions like, "How many gas stations are there in the United States?"  It's actually an easy question, if you apply a little of the above -- what usually trips people up is having the courage to make guesses.  You need to start with a little logic and make assumptions: it's probably safe to assume the number of gas stations is related to supply and demand, which is directly related to the number of cars.  To estimate the number of cars, you need to start with the population of the U.S.; certainly, a little street smarts and math can get an answer that is reasonably close.  The important part here is the process -- how did you arrive at your answer?

Brainteasers are often perceived as a power play.  They may incorporate some problem solving skills but they often have tricks, a play on words, or other tomfoolery.  They're often a game, and more often than not, there's a single answer.  There's not a whole lot of process to base an evaluation.

I used to really like this question but have since realized it's near useless: "You have 3 light bulbs in room A, controlled by 3 switches in room B.  You can do whatever you'd like with the switches in room B, but you can only enter room A once.  How do you know which switch controls which light?"

Great lunchtime brainteaser... but useful at evaluating someone?  There are better ways.
Comments are closed

My Apps

Dark Skies Astrophotography Journal Vol 1 Explore The Moon
Mars Explorer Moons of Jupiter Messier Object Explorer
Brew Finder Earthquake Explorer Venus Explorer  

My Worldmap

Month List