Microsoft was my first employer after college, via a contract assignment that quickly turned into a full-time role; I stayed a little under 7 years. My circumstances are unusual, because I started during the dot-com boom, and had no formal computer science background; I was attractive for my (natural) language skills combined with technical competence built over a childhood (and early adulthood) of experimentation with computers, when Microsoft was investing a great deal of energy into internationalizing and localizing Internet Explorer.
Given my background, getting noticed by HR would have been the biggest hurdle; the agency temporary role made that easier, since I was introduced by a hungry third-party. The "bar" for hiring an agency temporary is usually considered lower, and usually there's slightly smaller number of interviews, and managers are willing to take more risks on people that they consider disposable.
For anyone with better paper qualifications, is it "difficult?" Based on the sheer number ratio of initial contact to actual hire, you could say yes. But is it more difficult than any other technology company? I can't say that it is. The interview process at Zillow was fairly similar (though the history of the execs there makes that unsurprising). Interviews tend to be fairly technical. Elsewhere, I've received job offers on the merits of what Microsoft would have considered a phone screen, and I've experienced pretty substantial differences on how deep the technical interview was. In most of my recent jobs outside of Microsoft, which presumed a fair amount of experience, I've been able to talk through matters of development practices and philosophy that reveal more to the interviewers in 15 minutes than an hour of a coding exercises would have been, and the coding questions have been minimalist or occasionally nonexistent.
It's unlikely that at Microsoft you'd answer less than 3 substantial whiteboard coding questions during a four person interview loop, even if you were considered a rockstar, and even if you've been employed there before. This is mostly for cultural reasons.
Although we liked to think we weren't so arbitrary as interviewers, one team might think you a good hire and another might not see your merits at all, so a hire/no-hire decision can seem capricious and arbitrary, especially if you've been on either the hiring or interviewing side more than once.
However, if you're intelligent, can code reasonably well under the pressure of a whiteboard, and you can think through problems big and small, you'll have a reasonable chance of making it through the interview process. It's not "difficult" if difficult problems don't freak you out, and simple problems don't catch you off guard.
If you go to an interview there are things that can increase your chances of success:
- Be able to write the basic operations of linked lists, trees, and other classic data structures; understand at least one sorting algorithm well enough to be able to write it on the fly with potentially unexpected constraints.
- Knowing your time constraints (usually about 10-15 minutes for a typical coding question), ask clarifying questions before you get started; write a minimalist solution as quickly as possible; explain your thoughts while you write code; explain how your code works; explain how it handles, or fails to handle, error conditions. Be able to explain what you would do to improve the code given more time or different project needs.
- Be prepared to discuss micro- and macro- design decisions, for systems you've implemented before, and hypothetical projects whose requirements are made up on the fly by interviewers.
- Read Skiena's book, The Algorithm Design Manual, so that you'll be able to pattern match problem statements given by your interviewer, and suggest appropriate data structures/algorithms that can help with those problems. You probably won't be expected to write a kd-tree implementation or vertex-coloring algorithm on the whiteboard, but you should know when they would help.
- Read the GoF patterns book and the Patterns of Enterprise Application Architecture book, and be able to suggest appropriate application of those patterns to an arbitrary problem.
- Be prepared, when your interviewer proposes an alternate solution to a problem you discuss, to discuss the tradeoffs between your solution and theirs. Most interviewers love to see you challenge them, if you do so politely with good justifications. (Some will intentionally propose poor solutions to see how you react).