Jøhnny Fävòrítê (johnnyfavorite) wrote,
Jøhnny Fävòrítê

microsoft II: the brainoring

So I did the Microsoft phone interview yesterday. Four and a half hours or so. They told me nothing ahead of time, so I didn’t know it was going to be four interviewers, one hour each. Actually it was closer to four and a half hours, because a couple of the interviewers enjoyed torturing me so much that they went over a bit. The internet connection I have where I’m staying barely works, so I went to Portland Brew in East Nashville. A perfect spot for this. They have a big well-lighted upstairs room that’s far away from the front door, not many customers, and strong wifi.

The interviewers wanted me to install Microsoft Windows Live Meeting, but fortunately for me there is a java applet that runs in Safari you can use instead. I was afraid that the java version might have some limitations compared to the native client, but if it does, I didn’t notice them. In fact, there was a guy who works at the recruiting firm who sat in on the interview who did install the native version, and his experience was horrific. He said it took him over five hours to get it to work and he couldn’t see most of the diagrams the Microsoft interviewers were drawing. All I had to do was point Safari at a particular URL and it worked fine.

My worst fear was that they’d haul out the famous Microsoft brain-teasers. The most notorious of the lot is “Why are manhole covers round?” I’m sure they’ve had to retire that one, everybody knows it. Here’s another one I just googled up: “How many cars are there in the U.S.A.?” Fortunately for me, there was none of that nonsense.

But programming problems! Oh yes, lots and lots of programming problems. The night before, I gave myself a little pep talk. Part of the reason I do badly at this type of interview is that I am a classic introvert. I don’t like having my guts dragged out for other people to gawk at. So I had to remind myself that it’s okay to look stupid. The whole point of this type of interview is to give you questions that you can’t solve or haven’t seen before, and see how you attack the problem. I’m less of an introvert than I was five years ago, so this is less of a problem for me now.

I did pretty badly with the first interviewer. The first exercise was okay. He drew a theoretical program window on the Live Meeting chalkboard, and asked me to write a class to operate it. I did okay on that one, but I used old-fashioned “raw” Objective-C to do so. Then he wanted to know if I could do the same thing with bindings. I had to admit that, no, I have no experience with bindings. They don’t work on the iPhone and that’s where I’ve been doing my Cocoa programming lately. Then he started in on his second problem. You’ve got a 24-bit image file, and you want to dither it down to a 256-color palette. Here’s a sample list of palette entries and a sample RGB pixel from the image. How do you match that pixel to the closest palette entry? I came up with a matching algorithm that wasn’t completely embarrassing, but it wouldn’t work. There were other permutations, like how can you sort the palette entries for fastest access when doing the color lookups. I did really badly at all of that.

First hour over. The interviewer says “I see that our time is up” and exits the live meeting thing. I figured that my supposed four-hour interview had gone so badly that they’d terminated it after only an hour. I started packing up my Macbook. The guy from the recruiter calls me and says: Hey, misunderstanding, you’ve still got three more interviewers.

I did better with the second guy. He spent a fair amount of time grilling me about my Mac programming experience. I have a lot, but B-level cube farms are not willing to consider most of it valid, because the large majority was things I did on my own time, rather than for an employer. Incredibly, they seem to think that if a big corporation didn’t pay you for it, it doesn’t count. That attitude is so wrong I don’t even know where to start. Good companies realize that stuff you do on your own time is a far more valuable indication of initiative. It says you care so much about a particular subject that you’re willing to devote your own time to doing it. To Microsoft’s credit, they were perfectly willing to accept my homebrew projects as valid.

Then the programming exercise. Input an integer, convert it to a Pascal string. I breathed a sigh of relief. It sounds pretty straightforward, I can do this. I start by typing this into the live meeting thing:

  typedef char PascalString[255];

  void IntegerToString(PascalString* string, int integer)
      char* text = string[1];
      text = itoa(integer);

and the interviewer says “Oh, and you can’t use itoa().” Sigh. This is why programming interviews are so tedious. They don’t want you to write actual code that might be useful today. They want you to write code similar to stuff we were doing back in the eighties, before most languages had good libraries. Now that I think about it, that applies to the RGB palette question as well. Who would write something like that today?

I wrote a loop that could pick off the individual digits of the integer, no problem, and stuff them into the Pascal string. The interviewer challenges me to notice what’s wrong with my solution. It dawns on me: the usual way of picking off individual digits from an integer results in getting the low-order digits first, which means that they are backwards in the string. Now the problem has devolved into the age-old “write a method to reverse a string in place” exercise. My second-worst nightmare. I struggled mightily, glancing longingly at the clock in the Mac’s menu bar, praying for the hour to be up. I got it mostly-working by the end.

The third guy was my most sympathetic. He remembered that he had been in on my first phone screen about a week ago, but I didn’t really remember him. Phone interviews force you into an unnatural state; for me that means my mind isn’t working as well as usual. He was more laid back than the rest of them, and a little world-weary. I liked him. His first two programming problems involved bit-twiddling and recursion. I’ve done plenty enough of those things to come up with serviceable answers.

His third programming problem was my only stroke of luck all day: “Write a method to detect a loop in a linked list.” I got this exact same problem in my interview with OpenWave, eight years ago. Also, I did a tiny amount of googling for programming-related interview questions last night, and this was the one and only question that had a simple enough answer I could remember. So I had the perfect algorithm already in mind, it was just a matter of futzing over the details. (Here’s the answer, in case you’re interested. Write a loop with two pointers that traverse the list. In every iteration, make one pointer move forward by one link, while the second one moves forward by two. If the two pointers ever become equivalent, then the linked list contains a loop.)

Then he posed some language-lawyer-type scenarios involving C++. Things where the answers involve knowing what is-a and has-a relationships are, what private inheritance is good for, stuff like that. C++ is vast. I'm familiar with maybe 20 percent of it. Fortunately for me, all his questions were within that 20 percent.

His final question was a scenario that involves connecting circuits to each other to sort a list of numbers. I guess this was technically a brain-teaser, but enough like programming that I didn't feel cheated. And finally, this guy was finished with me. He went over by about 15 minutes.

The last guy of the day asked me about my programming experience again. He allowed me to go on at length about how I implemented my card game, which I enjoyed. His sole programming question was, I think, the most relevant of them all. Here it is: reimplement the NSObject method valueForKey: from scratch. Here is the relevant documentation on Apple’s site. If you’re following along at home (hi Alex!), the description I had to work with starts with “Default Search Pattern for valueForKey:” and contains five very detailed and exhaustive rules. I struggled mightily with this, moreso than the other programming problems, because this one seemed pretty close to something I might actually have to do in real life, in this decade. I spent close to an hour on it and got maybe 15 percent of the problem solved. So this interviewer ended up going over the allotted hour as well.

Whew, what an experience. I had been pretty focused the whole time, so I didn’t notice until it was over that my back hurt. I think I had been holding myself in a tense posture for the entire time.

I tried to get out of this, but now I’m glad I didn’t. I certainly did better this time than on any other programming-related interview I’ve ever done, which I attribute to finally being willing to get dragged into the thick of it. I’m still ambivalent about Microsoft, and I have no idea if I’ve made it to the next level, or if I even want to. But it was a positive experience. I’ll be recounting this story for years.

update: feedback from Microsoft via the recruiter is that I “had some trouble with the problems.” I would have felt obligated to take this if they’d offered it, so I’m a bit relieved.
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded