Hello, Kim here again. We get many questions about what to expect when interviewing at Microsoft. I’m coming up on my two year anniversary at Microsoft and I thought I would share my experience in the hope that it might help you if you are interested in applying to Microsoft Support; if nothing else, there is some educational and entertainment value in reading about me being interviewed by Ned. 🙂
Everyone at Microsoft has a unique story to tell about how they were hired. On the support side of Microsoft, many of us were initially hired as contractors and later offered a full-time position. Others were college hires, starting our first real jobs here. It seems some have just been here forever. Then there are a few of us, myself included, that were industry hires. Over the years, I’ve submitted my résumé to Microsoft a number of times. I have always wanted to work for Microsoft, but never really expected to be contacted since there aren’t many Microsoft positions available in central Indiana (where I’m from). I had a good job and wasn’t particularly unhappy in it, but the opportunity to move up was limited in my current role. I casually looked for a new position for a couple of months and had been offered one job, but it just didn’t feel like the right fit. Around the same time, I submitted my résumé to Microsoft for a Support Engineer position on the Directory Services support team in Charlotte. Much to my surprise, I received an email that began a wild ride of excitement, anxiety, anticipation, and fear that ultimately resulted in my moving from the corn fields of the Midwest (there is actually more than corn in Indiana, btw) to the land of sweet tea.
I never expected that Microsoft would contact me due to the sheer volume of résumés they receive daily and the fact that the position was in Charlotte and I was not. About a week after I submitted my résumé, I received an email requesting a phone interview with the Directory Services team. I, of course, responded immediately and a phone interview was set up for three days from the current date. When I submitted my résumé, I didn’t think I’d be contacted and if I was, I definitely thought I’d have more than three days to prepare! The excitement lasted about 30 seconds before the reality of the situation set in . . . I was going to have an interview with Microsoft in three days! Just to add to the anxiety level, Ned Pyle (queue the Halloween theme) was going to do my phone screen!
Preparation – Phone Screen
I didn’t know where to start to prepare. As with any phone screen, you have no idea what types of questions you will be asked. Would it be a technical interview; would it just be a review of my résumé and my qualifications? I didn’t know what to expect. I assumed that since Ned was calling me that there would be some technical aspect to it, but I wasn’t sure. There’s no wiki article on how to interview at Microsoft. 🙂 On top of that, I’d heard rumors of questions about manhole covers and all kinds of other strange problem-solving questions. This was definitely going to be more difficult than any other interview I’d ever had.
Once I got over the initial panic, I decided I needed to start with the basics. This was a position for the Directory Services team, so I dug out all of the training books from the last eight years of working with Active Directory and put together a list of topics I knew I needed to review. I also did a Bing search on Active Directory Interview questions and I found a couple of lists of general AD questions. Finally, I went to the source, the AskDS blog, and searched for information on "hiring" and found a link to Post-Graduate AD Studies.
My resource list looked something like this:
1. Post-Graduate AD Studies (thanks, Ned)
2. O’Reilly Active Directory book (older version)
3. Training manual from Active Directory Troubleshooting course that was offered by MCS many years ago
4. Training manuals from a SANS SEC505 Securing Windows course
5. MS Press Active Directory Pocket Consultant
6. MS Press Windows Group Policy Guide
7. AD Interview Questions Bing search
I only had three days to study, so I decided to start with reviewing the areas that I was weakest in and most comfortable with. For me, these were:
1. PKI (ugh)
2. AD Replication (good)
3. Kerberos (ick)
4. Authentication (meh)
5. Group Policy (very good)
The SANS manuals had good slides and decent descriptions, so that is where I started. Everyone has different levels of experience and different study habits. What works for me is writing. If I write something down, it seems to solidify it in my mind. I reviewed each of the topics above and focused on writing down the parts either that were new to me or that I needed to focus on in more detail. This approach meant that I was reading both the topics I already understood (as a refresher) and writing down the topics I needed to work on. Next, I went through the various lists of AD interview questions I had found and made sure that I could at least answer all of the questions at a high level. This involved doing some research for some of the questions. The websites with the lists of questions were a good resource because they didn’t give me the answers. I didn’t just want to be able to recite some random acronyms. I wanted to understand, at least at a high level, what all of the basic concepts were and be able to relate them to one another. I knew that I was going to need to have broad knowledge of many topics and then deep knowledge in others.
The worst part of all of this studying was that I didn’t have enough lead-time to request time off from work to focus on it. So, while I was eating lunch, I was studying. While I was waiting on servers to build, I was studying. While I was waiting on VMs to clone, guess what? I was studying. 🙂 By the end of the three days of studying, I was pretty much a nervous wreck and ready for this phone screen to end.
The Phone Screen
This is where you’d like me to tell you what questions Ned asked me, but . . . that isn’t going to happen. Bwahahaha. 🙂
What I can tell you about the interview is that it wasn’t solely about rote knowledge, which is good since I had prepared for more than just how to spell AD & PKI. Knowing the high-level concepts was good; he asked a few random questions to see how far I could explain some of the technologies. It was more important to know what to do with this information and how to troubleshoot given what you know about a particular technology. If you can’t apply the concepts to a real world scenario then the knowledge is useless. Throughout the interview, there were times where I couldn’t come up with the right words or terms for something and I imagined Ned sitting there playing with his beard out of boredom.
In those situations, I found Ned was awake and tried to help me through them or skipped to something else that eventually got me back to the part I’d been struggling with but this time with better results. For that, I was grateful and it helped me keep my nerves in check as well. While trying to answer the flood of questions and keep my nerves in check, I tried to keep a list of the topics we were discussing just in case I got a follow-up interview. Although I’d like to say that I totally rocked out the phone interview and that I’m awesome (ok, I’m pretty cool), I actually thought I’d done alright, but not necessarily well enough to get a follow-up interview. Overall, I didn’t feel like I had been able to come up with responses quickly enough and Ned guided me around a couple of topics before I finally understood what he was getting at a few more times than I would have liked.
On-site interview scheduled – WOOT!
Much to my own disbelief, I did receive that follow-up email to schedule an in-person interview down in sunny Charlotte, NC. Fortunately, I had a little more time to prepare, mainly due to the nature of an on-site interview that is out of state. Logistics were in my favor this time! As I recall, I had about two weeks between when I received notification of the on-site interview and the actual scheduled interview date. This was definitely better than the three days I had to prepare for the phone screen.
With more time, I decided that I would take some days off work to focus on studying. Maybe this is extreme, but that is how important it was to me to get this job. I figured that this was my one shot to get this right and I was going to do everything I possibly could to ensure that I was as prepared as I could possibly be.
This time, I started studying with the list of questions from my phone interview with Ned. I wanted to make sure that if Ned was in my face-to-face interview that I would be able to answer those questions the second time. Then I reviewed all of the questions and notes that I had prepared for my phone interview. Finally, I really started digging in on the Post-Graduate AD Studies from the AskDS blog. I take full responsibility for the small forest of trees I killed in printing all of this material off. I read as much as I could of each of the Core Technology Reading and then I chose three or four areas from the Post Graduate Technology Reading to dig into deeper.
Obviously, I didn’t study all day for two weeks. I’d read and then go for a short walk. As the time passed, I began to realize how long two weeks is. Having two weeks to prepare is awesome, but the stress of waking up every day knowing what you need to do and then dealing with the anxiety of just wanting it to be over is harder than I thought it would be. I tried to review my notes at least once a day and then read more of the in-depth content with the goal of ensuring that I had some relatively deep knowledge in some areas, knew the troubleshooting tools and processes, and for the areas I couldn’t go so deep into that I at least knew the lingo and how the pieces fit together. I certainly didn’t want to get all the way to Charlotte and have some basic question come at me and just sit there staring at the conference room table blankly. :-/
By the time I was ready to leave for my interview, I knew that I’d done everything I could to prepare and I just had to hope that the hard work paid off and that my brain cells held out for another day.
The On-site interview
I arrived in Charlotte the evening before the interview. I studied on the flight and then a little the night before. Again, just reviewing my notes and the SANS guide on PKI and Kerberos. I tried not to overdo it. If I wasn’t ready at this point, I never would be.
I got to the site a little early that day, so I sat in the car and read more PKI and FRS notes. Then I took about 5 minutes and tried to relax and get my nerves under control (nice try).
The interview itself was intense. It was scheduled for an hour, but by the time I got out of the conference room I’d been in there two and a half hours. There were engineers and managers from both Texas (video conference) and Charlotte in the room. The questions pretty much started where we had left off from the phone interview in terms of complexity. I didn’t get a gimme on the starting point. I think we went for about an hour before they took pity on me and let me get more caffeine and started loading me up on chocolate. By the time I got to the management portion of the interview, I was shaking pretty intensely (probably from all that soda and chocolate that they kept giving me) and I was glad that I’d brought copies of my résumé so I could remember the last 10 years of my work history.
The thing that I appreciated most about the entire process was how understanding everyone was. They know how scary this can be and how nervous people are when they come in for an interview. Although I was incredibly nervous, everyone made me feel comfortable and I felt like they genuinely wanted me to succeed. The management portion of the interview was definitely easier, but they did ask some tough questions as well. I also made sure that I had come prepared with several questions of my own to ask them.
When I finally walked out of the conference room, I felt like a train had hit me. Emotionally I was shot, physically I was somewhere between wired and exhausted. It was definitely the most grueling interview I’d ever experienced, but I knew that I’d done everything I could to prepare. The coolest part happened as I was escorted to my car. As we were finishing our formalities, my host got a phone call on his cell phone and it was for me. This was probably the weirdest thing that had ever happened to me at an interview. I took his cell phone and it was one of the managers that had participated in my interview, she was calling to let me know that they were going to make me an offer and wanted to let me know before I left so I wouldn’t be worried about it all the way home on the plane. Getting that phone call before I left was an amazing feeling. I’d just been through a grueling interview that I’d spent weeks (really my entire career) preparing for and finding out my hard work had paid off was an unbelievable feeling. It didn’t become real until I got my blue badge a few days after my start date.
Hindsight is 20/20
Looking back at my career and my preparation for this role, is there anything that I would do differently to better prepare? Career-wise, I’d say that I did a good job of preparing for this role. I took increasingly more challenging roles from both a technical and a leadership perspective. I led projects that required me to be both the technical leader (designing, planning, testing, documenting a system) and a project leader (collaborating with other teams, managing schedules, reporting progress to management, dealing with road blocks and competing priorities). These experiences have given me insight and perspective on the environments and processes that my customers work with daily.
If I could do anything differently, I’d say that I would have dug in a little deeper on technologies that I didn’t deal with as part of my roles. For instance, learning more about SQL and IIS or even Exchange would have helped me better understand to what degree my technologies are critical to the functionality of others. Often our support cases center on the integration of multiple technologies, so having a better understanding of those technologies can be beneficial.
If you are newer to the industry, focusing on troubleshooting methodologies is a must. The job of support is to assist with troubleshooting in order to resolve technical issues. The entire interview process, from the phone-screen to the on-site interview, focused on my ability to be presented with a situation I am not familiar with and use my knowledge of technology and troubleshooting tools to isolate the problem. If you haven’t reviewed Mark Renoden’s post on Effective Troubleshooting, I highly recommend it. This is what being in support is all about.
Just don’t be these guys
So, what's it really like?
Working in support at Microsoft is by far the most technically demanding role I’ve had during the course of my career. Every day is a new challenge. Every day you work on a problem you’ve never seen before. It’s a lot like working in an Emergency room at times. Systems are down, businesses are losing money, the pressure is high and the expectations are even higher. Fortunately, not all cases are critsits (severity A) and the people I work with are amazing. My row is comprised of some of the most intelligent but “unique” people I’ve ever worked with. In ten minutes on the row, you can participate in a conversation about how the code in Group Policy chooses a Domain Controller for writes and which MIDI rendition of “Jump” is the best (for the record, they are all bad). While the cases are difficult and the pressure is intense, the work environment allows us to be ourselves and we are never short on laughs.
The last two years have been an incredible journey. I’ve learned more at Microsoft in two years than I did in five out in the industry. I get to work on some of the largest environments in the world and help people every day. While this isn't a prescription for how to prepare for an interview at Microsoft, it worked for me; and if you're crazy enough to want to work with Ned and the rest of us maybe it will work for you too. GOOD LUCK!
- Kim “Office 2013 has amazing beard search capabilities” Nichols