Inside the Microsoft Developer Job Interview, Part 3 of 3: Tips & Tricks for the Interview Itself

Microsoft hiring managers and interviewees share inside advice for nailing the interview process.

For more in this series:
- Part 1: What To Expect/What's Changed 
- Part 2: Tips & Advice on Preparing for and Answering Questions 

So now you know what to expect, you've got your coding skills down and are well prepared for whatever the 'Softies may throw at you. So what do you do when it's go-time and you're face-to-face with an interviewer?

Show Initiative
Fung, who just might be one of those interviewers, presented some specific tips: "What I like to see is someone take several passes of their solution. It shows me a lot when you take the time to go back through your code of your own accord without me having to ask you, ‘O.K., let's debug with these boundary cases. Does it work in all cases?' If you take your own initiative to do that, that's actually really cool. So after you write out your solution, think from the technical perspective, ‘What are the boundary cases?' and talk about them out loud and walk through your own solution in front of the recruiter to show them you debugging your own code—and a lot of times you'll find a lot of your own bugs that way."

Fung had additional advice for each of the three main positions:

  • "For a dev, it's also really cool if they do a third pass, which is the performance one. Think about ‘How can I change this code to make it more performant?'"
  • "For test, it's cool to go into the more in-depth testing question or think about ... can you change your code and write it so it's easier to test, to increase testability?"
  • "For PMs [project managers], a lot of times we go back to requirements. [Build] your solutions, solve all your requirements—and can you think about future requirements that I might not have asked you right now; and how do you design the API or the algorithm to make it flexible so that you can add more in the future, if you need to?"

"Carl," whom you also might run into, offered this advice for job seekers during the actual interviews:

  • "If you need more information to answer a question, ask for it. That's how the real-world works and many questions are intentionally vague to simulate just this kind of interaction."
  • "Try to answer non-technical questions based on your personal experience. For example, instead of saying ‘Here's how I would deal with that situation,' say, ‘I had a similar situation in my past and here's how I dealt with it.' Even if your interviewer doesn't phrase his questions in that way, for example, ‘Give me an example of how you dealt with a situation like blah,' it's helpful and impressive if you can use your own history to pull out a positive result."
  • "Make sure you ask questions. Working at Microsoft isn't just a job, it's a way of life, so make sure you're sure you want the team and the job for which you're interviewing."

And finally, it might pay off to make an impression toward the end of the interview. Stephanie Clark, an interview strategist/coach, told us interviewees need to some degree "take the bull by the horns and steer part of the interview." As it's drawing to a close, she said, make sure to ask, "Is there anything else that you need to know about me to build my case for being one of the leading applicants for this position?"

"Asking this question (rephrase it to suit your communication style) ensures that no stone is left unturned, no question left unanswered, nothing left to chance. It gives you the opportunity to fill in any gaps," explained Clark.

Mistakes You Don't Want to Make
Now you what to do in the interview, but you also need to know what not to do. Some common pitfalls Fung has seen with coding questions include:

1, Not taking time to think about the problem and not asking clarification questions.
"I've ... seen a lot of cases where students just run off the moment I give them the technical problem, not asking me any questions, and they end up solving the wrong problem. That's the worst thing."

2. Not being specific enough in your answers.
"I might ask a PM, ‘How would you go about designing this API?' If they end up being very general, it doesn't help me. [I have to ask myself,] ‘Wait, do they really understand the question?' "

3. Not answering the question being asked.
"Surprisingly ... that does happen quite a lot. Sometimes I'll ask a linked-list question, and they end up solving something completely different, not even bothering to ask me, ‘Is this what you're looking for?' Make sure you do take a step back, and ... ask questions and think out loud."

4. Assuming that one or two answers is enough for open-ended questions.
"Definitely don't ever feel like you'll take up too much time or you'll seem too silly asking too many questions. Of course, don't go in there thinking, ‘I'm going to ask lots of questions to prove to them that ‘I'm going to succeed at this interview.' I don't want you ... to start running out and just start asking questions just for the sake of asking questions."

5. Answering questions in the way you "think" your interviewer wants you to answer them.
"Be confident in your own thought process and how you solve questions. Don't ask things thinking ... ‘Oh, this is something that they'll want to hear me ask.' "

6. Not describing the solution while you're writing it.
We want to see how you think through the process. "Be able to think out loud. It's a very common pitfall that someone just starts writing, and it's hard for me to see how they're thinking about the problem."

7. Being silent if you're stuck.
"If you end up having a brain freeze, or you're really having a hard time finding the right algorithm, tell the recruiter. For example, for sorting questions, a lot of the time there are different algorithms that you can use. If you know you want to use a different one that's more performant, but somehow you have a brain freeze and you can't find the solution, talk about ... all the other solutions. If you do know the more basic one, maybe code up the basic one first and then build on top of that."

Beyond the Code Questions
And even with the emphasis on coding, don't forget about the more traditional interview, a.k.a. the "behavioral" questions. Stuehrenberg said, "You will be asked the usual interview questions such as, ‘Is there any time you feel you failed, and can you tell me about it?' "

Artashes was asked a version of the "tell me about a conflict at work" question. "I personally think this type of question only verifies that the candidate is serious about the interview and does not verify any real skills. After all, if you tell them a fantastic story and pretend [to be] a hero, nobody will ever verify the information you provided—it's all about interviewing skills," he said.

Carl said he uses the conflict question, and others such as, "Tell me about a time when you had too much work to do in the time you were given. How did you resolve that issue? What was the result? What did you learn?"

"The core idea of behavioral interviewing," Carl said, "is that past behavior indicates future behavior, so instead of asking people things like ‘How would you deal with such-and-such?' you ask them, ‘How have you dealt with such-and-such in the past?' This forces them to find a matching scenario and you get to see if they way they dealt with the issue in real life matches what you want from a team mate in that job."

Fung said she asks those types of questions "because I'm interested to see how you interact with your team and how you go about [dealing with] with conflicts and resolutions, etc."

Other Qualities
'Softies have other tricks up their sleeves beyond coding problems and behavioral questions. Fung said recruiters will be watching for other things throughout an interview. One thing they'll look for, she said, is the ability to learn things and apply them later as you go from interview to interview.

Stuehrenberg said, "If you're interviewing for a leadership position (for example, lead, senior lead, architect, etc.), you should expect at least one person from a different department to be part of your interview cycle. These people will be gauging your grasp of process issues and ability to interact with the other teams." 

Hang In There
Throughout the process, don't get discouraged. While Microsoft has a sterling reputation for treating applicants well ("They are ... the most generous to their interview candidates," said Joe, who should know), Stuehrenberg at times found the application process frustrating. "By the time I received my official notification of a start date, I had dealt with at least six completely different and unconnected departments within Microsoft, not counting the one for which I hoped to be working," he said.

He dealt with myriad people, from the initial recruiter to others responsible for paperwork, scheduling, negotiating, orientation planning, background checks and more.

Candidates, he said, "should understand that [landing] a full-time job at Microsoft will usually take over a month from the time of your initial phone screening to the start of your first day's orientation, and that's assuming expedited hiring that just happens to align with an orientation class (only occurring on Mondays) that has room." More likely, he said, the process will take up to two months or more.

A small price to pay for joining the elite. While much has been made of Microsoft losing coding talent to companies such as Google and various open-source projects, it's going to be a major player in all things software-related for quite a while, and dev jobs there are still highly coveted.

And it can be a lot of fun. Just ask Thom Mitchell, a recent hire who documented his experiences on the JobsBlog. He started out by saying, "Microsoft has a legendary reputation as a difficult place to interview, but a great place to work."

After he detailed his arduous journey through the interview process, he concluded: "If you think the interviews are challenging, wait until you have to start absorbing all information that Microsoft throws at new hires. The phrase that everyone uses is "drinking from the fire hose." I'm not sure if it is a fire hose or if it is a 72 inch water main inundating you with so much information that your head overflows. Either way, I'm having the time of my life in a dream job and I'm still ecstatic that they hired me."