Interviewing at Microsoft

In a few weeks, we'll be moving to Redmond, where I'll be pursuing a career with Microsoft as a software engineer.

After a few months of deciding my future in Sandpoint, we (the family) decided we should at least keep our options open and keep my eye on the job market. This is probably sound advice all the time, but it's a mentally draining process.

I'm an avid reader of the Moon Gals' blog ( and back in early December, they posted about the need for software engineers ( Even though I hadn't really considered living in Washington, I figured I'd send my resume in. In truth, I had a profile on the Microsoft Career's website for quite some time, updating it weekly to keep it fresh, but never got any leads.

Zoe (one of the Moon Gals) had forwarded my resume onto a few recruiters. As it turns out, I was a good fit for a number of positions at Microsoft. On January 7th, 2005, I flew out to Redmond with the family for an in-person interview. Whew! What a process, and I thought others might like to hear about my experience since books have been written about interviewing at big companies like Microsoft, IBM, Google, etc.

A drive from Sandpoint, Idaho, is about 6 hours. The nearest airport is in Spokane, WA, about an hour and half, and on the exact same route we'd need to take to get to Seattle. We still opted to fly because of the weather -- driving through the mountains with our cars is a bit risky in the middle of winter, and I didn't want to risk blowing the interview.

The drive from the airport to the Residence Inn in Bellevue was straightforward; we flew in on a Thursday and my interview was the next morning. I spent some time driving around the campus, and made sure I knew where building 19 was, and did a drive test-run that night. The last thing I needed to worry about was how I was going to get there in the morning.

I'm a bit torn as I write this as to how much information to divulge about the brainteasers and coding questions I received. There's so many books and blogs on interviewing questions, I hope providing some of this information here is helpful and doesn't reveal any "secrets." Like preparing for the SATs by reading sample questions, I believe Microsoft constantly evolves the interview process enough that revealing some of my experiences will be constructive.

My interview started around 8:30am. In the lobby of building 19, I was amazed at how many other candidates were being interviewed -- of course they were all for different positions throughout the company, but I couldn't help but wonder if this kind of thing was typical on a daily basis. I was also amazed at the size of the campus -- see the map below.

I met with the recruiter for about half an hour before going off to the first interview on my itinerary. The itinerary had three people scheduled, taking me up to lunchtime. The first engineer I met was probably the most difficult from a technical perspective, though this could be because it was the first technical interview and I was nervous. I was given the following series of numbers:

1 1 2 3 5 __

I was asked what the next number was in the sequence. My brain was able to dig back and recall these were Fibonacci numbers, where the number (n) is the sum of the previous two numbers (so the next number is an 8). It was like divine intervention that I somehow remembered the name Fibonacci (though that came after a long think). I was then asked to write two functions in C# that return the Fibonacci number when given the index (for example, passing in 4 would yield 3 (as 3 is the 4th Fibonacci number), 5 would yield 5, etc. One was to use recursion, the other without.

What's interesting is that the recursive solution was very easy (I haven't actually tested this, this is just a pseudo-code thing):

public int GetFibonacci(int index) {

    if (index <= 0) return 0; // error if negative?
    if (index == 1) return index;

    return GetFibonacci(index-2) + GetFibonacci(index-1);


So recursively this was pretty easy, and I made an assumption that 1, the first Fibonacci number, was index 1 (not zero). I also left it open as to what a zero (or less than zero) value should return. Non recursively, however, I struggled with this (I think my nerves got the best of me):

public int GetFibonacci(int index) {

    int a = -1;
    int b = 1;
    int c = 1;

    for (int x=0; x<=index; x++)
        c = a + b;
        a = b;
        b = c;

    return c;


The rest of this interview focused mainly on a T-SQL discussion, focusing mainly on joins and syntax with some mock tables. Afterwards, I hopped in a shuttle and headed to another building, where I met a lead web engineer. In this case, I was given the hot seat; in front of me I faced Visual Studio in one monitor, and Query Analyzer on another. The task: build a simple webpage that populates some datagrids, and construct some stored procedures that pull the data as prescribed. The queries were pretty straightforward joins; I hadn't really used datagrids before but was familiar enough with ADO.NET and ASP.NET to get this done.

The next question was a bit tougher; I was to write a calendar control that displayed the current month (without, of course, using the built in calendar control). There's a lot of ways to do this, and it was clear to me the test was to see how efficient and what type of solution I could come up with.

To be honest, I kind of dropped the ball. I was hastily trying to decide on an algorithm because time was short (I had about 20 minutes to do this). I talked over the ideas with my interviewer, and began coding what I knew was not the best way but, realizing there are deadlines, I wanted to get something done. He stopped me, and pointed me in the right direction to solve the problem. There was a surprisingly easy solution to this (without using the built in calendar control, of course) that I hadn't thought of. Once we discussed it, I was able to complete the control.

My next interview primarily took place over lunch in one of the Microsoft Cafeterias. My interviewer was great, we had a nice chat and discussed corporate life at Microsoft quite a bit. Afterwards, I had about a half hour in his office where I was asked to write some moderately complex T-SQL queries using joins and aggregating data. The final question was a brain teaser:

You have 9 diamonds. 8 of them are of equal weight, 1 is a fake and weighs less than the others. Using two weighs on a balancing scale, how can you find which of the 9 is the fake?

Fortunately this one was fairly easy; I hadn't heard this one before but have read enough of the "weighing" brainteasers to figure it out: you divide the diamonds into groups of three. By balancing the first two, you can isolate which group of the three contains the fake diamond. On the second weigh, with one diamond on each side, you can determine which is lightest. If the scales balance, you know the fake is the one remaining diamond.

When the interview began drawing to a close, I knew this was the "as appropriate" part of the interview day. As I've read, if you're sent packing at this point, it's not good news. Fortunately, I was given another name and continued onward.

From here, the interviews were more of a management style with theory project handling as the focus. I was asked questions dealing with documentation, handling changing requirements, interfacing with business users, etc. One manager had asked me to write code to reverse a string, and then go through the ways it could break, and how I'd handle all the scenarios. We also discussed some of the projects I had worked on, challenges I had to overcome, and where I would like to see my career going.

After each interview, I was given another name -- sometimes in the same building, often jumping between buildings. The code writing I had to do early on was sometimes with pen and paper, sometimes directly on a computer, and of course, on the whiteboard.

One of my last interviews has given me a final brainteaser. He drew an image similar to the one below.

In this game, two people are wearing black hats and two people are wearing white hats. The direction of the hats shows which way each person is facing, and the player cannot turn around. The concrete wall is impenetrable. The first person to guess his/her color hat wins a big prize, but there's a penalty with losing so no one will guess unless sure they are sure of their color.

Who will win this game?

I had asked two clarifying questions. The first was pretty obvious, "The player on the left can see the two hats in front of him, but not his own, correct?" "Yes." I was just making sure I understood the rules. Finally, I asked, "Do all the players know there are 2 black and 2 white hats?" "Yes."

I absolutely love brainteasers like this; I vaguely remember a brainteaser given to me by one of my instructors about 15 years ago; I don't quite remember it, but recall something about three gnomes, two wearing red hats and one wearing a gold hat. It was similar in style to the one above -- and is often the case with brainteasers, it's not what you know, it's what you don't know that leads to the answer. In this case, the winner should often be the first guy on the left; assuming the hats are distributed randomly, 50% of the time he'll look out, and see two identically colored hats, and conclude his hat is the opposite color. That's not what happened in this instance; the guy on the left simply can't determine what color hat he has. But, the next guy over, knowing the first guy cannot determine his hat color, must know he has a hat of the opposite color of the person in front of him -- and hence he wins. After reading, "How would you move Mt. Fuji," I was glad I got some relatively easy brainteasers compared to the ones in the book.

All said, I believe I interviewed with nine people in total, ending just before 6pm. Was I tired? Actually, no, I was pumped. I really enjoyed the experience, and felt I had a great rapport with everyone. I had even joked with Jim, who gave the hat brainteaser, that the guy on the left may intentionally stay quiet -- even if he knew what color hat he had -- just to mess with the second person, causing him to guess wrong.

A few days later, I received an amazing opportunity: my choice of any of three jobs I was interviewing for. Wow! I spent the next few days talking it over with the managers, trying to figure out the best fit. To be honest, I was a bit uncomfortable reverse-interviewing everyone. It's tough to listen to why each team was my best choice, because they were all fantastic positions. In the end, I chose a position with the Windows Driver Central team. I think I'll be working in building 42, but I'm not quite sure yet! (Hey, 42!! It really is the answer to everything.)

The recruiters and managers were really great to work with. Moving, now that I have a family, is just not as simple as packing a car and driving. Some of the challenges include dealing with careers, family, friends, bills, bank accounts, loans, credit cards, retirement accounts -- I mean, the list seems endless.

I have to admit, it wasn't an easy decision to move to Redmond. The cost of living, the congestion -- none of that sounded appealing. I didn't want to leave some of the dearest friends I've ever made. But ultimately, I knew I had to do this.

So as the Dolphins said in the Hitchhiker's Guide to the Galaxy, "So Long and Thanks for all the Fish," Sandpoint, I'll miss you.
Comments are closed

My Apps

Dark Skies Astrophotography Journal Vol 1 Explore The Moon
Mars Explorer Moons of Jupiter Messier Object Explorer
Brew Finder Earthquake Explorer Venus Explorer  

My Worldmap

Month List