Interviewing at Microsoft: Part 5

The recruiting shuttle took me to my team’s building (they consider themselves lucky that pretty much the whole team is in a single building– hard for me to imagine working any other way!) As I walked in the building, I noticed it was obviously much newer than building 19 where I had met with my recruiter. I introduced myself to the receptionist, and told her I was here to meet with my first interviewer, whose name was Chad. I sat down in the waiting area, and read a massive analyst report about Microsoft’s previous quarter– perfect reading material. However, my wait was short– within a few minutes, Chad came down and introduced himself. We exchanged pleasantries while he escorted me to his office.

Second Interview: Chad
I had spoken to Chad previously during my phone screen, and he had been all business- you’ll recall from my description of that call that his questions were obviously pre-prepared, and he had spoken quickly, decisively, and almost in monotone. However, in person he was COMPLETELY different. First of all, he was very friendly– very much like most of my friends in terms of his demeanor. However, there was an almost palpable intensity behind his friendliness: this was obviously a guy who cares very deeply about his job and the technology his team is building. This was a guy with passion.

Chad’s questions focused primarily on the type of management specific to program managers: managing people, projects, and deliverables when you don’t have any direct authority. (I often describe a PM as someone with complete responsibility for a project’s success, but zero authority.) We talked a lot about handling conflicts and dependencies across group boundaries, which generally took the form of what I’ll call “scenario questions.” He’d present me with a very specific scenario– in fact, I think that they were real day-to-day issues that he was actually dealing with– and we’d talk through how I would handle them. I really liked this type of question because it tells a lot more about a person’s ability than any standard interview questions do… also, they are really fun to deal with because they’re so close to the real problem domain.

The detail of these scenario questions was actually very surprising to me: in the process of asking these questions, it was very common for him to reveal obviously internal information about upcoming features in the team’s products. This is why I say that I felt like they were real issues from his projects rather than made-up hypothetical situations. This level of trust really made me more comfortable, but it seems like a risky endeavor: you’re revealing confidential information to someone that, more often than not, is going to be mad at you for not hiring them! I wonder how often this causes problems for teams at MS. I assume they make a judgment call about how much they can reveal based on the level of experience of the candidate– experienced recruits are more likely to know where to draw the line.

Anyway, I feel like Chad and I really hit it off. I was very comfortable with him, which made it easy for me to perform well in the interview even though I hadn’t really gotten up to speed yet. Also, keep in mind that an interview loop should go both ways: you’re trying to sell the company on hiring you, but they company is also trying to peak your interest in working there. Chad was a great step in that direction: he’s exactly the kind of person I like to work with, and my interview with him revealed a lot to like about the team and the work they are doing.

There was one great moment where we were talking about handling differences of opinion. He described a situation that was very much on everyone’s mind on the team. (I’ll have to leave the details to your imagination and speak in generalities, though… but the scenario was VERY specific.)

“In this feature area, there are two very distinct schools of thought on how it should be implemented. On one side, there’s the people who want [Implementation A] but on the other hand, half the people on the team feel strongly that it should be done differently– they endorse [Implementation B].”

He went on to describe in detail the reasons people preferred each of the two implementations, and the pros and cons of each. He also confided that he was very firmly entrenched in the [Implemetation A] way of thinking. :)

“Tell me about how you would approach persuading another team member who was advocating the opposite implementation to the one you felt was the right thing to do.”

I began by discussing the various persuasive “tools” that are in one’s bag of tricks, and how I would apply each one, focusing on a Covey-esque “seek first to understand, then to be understood” logic. Once I felt I had adequately answered the question he had asked, I proceeded to answer the question he didn’t ask. I paused and said “let’s think outside the box for a second, though. Why not compromise and do something a little more like [Implementation C]?”

I then went on to describe a completely different implementation that I honestly think did a good job of blending the best features of implementations A and B. Chad looked stunned, and was really quiet for a second.

“I never looked at it that way. Wow.” He then turned around and scribbled down some notes. I honestly think that there’s a good chance that when the next version of the team’s product ships, you’ll see a little of [Implementation C]. :)

At this point, I really felt like I had Chad on my side. Not only were we getting along great, but I felt that I’d gone above and beyond just answering his questions, and had maybe even made a small contribution. I also felt like I had managed to convey how excited I was about the work his team was doing, which is key. (They are doing some really exciting stuff.)

The interview went for about an hour and a half, but it felt much quicker. The entire time felt a lot more like an informal chat about technology and management style than an actual interview. At the end, as Chad lead me back down to the building lobby to wait for my next interview, I was in the “well now this isn’t so bad!” mindset, but I was in for a surprise…

Interview 3: Steve
I waited for a few minutes in the lobby, and jotted down some precious notes that would allow me to blog about my last interview with a reasonable amount of detail. I finished up, and just as I was packing my Tablet PC back into my bag, Steve walked up and introduced himself. On the way to his office, he asked me how I thought my previous interview had gone. I explained that I felt really good about it, and that I had even managed to enjoy it. We also chatted a bit about the fact that it was on the strength of my phone screen with Steve (plus a recent campus tour) that had made me decide to put all other job-seeking opportunities on hold until I had an answer from Microsoft– I had pretty much decided that this was the job I wanted.

We settled down in Steve’s office, and he started out by apologizing for the fact that our interview would be cut a little short (an hour instead of one and a half hours) and that his busy schedule was the reason that I had a 30 minute break between interviews– they just couldn’t find a way to schedule them back to back. He then explained that we’d be task-switching a lot in our interview– that he wanted to ask a lot of very different questions, and that part of the drill was to see how I would handle switching rapidly between questions that required completely different ways of thinking.

First, he asked a technical question: “describe how audio and video gets converted into a signal, how that signal is brought into a computer and stored, and how that stored media is played on the computer’s screen or pictures.” However, there was a twist: “I’m nine years old.”

I started by describing how light was captured by a device inside a vide o camera using something called a “Charge Coupled Device” or CCD, and how it was separated into constituent primary colors (RGB) and started talking about how the audio waves were captured using either condenser or ribbon microphones. Of course, because I was talking to a nine year old, I had to go in excruciating detail, and break things down to their simplest components. At this point, he stopped me and told me to move onto how it is captured in the computer, but that now instead of talking to a nine year old, I was talking to an experienced programmer. Now I was talking in depth about how a device, either a breakout box or a card inside the computer would act as an analog to digital converter, and convert the audio and video into a file, which also required a discussion of video as a series of bitmaps, and concepts like framerates, timecode, how differential compression technologies worked, etc. Then it devolved into a block diagram of how a media player leverages the DirectShow APIs, how the DirectShow APIs interact with the NT kernal, and video/audio drivers, etc. All the while, Steve was asking probing questions, and digging and pushing. It was a real challenge, and I was kind of surprised at the amount of detail I was able to cram into a discussion that only lasted 10 or 15 minutes.

About 90% through that discussion, Steve made me completely change gears. I was presented with a scenario where I was presenting a feature to a VP in the company. I was to explain why the feature was important, how it worked, and convince him that it was the right direction. “What feature?” I asked.

“I don’t know… make something up,” Steve responded with a wry smile.

I proceeded to delve into why I thought a certain part of a specific Microsoft program was currently designed in a way that didn’t fit into the overall product’s theme and mission, and whiteboarded (whiteboard is a verb at Microsoft, trust me!) a solution to the problem. He asked probing questions, and responded to all of my responses with a nod and a thoughtful “hmmmmm.” It was kind of fun to watch him play he part of a VP– I got the sense he was unconsciously doing an impression of an actual person. At one point, I realized that some the UI I was creating was a totally horrible implementation. I stopped mid-sentence, and said “Wow… I’m creating some really bad UI here.” Steve chuckled a bit, and said “I promise that if/when you work here, by the time you’re presenting a feature to a VP you will have had more than 3 minutes to design it.” We both got a good laugh out of this… it’s a great illustration of what it’s like to do impromptu design on the spot with no time to think things through: you’re going to occasionally go off in a bad direction, but don’t be afraid to notice it and make a course correction– your interviewer will not only understand, but appreciate that you recognized the error of your ways.

We continued with a few more rapid-fire course corrections, and by the end of the hour I was feeling positively schitzophrenic. It was really fun to do a bunch of diverse whiteboard and verbal problems. I think Steve’s main goals were to find out if I could task-switch well (I think I passed this hurdle) and communicate using a whiteboard, which is a cultural imperative at Microsoft (I think I did OK on this front as well.) However, I think I did a less than stellar job of describing interactions between middleware, low-level APIs, and drivers. I focused so much on demonstrating my understanding of video and audio and compression, and had trouble switching to a more systemic overview of the computing concepts. (Note that I’m not saying that I understand this as well as I should, but rather that I did a poor job of demonstrating the parts that I do understand.)

Steve also threw in a few standard “tell me about some of you strength/weaknesses” type questions, but I think they were more to break up the white boarding sessions than anything. This was a rapid-fire interview, and he wanted every question to require a completely different way of thinking and communicating… so asking the occasional totally standard interview question sandwiched by in-depth design and whiteboarding questions fit the bill perfectly.

At this point, we were out of time, and Steve had to rush off to his next meeting. As an illustration (and, I think, just to see what my reaction was) he turned his laptop towards me and showed me his calendar. It was like a cruel joke: the entire week was not only booked, but over-booked. Steve would not only be in meetings every minute of every day that week, but most of the time there were 2 or even 3 meetings that overlapped. “The red ones are the super-high priority ones.” I noticed that several red meetings overlapped with one another. As we headed down stairs to the waiting area, we chatted a bit about the insane schedule, and how one handles a place where there’s always WAY more to do than you can possibly do. (Frankly, I wouldn’t have it any other way: I bore pretty easily if I’m not under enough pressure.)

All in all, I think that my interview with Steve went well, but I was concerned about having dropped the ball on block diagramming the interactions from DirectX–>Drivers–>hardware. I sat down in the lobby, this time having to wait a full 30 minutes before my next interview. However, I knew that upstairs, Steve was talking to my next interviewer… that’s what’s going on while you wait between interviews. I was running through my head what I thought Steve might be saying as I jotted down some quick notes from my interview. I also wharfed down a couple of power bars I’d brought with me, and used the little boy’s room. Before I even got a chance to start wondering where my next interviewer was, he walked in and introduced himself.

(To Be Continued…)