Managed World

[Update: Adam Ulrich (the hiring manager I actually interviewed with) actually posted another good piece of advice. I have now included it below.]

During the process of looking for another job to further my career goals, I happened to interview for a position at Microsoft. I think perhaps now I can look back on the interview process a little more cleanly since I've been removed from it for almost a week.

The position I interviewed for was an SDE/T position on Michael Hunter's team (he works on the product code-named Sparkle (no, I don't know what it is (I do have some hunches from putting various factors together but I can't and shouldn't say *anything* since the product hasn't been announced (and besides, it has such a tight lid on it that I couldn't even be told what it really was during the interview process)))).

First of all, it was a great honor to interview for a position at Microsoft. I would like to think that eventually (after I mature some more as a developer and professional) I could get a job there and be a great contribute to Microsoft technologies. For the position I interviewed, though, not so much. One thing that became perfectly clear to me throughout the day was how much of a hole in my knowledge I have when it comes to testing software. By the end of the day, I knew that I wasn't a good match for the position I was interviewing for.

However, with that said, all the interviews were a blast and I like to think that I learned some good things about myself during the whole process. One thing that I would like to say to anyone thinking about applying to Microsoft: [Advice id=1] Just Do It [/Advice]!! Don't be afraid about the interview process. Don't let fear of the process get in your way. All the process really does is help both yourself (if you haven't already) and the interviews to get to know what your strengths and weaknesses.

One of the downsides for me happened to be how closed the end of the interview process. After going through the interview process, I would have loved to know certain *whys* of why I wasn't chosen for the position. If the feedback is there that can help you grow as a developer (and let's face it, the more good developers there are about there, the less potential crappy software is written on MS technologies, ultimately leading to a better public opinion of MS software and, consequently, putting MS in a better position). Now, I understand most of the reasons for not enclosing this information (especially considering all possible legal ramifications), but it's still a bummer nonetheless.

The day for me was rather short which made me have doubts about being considered seriously for the position. My whole day consisted of about 5 interviews, and went from 9am to 2pm. The first interview was with Michael Hunter which put me at ease a bit since I had already exchanged a couple of emails with him and had a phone interview with him also. In hindsight, I think I was too much at ease and perhaps didn't do as best as I could have done. [Advice id=2] Remember, no matter how much you might know your interviewer, it is important to not forget that it is still in interview [/Advice].

I thought that with Michael I did a decent job of talking through my thoughts. I knew that they want to know how you think, so help them in finding that out. As far as my coding question, my problem was that I got hung up on the details too much and didn't focus enough on the solution. While I mentally had the solution, it took too long for me to write it up on the white board and, hence, I didn't get to finish. That brings me to some advice: [Advice id=3] Pseudocode! Pseudocode! Pseudocode! [/Advice] Pseudocode will help you express your thoughts on the problem space and will help your interview gain a better insight into how you're thinking about the problem. That will ultimately lead to more discussion and will leave both parties in a better position. Even though I learned that piece of advice after the first interview (and I chatted about it a bit with Michael), I didn't do it as well in future interviews as I could have (although I did improve from the first interview I believe (in the logistics of coding on a white-board at least)).

So, then I was on to my second interview. My second interview was with another member of the team, John (sorry, I forgot your last name John). I knew I was in for a fun ride when I walked into John's office. Immediately, my eyes spot the “Graphics Gems“ series of books on his bookshelf. I also see some software patent cubes and numerous “Ship It!“ awards of his shelves. “This is going to be a blast,“ I told myself. And what a blast it was. We got to chat a bit about the Graphics Gems series and also about where I want to go as a developer. The white-boarding question was great! Basically, I was asked to devise a RLE (Run Length Encoding)compression/decompression scheme. Until that point, I actually didn't know any details about any compression methods, so I was pretty nervous. [Advice id=4] But, as long as you verbalize what you're thinking you should be in pretty good shape [/Advice].

Relatively quickly (although “relatively“ is not a good word since, for all I know, I came to the conclusion infinitely slower than any prior interviewees), I realized a pretty big flaw with the easy-choice compression method. That being, if you encoded everything the same way, and the file ultimately contained random data, then the file would end up twice as large as it began. Not exactly a good thing to happen for a compression scheme :). Anyways, by talking through it, I eventually came up with a scheme that used a single bit to determine whether the next value was a repeated value, or was a random value. I didn't quite take it as far as I should have but with a little push from John, I made that final step. The funny part to me was that, when all was said and done, he said that I used an encoding algorithm very similar to how Targa images are/were encoded. That made me smile since I had never even thought about compression before.

My next interview was with Adam Ulrich, the test manager. The meat of the potatoes of the interview was discussion about testing methods and spotting possible flaws in given solutions (which is an area that now I realize I need to work on). Toward the end of the interview, he had me code up a method called IsAnagram that determined whether two strings passed in where anagrams of each other. I thought I did decent at that example, but I was feeling pretty drained in hindsight. This happens to bring me to another piece of advice. [Advice id=5] Bring an energy bar or something to snack on between breaks in order to keep your energy level up [/Advice]. I knew this after seeing it on the Channel 9 video but happened to leave the energy bar out in the car. I will also give you another piece of personal advice: [Advice id=6] bring a bottle of water and keep it filled up [/Advice]. You can never drink enough water. It is important to stay hydrated. You will be talking a lot throughout the day (and if you happen to be a large man like me, you might be sweating a bit too), so you will need to remember to keep intaking water throughout the entire day. 

That brings me to my last interview. My last interview happened to be a lunch interview. [Advice id=7] A lunch interview is still an interview! [/Advice] Once again, I had gotten some advice about this so I thought I approached it pretty well. One problem that came up from having a low energy level though was I noticed that I tended to be a little distracted throughout the lunch interview. This last interview was with Greg Penoyer. After lunch, we went back to the office, and did a little more interviewing.

He had me code up an IsValidMove function for Othello. Unfortunately, by this time, I completely forgot about the advice I had given myself earlier in the morning and I didn't focus on the solution and the expression of that solution. Once the code was finished, we discussed different ways to test. Part of that discussion was talking about the most important test cases, and some of the “interesting“, outlying test cases. If I hadn't already noticed before, this *really* drove home the point of how little real world experience I had with testing software.

Ultimately, this brings me to yet another piece of advice I have for other prospective MS interviewees: [Advice id=8] Know the position you're interviewing for [/Advice]. I know, this one sounds obvious. But I mean it. If I had to say that there was one thing that set me up for failure most, it was this. I knew I was very interested in the position, but I made the mistake of not actually viewing the job description and, hence, not knowing exactly what the team was looking for. Yeah, I know, that sounds pretty silly and it is pretty common sense. But I think it's important, especially with the growing influence of blogs and how many jobs might be talked about any given MS employee's blog. I felt that perhaps I wasted my interviewers time, and that is never a good feeling to have. If I had researched the position some more, I would have known that my skill set was not a good match for the position. Perhaps then, I could have looked for other positions that would have suited me more. Remember, it's important to be totally honest with your interviewers and your recruiter. You don't want to set yourself up to fail. Especially with how draining the interview process is, you don't want to think that you have wasted your time doing it. I'm not saying I felt that way, but I want to make sure that you (any potential MS interviewee out there) doesn't feel that way. 

I have one last piece of advice in closing. [Advice id=9]Your interview day is not only your opportunity to be interviewed, but also your opportunity to interview the team/company [/Advice]. Take advantage of that. I know I had many interesting conversations throughout the day that excited me about the possible to work on the team. Unfortunately, as I realized, my skill set didn't match the requirements of the team. Well, at least that is what I believe and what I was told. Due to not knowing any of the feedback, for all I know, my interviewers felt I'm not Microsoft material and that I'm now listed as a “non-hire” or something like that. I hope that's not it, but there is no way for me to know at this point.

Regardless of the outcome, I'm ecstatic about how it all worked out. Of course, I had the luxury that I already had an offer for a job in Portland. It was going to be a hard call if I was offered the job. I mean, on one hand, being offered a job from Microsoft could potentially be a once-in-a-lifetime opportunity. On the other hand, there would be a lot I would leave behind here, and I wasn't sure if it was the best choice for me on my 5-10 year career plans. I just hate burning bridges though, so it will always bother me not knowing if one was burned with Microsoft or not.  

Overall, I thought the interview process was a great learning experience. I learned a lot about where I need to grow as a developer, and I learned a lot more about the inner workings of Microsoft. Like I stated before, I just wish I could know where my interviewers thought I could improve. But, that doesn't stop me from knowing the places I know I need to improve. Just keep an open mind and have fun. That's the important part!

[Update: This advice came from Adam Ulrich that I forgot to point out. [Advice id=“10“] Read the blog posts on recruiting from the team you're interviewing with [/Advice] (Adam includes some examples below in his comment).]

So, to recap some advice that I have for fellow developers wanting to interview at Microsoft:

1. Just Do It! Don't let fear get in the way of interviewing for a position with MS.
2. An Interview Is Still An Interview! (no matter how much you might know the interviewer)
3. Pseudocode! Pseudocode! Pseudocode!
4. Always verbalize what you are thinking about during white-boarding.
5. Have a snack ready (like an energy bar) in order to keep up your energy level.
6. Stay hydrated!
7. A lunch interview is still an interview.
8. Know the position you're interviewing for.
9. Your interview day is also for you to interview the team/company, not just for you to be interviewed.
10. Read the blog posts on recruiting from the team you're interviewing with.