As promised, I've decided to type up a short series on my interviewing process with Microsoft. I've talked before about it, however that was from a perspective of just screening and not actually landing the position. I am by no means an expert on interviews, or getting the dream job and as such this will just be my own experience with how it goes, and what ultimately worked to my advantage to help me succeed in the end. Most of this could probably be applied to interviewing with any company, but I'll put a Microsoft slant on it seeing as (maybe?) quite a few readers of this blog would jump at a chance to spend some time inside the walls of Microsoft. It's worth mentioning that I am *not* a traditional MS 'developer'...I will be working within Enterprise Support which is a completely different entity, and thus has different processes.

This post is part 1 of this series.

First and foremost, spend some time over on the MS careers site. On it you'll find a wealth of information about the different groups within Microsoft and what career tracks are offered in them. There is also a search page with a list of almost every job offered at Microsoft, so spend some time going through them and reading over the various requirements; you may find positions you didn't realize were even there. Of course Microsoft is first and foremost a software company, so the bulk of the jobs are related to the business of writing and selling commercial shrink-wrapped software (Windows, Office, server tools, etc). The vast majority of those traditional 'developer' jobs are located in Seattle, so you must be willing to relocate (though MS does have product groups scattered around the world, so do some research...there may be one closer than you realize).

Interestingly enough this was a track that wasn't of much interest to me...probably because I come from an IT (Information Technology) background, which anyone in the business will tell you is a completely different beast than that of the ISV (Independent Software Vendor) realm. There are other ways to be a developer for Microsoft, but not work within a product group: Microsoft's own internal IT/Tools department (Microsoft like any other business has an IT department), or Microsoft Consulting which as a general rule is not location specific other than "must live near a major airport" as these guys travel a lot (most of my friends who work for Microsoft are employed in this capacity, and love their jobs as they get to interface with customers on a very regular basis), or as an Application Developer Consultant which are similar to architects. I'm sure there are other code centric roles within Microsoft, but these are the ones I'm familiar with offhand. The point is not to limit yourself to being a developer on a specific product, though I'm sure that's a track that will interest many.

Once you've done your research, it's time to polish up your resume and start applying. Over the years I've kept a custom resume for each of the major groups I've applied to. Find out the technical specifics of the job and hone in on those areas in your resume. I cannot stress that enough. I can't even begin to imagine how many resumes MS Recruiting sees on a daily basis, so anything you can do to make yours stand out gives you that much of an edge over other candidates. The competition starts from the second you hit the submit button over on the MS Careers site. It's also worth mentioning that the flood approach (while easy to do) will not get you any further than hand picking a few choice positions and pursuing those more actively. I've made it a habit to check the Career page on at least a monthly basis...new jobs are popping up all the time. Perhaps most importantly: Read the requirements. If they say you need 10 years in the financial industry, that economics 101 class you took back in college won't suffice. In a nutshell, if the position seems like a longshot, it probably is.

So you've sent out 10 resumes, now what? It's been my experience that MS Recruiting is pretty quick to contact candidates that they are interested in. I can't give a hard number, but 2-3 weeks seems to be the average for me in the past 5 years. All in all I was contacted for about a dozen positions, with about half of those resulting in some actual face to face time with the group who was interested. The recruiter who contacts you can be located almost anywhere; Microsoft has relationships with many firms throughout the world when it comes to recruiting talent. The initial call will usually be normal HR stuff, so there is no need to put on your technical hat quite yet (that'll come later)...the usual "tell me about yourself, here's a description of the position, etc." By this point the group has shown interest so unless you royally mess up, you'll get some airtime with folks in the group. It's worth mentioning that from this point forward, every conversation, every email, every type of contact period is to be considered part of the interview process. Get rid of that email stationary, colorful fonts, etc. Treat all of them as if they were clients you are already billing work to, or trying to court as a potential client.

The recruiter will want to block off a couple of hours for you to speak with members of the team (about half will be technical, and the other managerial (or the so called "MS" part of the interview). They will usually let you pick a range of dates and times, so make sure you pick blocks where you'll be at your best. I'm not a morning person, so I always tried to do mine in mid-afternoon when I felt sharpest. I wouldn't push dates farther then 10 business days away, and heck, if you're feeling up to it then by all means schedule it the next day! I would recommend a week out, get all of the names of folks you will be screening with and write them down, and then it's time to hit the books.

In this day and age of blogs (and especially MS employees keeping blogs) I always search for the names of the people who will be screening me. A lot of times you'll get some hits, and they might even have their own website. You should of course read their entire site/blog to get insight into the group, plus you can mention that you read their site in preparation for the screen. If you know the specific group name, you can search for it to see what you come up with. Stuff you can find on the web is as close to actually sitting beside that person as you'll get before they extend an offer. In my case, I read about a dozen blogs start to end from folks who worked in either my group, or groups similar to mine. The information I gathered from those sites was by far the most useful as they outlined situations this group dealt with on a daily basis (as well as the resolutions for many of them).

Picking the actual books you'll need to study is a different beast altogether. This is not a steadfast rule, but it's been my experience that the majority of the stuff I think I need to read doesn't come up in the actual screen...the stuff I've found during my web researching has been more relevant. That being said, I pick 2 books (one of them from MS Press) and read them cover to cover. Treat them like college textbooks, and your final exam is the day of the screen. Use a highlighter, work through all of the exercises, etc. If you haven't finished them by the day of the screen don't worry, but do make sure to go back over whatever you felt was important the night before the screen. Don't kill yourself memorizing acronyms, layout of different configuration screens (in other words, the extreme details); concept are most important (for example, in my screens I missed the actual names of several tools, but I knew they existed and was able to describe how to use them which was good enough). Perhaps most important is to not overdo it. You aren't going to get any more out of an 8 hour cram session than a couple of 2 hour sessions spread over a couple of days. It may feel like you're cramming a bunch in, but that's just what it is: Cramming (not retaining). My rule was about 4 hours a day, and I made myself stick to it. I also spent another hour or so just working through real world examples either from my past work, or books, or contrived. Actually going through the paces is the best process in my honest opinion.

My final word of advice for preparation is not to do any last minute cramming the day of the screen. If you do, you'll end up focusing too much on the areas you're "brushing up" on when more than likely those areas aren't the answer to the questions at hand. If you're working at an office, I highly recommend trying to take the day off. If you can't get an entire day off, take at least half the day. If you can't do that, then schedule the screens for a day on which you can. Trust me, you're not going to want office hubbub on your mind if you want a decent shot at delivering "wow." If you've done your research on the group, applied to positions you're adequately qualified for, and gone through your reading material you should be more than prepared for the actual technical content of the interview. What you will not be prepared for is the process itself which I will go over in part 2 of this series, as well as going more in depth to my actual experience this go round.

Share this post: | | | | |