6 ms·

Microsoft Job Interview Questions

15 points by techdog 17y ago

riferguson 17y ago
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.
- timr 17y ago
  "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.
  - ambition 17y ago
    "Gets-things-done" people prepare for technical interviews, such that they don't flub simple questions. The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers. "Interview for Smart and Gets Things Done" is an accurate explanatory abstraction over what good interviewers do, but it's not prescriptive enough to tell people what questions to ask and how to judge the results.
    - timr 17y ago
      "'Gets-things-done' people prepare for technical interviews, such that they don't flub simple questions." So, let's be clear: you're admitting that you're screening for a trait that you assume is correlated with the trait that you actually want. I don't grant the assumption, but it should at least be explicitly stated. "The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers." How many computer science PhDs have you hired, let alone interviewed? I'd wager that it's not enough for you to be able to make this judgment with any confidence. And even if you're right, how does asking questions about linked-list reversal address the question of the tendency of a person to do practical work? Aside from tech interviews, I've never once in my life had to write a linked-list reversing routine. Look, I'm not saying "don't ask coding questions" -- I'm saying that we need to start being reasonable. Don't assume that a candidate is a no-hire simply because that they haven't pre-memorized the algorithms for the questions that you're asking. It's ridiculous that we're screening people based on the number of silly tricks that they can memorize from interview question websites.
      - ambition 17y ago
        I think by and large we agree: It's wrong to expect memorized answers or to ask questions that are so narrow that they only test whether a candidate spent time studying. I'd even go so far as to say that algorithmic questions are probably not good indicators for skill at many kinds of work we would call "programming"---i.e. Programming skill is more heterogeneous than many interviewers admit. We shouldn't expect a jQuery wiz to nail low-level data structure questions, and we shouldn't expect a bit-twiddling video codec developer to really grok method chaining in 30 minutes. The trouble with "Be reasonable" is that's it's the advice equivalent of a tautology. Of course we should be reasonable when interviewing. But I don't think there's widespread agreement about how to operationalize that. I'd be curious for more detail about how you would do it---you seem to have strong, well-informed feelings on this issue. To my knowledge, there's basically no publicly-available research on tech interview factors and how they correlate with on-the-job performance. The good big employers do this research internally and keep it to themselves. The rest of us are stuck with assumptions, intuitions, logic and argument. So unfortunately I don't think we'll be able to get the debate into the realm of interpreting real data anytime soon.
- arethuza 17y ago
  I don't know how it works in the US, but in the UK a PhD is usually awarded based purely on research - there is relatively little cutting edge research that I am aware of that hinges on manipulating linked lists. :-)
Locke1689 17y ago
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).
- deleted 17y ago
  [deleted]
RyanMcGreal 17y ago
>How would you explain what a database is to a 5-year-old? >How would you explain computer networking to a kindergarten kid? I have had to answer both of these questions - but to an actual five-year-old, not to recruiters.
Zak 17y ago
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.
- ambition 17y ago
  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.
  - th0ma5 17y ago
    sort of trivial in python with just statements: i=0 for x in thestring i+=1 print i
- scdlbx 17y ago
  Then don't write it in Lisp or Haskell. If they don't specify a language, use one that makes sense.
- msg 17y ago
  (defun strlen (str) (loop for i from 0 for char across str finally (return i))) Works in my emacs... I (require 'cl).
  - Zak 17y ago
    I suppose everything you called is a special form. It should have occurred to me that the loop macro could do it. Is the Loop macro Turing complete?
- Locke1689 17y ago
  Doesn't seem all that tough to me my_len_acc :: [a] -> Int -> Int my_len_acc [] so_far = so_far my_len_acc (_:xs) so_far = my_len_acc xs $ so_far + 1 my_len :: [a] -> Int my_len some_str = my_len_acc some_str 0
ambition 17y ago
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.
- arethuza 17y ago
  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?
  - ambition 17y ago
    It's a good idea, and I think it would make an excellent supplement to current interview practices. There would be some difficult logistical issues: Unfamiliar dev environment, etc. It wouldn't replace whiteboard coding, since you lose the ability to test for culture fit, give hints, examine thought process, ask about small decisions, get a gut check and other aspects of whiteboard coding that have nothing to do with the specific question asked. Some companies ask for a small code sample "that you're proud of" in advance of onsite interviews, I think that's another good practice.
msg 17y ago
My problem with the coding questions (other than the fact that everyone has seen them) is that they're too shallow. So the questions are binary. If you can't do them, interview over, sure. But if you can do them they don't say that much. They're almost short enough to count as trivia. I prefer asking for a program that will take about an hour, but will also get a range of correct answers and mistakes. The ideal question has maximum dispersion, like a good hash function. You can observe a variety of strengths and weaknesses, and the horrible candidates will cry, the mediocre candidates will cringe, the good candidates will nod, and the strong candidates will laugh.
- ambition 17y ago
  Could you give some concrete examples of the sorts of programs you mean?
  - msg 17y ago
    I give you a file of words, one per line, which may contain duplicates. Output the words in sorted order, removing duplicates, with a count of the number of times it appeared in the original file. Your program should be small and efficient. So there's file I/O, string matching, string storage, counting probably means a simple data structure, and there's formatted output to print the number of occurrences. You can also ask deeper questions, such as the big-O of the algorithm/data structure they come up with, and what happens if the file is too large to load in main memory. Perl programmers (for example) will laugh at this question, but in my experience that puts them ahead of the rest of the interviewing pack. I ask a similar question in my interviews that has some simple math instead of strings. I don't demand that my interviewees can remember the name of every library function, but if there's too much handwaving I get suspicious.
bmalicoat 17y ago
This is a pretty baseless post. Like riferguson said, the questions span many disciplines hence some are technical and other are very broad. The OP is wondering if Microsoft's practices work? No, no company is hiring 100% coding geniuses all the time. However, Microsoft, despite their public appearance sometimes, always has some of the smartest programmers and researcher alive today working for them. 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).
chris123 17y ago
Aren't these questions mostly a way to trim the prospect pool to a size that you can do "real" interviews with? ("Real interviews" are the interviews after the ones in which you get asked these kinds of questions).
eclark 17y ago
Having been through this I can give a little insight. All the questions are from the interviewer. There is no MS book of interview questions. Each person asks whatever they feel like at the time. 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.

15 points by techdog 17y ago

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.

timr 17y ago
"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.
- ambition 17y ago
  "Gets-things-done" people prepare for technical interviews, such that they don't flub simple questions. The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers. "Interview for Smart and Gets Things Done" is an accurate explanatory abstraction over what good interviewers do, but it's not prescriptive enough to tell people what questions to ask and how to judge the results.
  - timr 17y ago
    "'Gets-things-done' people prepare for technical interviews, such that they don't flub simple questions." So, let's be clear: you're admitting that you're screening for a trait that you assume is correlated with the trait that you actually want. I don't grant the assumption, but it should at least be explicitly stated. "The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers." How many computer science PhDs have you hired, let alone interviewed? I'd wager that it's not enough for you to be able to make this judgment with any confidence. And even if you're right, how does asking questions about linked-list reversal address the question of the tendency of a person to do practical work? Aside from tech interviews, I've never once in my life had to write a linked-list reversing routine. Look, I'm not saying "don't ask coding questions" -- I'm saying that we need to start being reasonable. Don't assume that a candidate is a no-hire simply because that they haven't pre-memorized the algorithms for the questions that you're asking. It's ridiculous that we're screening people based on the number of silly tricks that they can memorize from interview question websites.
    - ambition 17y ago
      I think by and large we agree: It's wrong to expect memorized answers or to ask questions that are so narrow that they only test whether a candidate spent time studying. I'd even go so far as to say that algorithmic questions are probably not good indicators for skill at many kinds of work we would call "programming"---i.e. Programming skill is more heterogeneous than many interviewers admit. We shouldn't expect a jQuery wiz to nail low-level data structure questions, and we shouldn't expect a bit-twiddling video codec developer to really grok method chaining in 30 minutes. The trouble with "Be reasonable" is that's it's the advice equivalent of a tautology. Of course we should be reasonable when interviewing. But I don't think there's widespread agreement about how to operationalize that. I'd be curious for more detail about how you would do it---you seem to have strong, well-informed feelings on this issue. To my knowledge, there's basically no publicly-available research on tech interview factors and how they correlate with on-the-job performance. The good big employers do this research internally and keep it to themselves. The rest of us are stuck with assumptions, intuitions, logic and argument. So unfortunately I don't think we'll be able to get the debate into the realm of interpreting real data anytime soon.
arethuza 17y ago
I don't know how it works in the US, but in the UK a PhD is usually awarded based purely on research - there is relatively little cutting edge research that I am aware of that hinges on manipulating linked lists. :-)

Locke1689 17y ago

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).

deleted 17y ago
[deleted]

RyanMcGreal 17y ago

>How would you explain what a database is to a 5-year-old? >How would you explain computer networking to a kindergarten kid? I have had to answer both of these questions - but to an actual five-year-old, not to recruiters.

Zak 17y ago

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.

ambition 17y ago
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.
- th0ma5 17y ago
  sort of trivial in python with just statements: i=0 for x in thestring i+=1 print i
scdlbx 17y ago
Then don't write it in Lisp or Haskell. If they don't specify a language, use one that makes sense.
msg 17y ago
(defun strlen (str) (loop for i from 0 for char across str finally (return i))) Works in my emacs... I (require 'cl).
- Zak 17y ago
  I suppose everything you called is a special form. It should have occurred to me that the loop macro could do it. Is the Loop macro Turing complete?
Locke1689 17y ago
Doesn't seem all that tough to me my_len_acc :: [a] -> Int -> Int my_len_acc [] so_far = so_far my_len_acc (_:xs) so_far = my_len_acc xs $ so_far + 1 my_len :: [a] -> Int my_len some_str = my_len_acc some_str 0

ambition 17y ago

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.

arethuza 17y ago
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?
- ambition 17y ago
  It's a good idea, and I think it would make an excellent supplement to current interview practices. There would be some difficult logistical issues: Unfamiliar dev environment, etc. It wouldn't replace whiteboard coding, since you lose the ability to test for culture fit, give hints, examine thought process, ask about small decisions, get a gut check and other aspects of whiteboard coding that have nothing to do with the specific question asked. Some companies ask for a small code sample "that you're proud of" in advance of onsite interviews, I think that's another good practice.

msg 17y ago

My problem with the coding questions (other than the fact that everyone has seen them) is that they're too shallow. So the questions are binary. If you can't do them, interview over, sure. But if you can do them they don't say that much. They're almost short enough to count as trivia. I prefer asking for a program that will take about an hour, but will also get a range of correct answers and mistakes. The ideal question has maximum dispersion, like a good hash function. You can observe a variety of strengths and weaknesses, and the horrible candidates will cry, the mediocre candidates will cringe, the good candidates will nod, and the strong candidates will laugh.

ambition 17y ago
Could you give some concrete examples of the sorts of programs you mean?
- msg 17y ago
  I give you a file of words, one per line, which may contain duplicates. Output the words in sorted order, removing duplicates, with a count of the number of times it appeared in the original file. Your program should be small and efficient. So there's file I/O, string matching, string storage, counting probably means a simple data structure, and there's formatted output to print the number of occurrences. You can also ask deeper questions, such as the big-O of the algorithm/data structure they come up with, and what happens if the file is too large to load in main memory. Perl programmers (for example) will laugh at this question, but in my experience that puts them ahead of the rest of the interviewing pack. I ask a similar question in my interviews that has some simple math instead of strings. I don't demand that my interviewees can remember the name of every library function, but if there's too much handwaving I get suspicious.

bmalicoat 17y ago

This is a pretty baseless post. Like riferguson said, the questions span many disciplines hence some are technical and other are very broad. The OP is wondering if Microsoft's practices work? No, no company is hiring 100% coding geniuses all the time. However, Microsoft, despite their public appearance sometimes, always has some of the smartest programmers and researcher alive today working for them. 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).

chris123 17y ago

Aren't these questions mostly a way to trim the prospect pool to a size that you can do "real" interviews with? ("Real interviews" are the interviews after the ones in which you get asked these kinds of questions).

eclark 17y ago

Having been through this I can give a little insight. All the questions are from the interviewer. There is no MS book of interview questions. Each person asks whatever they feel like at the time. 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.