

Microsoft Job Interview Questions - techdog
http://asserttrue.blogspot.com/2010/03/microsoft-job-interview-questions.html

======
riferguson
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
_"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.

~~~
gjm11
Reversing a linked list is not an Alan-Turing-level problem.

I've used the reverse-a-list problem (and others of a broadly similar kind) in
interviews. It shouldn't matter at all if a candidate hasn't read or written
any list-manipulation code in years; that gives them the chance to sit and
scribble some diagrams for me and work out how to do it. I don't mind much if
they don't end up with a beautifully neat solution. I want to know things
like: Did they check for edge cases? Did they blunder around trying things
until they got code they couldn't prove was wrong, or did they work out
something that ought to work and then implement it, or what? Did they ask
themselves questions like "what facts ought always to be true at this point in
the code?"? If they produce an inelegant or inefficient solution and I say "So
what happens if you do X?" or "Could you do anything about Y?", do they panic
and freeze or do they get thinking about the question? These are _not_ a
matter of having crammed their heads with algorithm esoterica. They're a
matter of being reasonably comfortable with code, and being a problem-solver
rather than a copy-and-paste artist.

I'm quite sure there are plenty of software developer jobs that can in fact be
done by someone who's fundamentally not very comfortable thinking about code,
and/or who has little interest in problem-solving or little aptitude for it.
It happens that those aren't the jobs I've interviewed people for, but they're
real enough and collectively they probably account for a majority of the value
added to society by software development. But when you're interviewing for a
job that does call for independent thinking and fluent code reading and
writing, that sort of question -- if used correctly -- is very valuable.

Of course, an interviewer who thinks the point is to say "Write me some code
that reverses a linked list" and then vote yes if the candidate does it on the
spot and no otherwise, is going to reject some good candidates and accept some
bad ones. But an interviewer who thinks that way is going to get lousy results
regardless.

~~~
timr
_"Reversing a linked list is not an Alan-Turing-level problem."_

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.

~~~
gjm11
Well, FWIW, when I've asked people "write me code to reverse a list", I've
simply assumed that unless the candidate is a real superstar it'll probably
take them a while to get to a working solution, and I'm happy to give them
some help along the way. I completely agree that an interviewer who expects a
correct solution within a few minutes (even to a relatively simple problem
like that one) is being dumb and helping to make the world a worse place.

As for "aha! brilliance", the trouble with that is that the variance is so
large; someone very good may well take a while, and someone not so good may
well happen to get there quickly.

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

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

------
ambition
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
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
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
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
Could you give some concrete examples of the sorts of programs you mean?

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

------
RyanMcGreal
>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
_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.

~~~
Locke1689
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

~~~
Zak
$ and + are built-in functions being used with infix syntax.

~~~
Locke1689
Without such built-in functions like application or arithmetic this is
impossible in every language.

Consider: without application you cannot consider such a language general
recursive and therefore it is not Turing complete according to the Church-
Turing thesis.

~~~
Zak
Hence my claim about the near-impossibility of the task.

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

