In-Depth

Inside the Microsoft Developer Job Interview, Part 2 of 3: Tips & Advice on Preparing for and Answering Questions

Part 1 of this series covered what's changed and what you can expect in general (e.g., lots of code). In this second installment, those who've gone before (and who are doing the interviews) give you tips, tricks and advice on exactly what to expect/how to prepare.

• By David Ramel
• July 30, 2010

For more in this series:
- Part 1: What To Expect/What's Changed 
- Part 3: Tips & Tricks for the Interview Itself

So now you know that the old, marathon, brain-teaser-infused Microsoft interviews of yesteryear have been replaced with focused, usually code-intensive interviews. But what do they focus on, and how can you best prepare? Read on.

Expect Open-Ended Questions
Fiona Fung -- a Microsoft lead software design engineer who presented a 2008 webcast targeted at college students titled, "How to Survive the Technical lnterview,"  said Microsoft interviewers often ask candidates open-ended questions that have no clear-cut answers. The goal is not to find a candidate who immediately solves a problem. "That's not that interesting to us because it doesn't show us how you think," she said. Interviewers want to see how a candidate approaches a problem, thinks it out ahead of time and then reasons his way through it while actually coding.

"The whole point of it is to get you to think and get into your thought process," Fung said. An important part of that process, she said, involves candidates being vocal, explaining their reasoning out loud as they work through problems.

Curtis Stuehrenberg, a developer who's been interviewed several times by Microsoft (see first article) has been on the other side of those open-ended questions. "The coding problems will almost always revolve around a theoretical problem or request they'd like to see you solve," he said. "The point to always remember is there is no right or wrong answer so long as the code will do what you claim it does. The primary goal they're attempting to draw out is your work patterns.

"The interviewers will want to see how you approach solving the problem. Do you have a deep enough grasp of the math to understand how to create your own algorithms? How deep is your knowledge of what common libraries are actually doing? If challenged, can you quickly shift gears and attack the problem from a different angle? And probably most important, does it look like you can work collaboratively and take suggestions -- or riff off someone else's ideas -- and build on them?" 

"Carl," a veteran Microsoft program manager, told us, "An interviewer is often looking for how a candidate works through an issue as much as the solution that they come up with. In an ever-changing world, being able to learn and adapt quickly is a huge part of how successful you can be in the tech industry at all, and at Microsoft specifically."

"Joe," an anonymous interviewee, agreed that -- to Microsoft -- the journey is more important than the destination. "A lot of people make the mistake of going out and trying to memorize as many questions as possible," he said. "While it's all well and good that you know the solution, the most important aspect of answering coding questions is your thought process and how you arrived at the solution. So if you've just memorized some answers, you're going to look very robotic and probably aren't going to come across that great to your interviewer."

Algorithms, Algorithms and More Algorithms
From all accounts, the coding problems usually involve algorithms, linked lists, traversals, arrays and such. Fung said the questions typically are tailored to the position being sought the big three being software development engineer (SDE), software development engineer in test (SDET) and program manager (PM). But a big mistake, she said, is to go for a PM position to escape the burden of having your coding abilities tested. "Everybody is expected to code," she said.

Interviewers for each position, she said, might try to find different information, such as the following:

• SDE: How performant is the code? Do you catch boundary exceptions? What kind of algorithms do you use? Do you use the most performant algorithm? Can you talk about the different kinds of algorithms that you could have used?

• SDET: After writing the code, how do you go about testing it? Do you do the black-box testing or the white-box testing? Do you find all boundary cases? What are some interesting test cases? Can you identify interesting areas to explore further?

• PM: Focusing on the initial design, what questions do you ask to make sure you get the right design? (Keeping in mind that there is great variety in the amount of technical expertise needed for different PM positions, with API design, for example, requiring much more coding than a PM who does mostly scheduling.)

Microsoft's Coding Questions Revealed
The algorithmic problems can take all shapes and sizes. Getting into specifics, Artashes (a previous Microsoft interviewee who declined to have their last name published) shared the details of one of his assignments: "They ... asked me a ‘maze' problem and how would I solve it. You're given a maze and a rat at some location and the rat has some limited abilities, it can turn and it can move forward. The maze is an MxN rectangle and there are some walls, and there is an exit. Your task is to develop an algorithm to take the rat from a given location to the exit."

On his Web site, Joe reported being assigned the following tasks during his visit:

• Write a function that takes a seven-digit telephone number and prints out all of the possible words or combinations of letters that can represent a given number.

• Write a function to reconstruct a chain of linked nodes that has been severed. Each node is missing the link to the node that it's supposed to point to, but contains the value of the node that points to it.

• Write a function to delete a node from a binary search tree.

Of course, other real Microsoft interview questions are all over the Web. Typically, they resemble these, provided by a poster on the JobsBlog earlier this year:

• Split a linked list into elements above and below the average of the list.

• Print the numbers 1..n^2 in a spiral, with 1 in the center and going outward.

• Write an algorithm to find the common ancestor of two nodes in a binary search tree.

• Print the permutations of a C string.

Getting Shot Down: Preparation Advice from the Front Lines
Unfortunately, Artashes didn't get the job. He explained: "The feedback was that fundamentally all my answers (including algorithmic) were correct, but as far as I understand they were not satisfied with my coding skills. Indeed, I did not manage to finish one pretty simple coding task in the given time quota, though there were other tasks which I coded well."

Joe didn't get a Microsoft job either. "The biggest factor in me not being offered was my technical performance," he said. That performance "wasn't horrible, but it was also far from perfect," he said.

To avoid their fate, you likely need to prepare like you've never prepared in your life. Joe had some specific advice for Microsoft candidates to pass along to our readers.

"What I recommend people do is buy a whiteboard to do coding questions on and set a time limit for each problem you do," he said. "This will simulate the pressure of having to answer the question on the spot and will get you used to the somewhat awkward task of writing code on a big whiteboard. Work on your approach to problem solving and devise a method that you feel comfortable with. If you do this, you'll feel a lot more confident during your interviews than if you had gone out and memorized a bunch of solutions."

Artashes offered advice along the same lines. "They will ask you to code a specific problem during all the interviews, so make sure you practice coding as much as possible," he said. "If it's going to be an on-site interview, make sure to practice coding on a piece of paper or a whiteboard if possible."

Being comfortable with coding on the whiteboard or piece of paper is likely to be crucial for any chance of success and could prevent disaster. Fung said the unusual technique often trips people up because they aren't used to it. She has even seen candidates "freeze up" in interviews when asked to code that way.

Fung also had some algorithmic advice on how to prepare for the coding questions. "If you're going over the sorting algorithms, write out each sorting algorithm or solve different sorting algorithms," she said. "It's not enough to just brush over the chapter 15 minutes before your interview. Make sure you're ready to go right when you go into the interview room." She said students' textbooks were a good source of study material.

For those out of college, Artashes suggested other reading. "I'd recommend [the books] Introduction to Algorithms (CLR), and be sure to code the exercises. For C++ -- as always -- I recommend [reading] at least, Effective C++, More Effective C++ and Effective STL."

But if time is short, Carl provided some contrarian advice. "Don't prepare," he said. "Be yourself. If you're not a fit for Microsoft, no amount of preparation in the days before an interview will help; and if you are a fit, that will come through in the interview."

Be sure to read Part 1 of this series "What to Expect/What's Changed," and and click here for Part 3, which will cover tips and tricks for the job interview itself.