Oct 15
Interviews at MS
Check out this recent story about a developer interview at Microsoft. I know Igor through a mutual friend back in Georgia. Igor came up to Redmond for a conferece a few years ago when I was still there. He reminded me of me – enthralled with everything Microsoft and willing to work to make himself an expert so he’d have a chance to work for the empire. After I read this recent post about his interview with Microsoft, he reminded me even more of myself! My first interview at Microsoft went badly as well.
This was a long time ago, not long after I was out of college. The year must have been early 1997 when I was really into Microsoft technology and programming. I spent all of my commuting time on the bus reading programming books. I spent much of my reading time before bed reading programming books or a subscription to MSDN magazine. With this rate of information intake, I became one of the top programmers at my company pretty quickly, but I was still unprepared my interview at Microsoft.
I expected my interview at Microsoft to concentrate on high level technologies like MFC and COM, which I’d pretty much mastered. Indeed, when I did get asked questions about COM, I knocked them out of the park and the interviewer was outwardly impressed. However, the rest of the interview, say 90% of it, was just straight C programming. It’s hard for me to remember the exact questions I got, but here are some:
- Reverse the words in a sentence. This was pretty tough for me at the time, since it required careful attention to pointers. Today, it’s a piece of cake. I eventually got it, but my solution wasn’t impressive or quick.
- Write a function to convert a number to a string and a string to a number. I did decently on this, but nothing to impress according to Microsoft standards.
- Write a function to reverse the bits in a byte. This one I completely flunked. I stood in front of the whiteboard for a long time, just silent, with no help from the interviewer. At the time, I felt like an idiot, but in retrospect, I suspect he had no idea what to do with me either. I gave a ton of interviews at Microsoft myself, and I would have been ashamed to behave as this interview did. Regardless, I’m sure he wasn’t happy with my performance and I didn’t get the job. But, even worse, I left not really wanting the job.
About three years later, I got the chance to interview again and this was when I landed my job at Microsoft. I was way more seasoned as a programmer (I still regard GeoGraphix as the best programming job I’ve ever had), and I knew what to expect. In short, I crushed this Microsoft interview. However, I did think it was pretty easy by typical Microsoft standards. The hardest question that I can remember was:
- Something like, write a function to reverse a string using a char* but keep in mind that the string is a multi-byte character string. Dang, I wish I could remember the details of this one a little better, but the trick was that you simply couldn’t write a string reverse; you also had to take into account that some of the characters were more than one byte.
One thing to note about Microsoft interviews is that when you’re in front of that whiteboard trying to find a solution to a really hard program, you’re also expected to write very clean and efficient code. When I came on board the team and finally got my first look at some real Microsoft code, I was shocked. “Wait, this is Microsoft right? Who wrote this code!?” That story is for a different post.
A few years later, when I felt I needed another change but was still interested in programming, I went on my last round of interviews. I interviewed for the Office group, for Internet Explorer, and a couple of others that I don’t recall. Office and IE were the most memorable because they were the closest that I came to getting an offer, but I never did. In retrospect, this was a good thing, but I left again with a sour taste in my mouth about the whole interview process. The questions that I was asked this time were ridiculously hard. The ones I remember best, though still it’s fuzzy, were from the office group:
- A problem involving binary trees. I had prepared for binary trees, but this problem had a twist on it that made it really hard.
- A problem that I later discovered was taken out of the Programming Pearls book. In case you don’t know, this book has some super hard problems in here that some university classes take a couple of weeks to study. I was expected to solve it in one hour. I never did, but I was happy with how well I did.
- I went through a few more questions but I can’t recall the details. But, it suffices to say that they all dealt with either trees, hash functions, or lists. Each was really hard. I may have had less than a 50% success rate, but, again, I was personally happy with the progress I made on each. I assumed that this would be taken as positive.
After maybe four or five interviews, I was shown back to the hiring manager’s office. I’d had a great conversation with him the week before. He had waived the screening interview because he was impressed enough with our conversation. However, this time, he came in with a scowl and promptly announced, “Well, it seems it’s not going that well for you. I’m not going to bother with an ‘as-appropriate’ (MS terminology) interview with you.”
I gave him a shocked looked and retorted, “Oh, I was under the impression that I was doing pretty well.” This prompted mixed-up looks from both of us at each other. To make a long story short, our short conversation eventually turned to me giving him a stern but nice lecture about how his team interviewed me on one skill, algorithmic programming, which I had already professed was my weakest trait. If this was what they were looking for, then they likely made a good choice, however, if they were looking for a well-rounded developer which strength in distilling problems to their most simple components and a flair for creativity, then they failed. I honestly can’t remember that much, but I seem to recall that he was a little shocked that I talked back to him the way I did. I’m no super MS programmer by any stretch, but I had been at MS long enough to know that there are plenty of so-called geniuses that cause all sorts of problems with the code that they write and that hiring manager should look for balance on their teams.
After that, I made special strides to be a different sort of interviewer. I never asked the super hard programming problems. In fact, my problems were pretty easy. Of course, if you wanted a chance, you had to nail it, and if you did, you had to be able to intelligently take it to the next level, explain why, and show your own brand of excitement while you do it.
I was proud of my track record: People that I strongly endorsed when on to become great full-time hires. Some people that I “no-hired” (MS terminology) and who were hired anyway eventually ended up being fired. I can think of two right now! Not to mention the numerous interviews that I conducted in China, which was a completely different animal.
To close, I wish you would have asked me to help you prepare in advance, Igor. You gotta know the linked list backwards and forwards. I know you do, but at least now you’ve had your trial by fire and you’ll be ready next time. Those interviews can be unsettling. I’ve never experienced the phone “whiteboard” interview. I bet it’s even worse than the basic whiteboard interview. Give it some time and try again.
3 comments3 Responses to “Interviews at MS”
Leave a Reply
Theron, thanks for your reflections. In retrospect, I should have talked with you before the interview :).
I have never worked with anyone who was able get into my coding issues as quick as Igor. Igor’s solutions were always well written and easy to follow. Igor is brilliant and a natural teacher.
If Microsoft’s phone interview process filtered out Igor, then the process needs to be fixed. Igor would be valued addition to any organization building software solutions.
Couldn’t agree with you more, Dick! MS hires a lot of the same style developers. They need more people like Igor, in my opinion. It’s easy to test for the algorithmic style, very tough for the software engineering style.