On early October of this year I submitted my resume to the Microsoft University Careers website. After a few weeks I received an e-mail from a Microsoft representative to schedule a phone interview. The phone interview was quite brief (a little more than half an hour). The person on the phone seemed very nice and asked me a series of questions that sounded a little absurd, but I guess they are useful to them to figure out how you think. Something on the line of “you are in such and such situation, how would you do this?”. This took almost 2/3 of the interview time. At the end he asked me two technical questions about data structures and coding, which I thought were fairly easy to answer.
After a few weeks, a recruiter contacted me to gather further legal information about me. When I finally put all my documents together I got a reply saying that I was invited to another round of interviews at their campus in Fargo, North Dakota. A series of e-mails followed to make sure that all my travel accommodations were taken care of and that I understood the itinerary. I requested to travel by airplane and they bought me tickets ($680 value). Sweet!
In the meanwhile they told me that I was going to be interviewed for a position as an SDET (Software Design Engineer in Test). I honestly have no idea of how I got assigned to this position with just one short phone interview instead of being considered for a SDE (Software Design Engineer) or PM (Program Manager), but this is what they told me in the e-mail. I hadn’t done much software testing in my career before besides some simple unit testing, so I went online and purchased a few books.
- How we test at Microsoft by Alan Page, Ken Johnston, Bj Rollison
Besides the first part of the book that bragged about the awesomeness of Microsoft, the book contained a quick introduction to software testing methodologies, like equivalence class partitioning, boundary value analysis and an overview of tools that help with the generation of test cases and help detect risk areas. It also explained how the career path of an engineer at Microsoft looks like. I would recommended reading this book if you’re applying to Microsoft, but skip the first part.
- The Art of Software Testing, Second Edition by Glenford J. Myers
The first edition of this book was written back in the 70s, yet I was surprised how of well Myers was able to abstract the principles enough so that the reading still flows today. The book is very pleasant to read and covers further many aspects of software testing. You should read this book if you are serious about software development, regardless of whether you want to nail a job at Microsoft.
- Programming Interviews Exposed: Secrets to Landing Your Next Job, 2nd Edition by John Mongan, Noah Suojanen, Eric Giguère
This book wasn’t about testing in particular, but I thought it contained some pretty useful insights about technical interviews. It contains a review of data structures, algorithms, Big-O notation and other common topics that arise often during interviews. But the most interesting part about the book is when the authors explain the thought process that you are expected to show during an interview. Things like speaking out loud, using the whiteboard, triple checking your code for common errors before you finalize your answer, explaining the limitations of your solution, etc. I’d recommend this book if you are interviewing with any big tech company.
I also took some time to review my C# skills and tried to solve a few problems that I found on this page from Wikipedia. Finally, I looked over my resume a few times just to remember what stuff I put in it.
The whole interview trip lasted three days. One day to arrive in Fargo, settle in and have a reception dinner, one day for the actual interview and the third day to fly back home. The first day at the reception dinner I met a lot of talented and technology passionate people. Some of them were employees at Microsoft, others were candidates like me, applying for a job at Microsoft. The atmosphere was very friendly, full open bar and very good food.
I left the reception dinner early around 9pm because I had to wake up early the next morning for my interview. On the interview day at 7am I took a shuttle that brought me from the Radisson hotel to the Microsoft’s campus. There one of the directors greeted us and gave us a tour of the place, emphasizing the awesomeness of working at Microsoft. Game room with XBoxes, free soda machines, subsidized cafeteria, fireplace, etc. Of course along with the delicious foods and drinks of the night before that was pure marketing to get me and the other candidates to accept an offer as quickly as possible if we did get one. During the tour I tried to pay attention to the things that were not put under the spotlight, like the incredible small cubicles where first hired developer work and the small offices with no natural lights for senior developers. The building itself was entirely made of glass which brought in a lot of sunlight, so I was disappointed and surprised to see that the actual offices didn’t get much natural light at all.
We all took a seat in a meeting room where we got served a delicious warm breakfast. After breakfast, one by one each candidate got called by a Microsoft employee and brought into an office for a 45 minutes interview. At the end of the interview I had a 10 minutes break and the process was reiterated three other times, for a total of 4 interviews of 45 minutes each. The questions were split half and half between technical and personal questions. The technical ones were aimed at establishing my overall ability to solve problems, the personal ones to assess how well I would fit for the job. One thing I noticed talking to the other candidates was that those who did not solve one or more of the technical problems were the ones who got “eliminated” first. So if you want to nail a job at Microsoft you really have to be able to solve these technical problems. I didn’t think the problems were really hard and I could choose any language of my choice to solve them. I was asked to first describe the solution, then attempt a solution by writing the code, then discuss how well it performed and what were the limitations of it. I was able to find a decent linear time solution for all the problems and the interviewers seemed quite satisfied from my answers.
As for the personal questions, they asked me the usual stuff you would expect from a non-technical interview: something about my past projects, a time where I was stuck on a problem and how I went about solving it, etc. They also tried to assess what my favorite area of development was, whether it’s in UI development, test, back-end, etc. Although I knew I was applying for a position in test, I didn’t feel like lying and I honestly told them the truth, that I prefer to work on things that are directly visible to end users, like UI, mobile and application development. I however emphasized several times that I would be excited to work in a testing position as well.
At the end of the 4th round of interviews, the recruiters gathered everyone in the meeting room and we got served some lunch, while they decided who was going to get an offer and who wouldn’t. There were 17 candidates and only 6-7 positions available. While chatting with one of the recruiters I couldn’t but notice how they were trying to probe us on whether we were going to accept an offer right away. In the middle of the conversation they would simply ask you “so, are you going to accept the offer right away?”. I told them “maybe”, but of course I was going to accept. I just wanted to make sure that they didn’t think that I was desperate for a job. After an hour of wait, the recruiters announced that they had decided and that they were going to call in “random order” one by one and tell everyone the results in private. I became very suspicious that that was not the case when they also said to “grab our stuff because we are not coming back in the room”. Cut short, if you were called you did not get an offer. I think 8 people got called before I did (which were also the ones I knew struggled with the technical parts of the interviews). When my name got called I followed the recruiter in a small office and she politely told me that I did not get the offer and escorted me rapidly to the shuttle that brought me back to the Radisson. In a way I felt like I was almost getting kicked out. Of course on my request to know what I could have done to improve in case I decided to apply in the future was denied with a “sorry, we cannot disclose that”. I was a little puzzled at first because I felt like I nailed the technical part. But I guess they don’t look just into how well you deal with problems but also how well you would fit in the position.
The Fargo campus is mainly dominated by the Microsoft Dynamics team (in fact the whole campus was built around the company that previously owned the product that is now called Dynamics). At the time of writing they also had a small Windows Phone team and also a very small Visual Studio team. To be honest, although I would have liked the opportunity to work for this company, Dynamics is definitely a product that does not interest me, at all. Most people don’t even know what Dynamics is. I would have hoped to work on some “cooler” products such as Windows, Windows Phone, Office, XBox, Surface, not Dynamics! So I would say good job to the recruiters that identified my passion for some other areas. I spent the rest of my evening in Fargo at a very good italian restaurant, then the next morning I flew back home. All expenses were reimbursed as long as we kept the receipts.
Overall it’s been a great experience, I feel like I got to know a lot of talented people and I have a better feeling for what to look for in the future. The only thing I really disliked were the lies I had to listen from the recruiters. “Everybody is going to get an offer”, “We are going to call you in random order”, blah blah. I know it’s their job to tell you what you want to hear, but nonetheless I still highly dislike it.
So, what are my suggestions to do well during an interview with Microsoft?
- Ask questions! DO NOT make assumptions about the nature of the problem. If they start a question with something very generic and vague, ask them to be more specific. They will do that, on purpose.
- Never, ever, ever give up. If your first solution doesn’t work, start over. They are more interested in seeing your thought process rather than the final solution.
- Triple check your code for divide by zero, boundary values and dynamic allocation exceptions.
- Make sure you know what position you are applying for and make sure that you really would like to work for that position.
- Explain your solutions clearly and use the whiteboard.
Curious fact: I was told that I was being considered for a SDET position, but they didn’t ask me to write a single test case. A fellow applicant that was being considered for a SDE position got asked to write tons of test cases. I don’t know if this is just coincidence, but be prepared.0