Live data from Hacker News

Microsoft Job Interview Questions

asserttrue.blogspot.com

1–10 of 36 posts

Re: Microsoft Job Interview Questions

#2
Three things:

First, those are questions for a variety of different positions all mixed together. Product manager candidates get asked different questions than engineering candidates.

Second, yes, Microsoft tracks the effectiveness of interviewers based on the outcome of the interview loops and the performance of the people who get hired.

Third, all of the questions listed, no matter how trivial they seem, are dispositive. I've interviewed engineering candidates with PhD's from top tier universities who couldn't reverse a linked list when asked, or who couldn't even explain basic concepts in their putative focus areas. You have to ask the seemingly stupid stuff -- it's a continual surprise.

Full disclosure: no, I don't work there now. Yes, I used to, a very long time ago.

Re: Microsoft Job Interview Questions

#3
I don't know what the author wants from Microsoft. I don't know about the other questions, but the technical questions seem fine. What does he want them to know if not how to do a preorder traversal without recursion? Name some obscure feature of Microsoft SQL? That will get you people who know specific pieces of software well, not good programmers. A good programmer should be able to quickly develop complex algorithms, irrespective of the environment or language. Everything else is pretty secondary to that.

I can tell you that my hardest question from my interview was developing an algorithm to get the greatest increasing subsequence from a sequence of integers. Will all good programmers be able to solve this? No, probably not. Will all the people who solve this be good programmers? Probably more likely. Microsoft is trying to find the best of the best and asking tough questions will get you much farther than random knowledge questions (which can be picked up in an afternoon with Google and documentation anyway).

Re: Microsoft Job Interview Questions

#4

I don't know what the author wants from Microsoft. I don't know about the other questions, but the technical questions seem fine. What does he want them to know if not how to do a preorder traversal without recursion? Name some obscure feature of Microsoft SQL? That will get you people who know specific pieces of software well, not good programmers. A good programmer should be able to quickly develop complex algorith…

[deleted]

Re: Microsoft Job Interview Questions

#5

Three things: First, those are questions for a variety of different positions all mixed together. Product manager candidates get asked different questions than engineering candidates. Second, yes, Microsoft tracks the effectiveness of interviewers based on the outcome of the interview loops and the performance of the people who get hired. Third, all of the questions listed, no matter how trivial they seem, are dispos…

"Third, all of the questions listed, no matter how trivial they seem, are dispositive. I've interviewed engineering candidates with PhD's from top tier universities who couldn't reverse a linked list when asked, or who couldn't even explain basic concepts in their putative focus areas. You have to ask the seemingly stupid stuff -- it's a continual surprise."

While there are certainly idiots with PhDs, if you've got a candidate with a PhD from a top-tier institution who "can't reverse a linked-list", it's most likely because (s)he is under-prepared at the art of technical interviewing. Idiocy is clearly not impossible, but the conclusion that the candidate is an idiot should be on the low-prior-probability event list.

One thing that drives me absolutely crazy about technical interviews today is that most interviewers have completely lost the bubble on what they're trying to accomplish. It's become a bizarre, nerdy form of Kabuki theater, wherein candidates are madly trying to cram their heads full of list- and string-algorithm esoterica, while hoping that they're not presented questions so unfamiliar that they can't derive the answer in under 30 minutes, at a whiteboard. If the interviewer doesn't take this into account (and few do), the interview becomes little more than a random, high-pass screen, wherein lots of smart people are eliminated from positions based on bad luck, and little else.

Joel (on Software) has it right, but it seems like few people are listening: you want to make sure the candidate is smart, and can get things done. That's it. The goal is not to see if they're the next human incarnation of Alan Turing, and it's certainly not to see if they can derive fiendishly difficult algorithms during a whiteboard lecture (call me crazy, but I'm reasonably sure that Turing didn't come up with his theories while talking continuously in front of a whiteboard, while some asperger-y geek sneered at him from across the room.)

When you're interviewing, you want to make sure that the candidate can write code, that they're reasonably smart, and (IMHO) that they're not an asshole. It seems to me that our industry has taken "coding puzzle" and turned it into "crappy intelligence test", while largely ignoring the "not an asshole" part of the equation -- the part that's usually the most important in real life.

Re: Microsoft Job Interview Questions

#7
Write code that returns the length of a string without using any built-in functions.

It took me a while to realize that they're probably not counting infix operators that behave like functions except for the syntax. Accomplishing this task in Lisp or Haskell would be nearly impossible.

Re: Microsoft Job Interview Questions

#8
I've been asked some of those questions at other top-tier tech companies (that the author isn't criticizing).

Conducting good interviews is hard. Watching someone attack a problem or write some whiteboard code is a not-bad system. Pick a problem that's too small or familiar and you're not filtering enough. Pick problems that are too hard or long and nobody will succeed. It's a balancing act.

Re: Microsoft Job Interview Questions

#9
post #7

Write code that returns the length of a string without using any built-in functions. It took me a while to realize that they're probably not counting infix operators that behave like functions except for the syntax. Accomplishing this task in Lisp or Haskell would be nearly impossible.

That's disingenuous. When they say "no built-in functions", they really only mean "don't use a library function that makes this task trivial." Which eliminates 'strlen' in C, 'length' in Haskell, 'len' in Python, etc.

Re: Microsoft Job Interview Questions

#10
post #8

I've been asked some of those questions at other top-tier tech companies (that the author isn't criticizing). Conducting good interviews is hard. Watching someone attack a problem or write some whiteboard code is a not-bad system. Pick a problem that's too small or familiar and you're not filtering enough. Pick problems that are too hard or long and nobody will succeed. It's a balancing act.

I don't know about you, but writing code standing up at a whiteboard while others watch just doesn't feel very natural to me.

Why not give them a PC and a small development task and leave them alone for a bit and then talk over their solution once it is complete?

Post reply on HN