Microsoft Job Interview Questions

I was interviewed there a few weeks ago and the questions I got were much more related to the team's tasks. Most were coding but a few where design architecture but all were quite relevant (ie no linked list stuff, though there was a BST question).

I think my primary argument is that it's basically impossible to assess "intelligence" at a 30-minute white-board session. There are too many other factors: thinking style, nerves, fear of speaking, etc. But most interviewers will flip the idiot bit if you don't answer their pet algorithm question quickly enough; it can be very difficult to come back from that kind of deficit.

It's usually pretty easy to tell if someone can't code -- you give them a straightforward problem (no "aha" moment required), and make them write the code. If you're really worried about it, give them a phone-screen problem that requires coding, then make them write a variant of the solution during the interview.

For "intelligence" testing, I like to give design problems, since they're far more representative of what will happen on the job. For these, I usually reach back into the grab-bag of recently-solved problems, and ask them to sketch out a solution, then iterate. If their solution is better than my own, that's a win. If it's the same, that's good too. If they just can't come up with something reasonable...well, we have a problem.

But note what you don't see here: there are no situations where I ask a question that requires a moment of algorithmic brilliance. That's just too random. Google can get away with that kind of stuff, because they get thousands of resumes a day, and can't possibly hire every good engineer that applies. For the rest of us, we have to be a bit more intelligent.

I'm not suggesting that it is. The problem is, people are asking much harder questions -- questions that require "aha" brilliance -- and using it as a proxy for intelligence. That's stupid.

Hell...it's not even a deal-breaker if someone has to struggle a little to work out the algorithm for reversing a list, so long as they get it right. The problem is that if you spend more than 5 minutes (or whatever) doing it, 99% of nerds are going to flip the idiot bit on you, and it's time for "Do You Have Any Questions For Me?"

Once you've set up the game such that a candidate has to memorize the answer to "easy" questions to perform, there's no end to the regurgitation that could be required. Before long, people are committing obscure algorithms to memory, because "someone might ask", and they don't want to appear to be stupid. It's a waste of time and energy for everyone involved.

While they seem like pointless questions for some jobs, this list is a conglomeration of questions for the three types of positions (Dev, Test and PM).

The questions are made to be very difficult because the interviewee is supposed to struggle and have to verbalize what he/she is thinking. If the questions are less strange there is the chance that a candidate will have seen them before and know how to solve them off the top of their head. That's only useful for weeding out people who can't program at all. The verbal communication is just as important as actually solving the problem correctly. Microsoft has a pretty high confidence in it's mentoring system, it believes that teaching the actual code is much easier than teaching how to think systematically.

I was given questions that took me > 6 hours to fully complete when I went home and did them. There is no way the interviewers actually wanted all the code, just a discussion.

Some of the "Gotcha" questions are from earlier in Microsoft's hiring practices, so take these lists with a grain of salt. Though they are wicked fun to try to solve them all.

HR at MS is very good at their job. They keep track of everything about who talked to whom.

  (defun strlen (str)
    (loop for i from 0
          for char across str
          finally (return i)))