Thoughts from St. Louis: Interviewing and Campus Talk

I had a good trip to St. Louis this week. I did two days of interviews at WashU and gave a presentation to a group of about 30 students on campus.

The interviews went very well, I was impressed with the caliber of students that I interviewed, I have some hard decisions now on who we “fly-back” for another round of interviews.

WashU uses Java as its primary teaching language. The thing that surprised me was that none of the people I interviewed really liked Java. Their #1 complaint was that it is just too slow. Usually when I pushed on this I either got generalization (it has to be slow because it has a GC…) but some pointed out real issues such as startup time, small device or even throughput problems. One notable quote was: “I want to use C++ because Java is a toy language”. A lot of this push back struck me because *some* of the same criticism of Java can be applied to CLR based languages such as C# or VB.NET… I certainly hope an informed developer would not call C# or VB.NET “toy languages”…. Frankly I would not even call Java a toy language.

At any rate, as I did the interviews, I made a few notes of some things I found myself looking at in candidates. Hopefully these are some helpful tips.

Be concrete – I can best judge your potential and experiences if are explicit and use lots of examples. Didn’t just tell me you lead a group project; tell me exactly what you did to lead the project, what worked? What didn’t?. Don’t just tell me you like Napster, tell me what you like about it, and exactly what features you’d add.

Let your passion and excitement show – I want to hire people who will LOVE what they will do at Microsoft. Those people typically find a way to love what they are doing in school as well. If you have a project that you love doing, let that show through. If you don’t currently have one, get one! Even if it is outside of your direct school work. Don’t let classes get in the way of your education ;-).

Get curious – Many of my interview questions revolve around why things work the way they do. For example, it is not so much that you need to know how DNS servers work or how Java’s memory manager works to do well at Microsoft. But if you use the internet and write Java code every day and you are curious about the world you will likely spend cycles figuring how they work and why they work that way.

What you know maters, not your grade – Certainly, I look at the GPA, but I know it doesn’t tell the whole story. Don’t take the easy classes to pad your GPA, I have (in previous trips, no comments on this trip, sorry) passed on 4.0 masters students and hired 3.0 undergrads. Take the classes that will challenge you. Do some AI and/or compiler design classes… do some projects outside of class.

Love your mistakes – If you are not making noteworthy, meaningful, costly mistakes, you are not taking on challenging enough projects. Don’t be shy to talk about your mistakes; I’d be worried if you don’t have any! The most important thing to me is what you learned from your mistake. How did you get smarter as a result? What would you do differently if you had it to do over?

Come ready to code – Every CS major I interview gets to code. Obviously the problems are different for developer candidates than for PM candidates than for developers in test. By if you are in CS, you should be able to write some fairly simple code on a whiteboard. I like it because it is so concrete… It is very hard to BS your way through a coding question. That is not to say that everyone at Microsoft codes all day long (many do of course), but it is an easy way to demonstrated that you have learned. Syntax maters, but more importantly I care about the whys. Why did you use a recursive solution? Why do have to test for null there? Why do you have to iterate through the loop again?

Last night I did a talk to about 30 students (mostly CS undergrads). I did the standard intro to the CLR, plus I threw in a few bits about V2.0. This was a good talk for this audience as only a couple of folks had any .NET experience, but they had lots of Java experiences (Java is the teaching language at WashU). Microsoft kicked in giveaways (software, t-shirts, my poster etc) and pizza. What I think was most interesting to the students was the Q&A time where the discussion turned from deep technical facts about how the CLR works to life at Microsoft and generally the tech industry trends.

I had a chance to talk about my own interview process at Microsoft. (Which I talk about in my recent .NET Developer’s Journal interview)

I described what it is like to take “bugs” through the IE 4.0 war team. During then end game of a project we want to control the amount of changes that go into the code base. Because something like 1 out of every 3 bugs fixes causes some other bug, we want to be very careful about what we fix. So, at the end game, each bug fix has to be approved by the “War” team… a team of senior leaders with the experience to know which are the right bugs to fix. As a release PM I presented my team’s bugs one-by-one to the IE war team nearly every day. It was a grueling process that forced me to learn my product inside and out in order to stand up to questioning from the war team and I got a chance to hone my interpersonal skills as I learned how to communicate with the war team, devs and testers under very tight time schedule.

The students where very interested in the competitive landscape Microsoft finds itself in. We discussed Mono and in general what Novell is building and how it affects Microsoft. FireFox and IE were the source of some good discussion as well as the general position of “open source” world. One of the students asked me if I expected MS to follow IBM’s business model. IBM makes a huge amount of money on consulting services and MS makes a huge amount of money making software that is easy to use. I argued that these were diametrically opposed business models. I don’t see IBM doing what MS is doing, and I don’t see MS going after IBM’s model. We have different views of the world.

Lots of good comparison questions on Java vs. CLR. How generics in Java differ from generics in C#, performance difference in JIT’ed java code vs. NGen managed code. Etc.

I, of course, plugged by blog during the talk, so I may now have some readers that were at the presentation… if you were please add your comments here on the most interesting part of the talk for you. I’d be interested in hearing from you.

Overall a worthwhile couple of days…