Matt asked about how to prepare for a technical position at Microsoft. Since there are two separate recruiting engines at Microsoft, I’m going to break my comments up into college candidates and industry candidates to match the paths that people typically enter the company.
College Campus Candidates
I interview a lot of people at college campuses as well as during full interview loops at Microsoft since I took my current position 2 years ago. I've visited 7 college campuses and two foreign countries (Bulgaria and Romania) and interviewed around 200 candidates during those trips, and I have had about 20 or so campus candidates interview for positions during that same period. Obviously, a BS or MS in CS at a school with a good CS program is probably the best way to prepare yourself technically for any technical position at Microsoft. It probably goes without saying, but I'l say it anyway: regardless of your degree or your GPA or your class rank, not just getting the grade, but developing a deep understanding of the curriculum is what will best serve you. That GPA on the resume that’s reviewed by a screener at a recruiting fair, or seen by the schools recruiter, may get you 30 minutes with me, but you'll never get back to Redmond for a full loop if I see that you came out of school with a degree in CS and have gaping holes in your fundamental knowledge.
So back to how to prepare yourself. Here’s some of the things I see in the best candidates:
What I look for when someone applies for STE
I mostly look for fundamentally smart people with a real passion for technology who can generate test cases and understand enough about how computers work to understand what code is doing. I also look for determination and inquisitiveness. Then I look at if this person can grow their coding skills. OK, they've never done any OOP, but can they code functionally? When I am making the decision for my team as the Hiring Manager, every STE I hire I believe that they have the coding skills to eventually move to SDET/SDE. Hey, I am in developer tools, I want every person I hire to be an expert on our product, and so I look for the potential to become an expert, which would mean being a developer. That is not the bar across the entire company, so when I am interviewing for Microsoft on campus, I look for the first part (fundamentally smart, real passion, understands computers at a moderate to high level), never gives up, and an inquisitive nature. I generally ask some testing questions, but because there are really few classes that teach how to test software, I am looking for aptitude, not ability. Red Flags: when I see someone come through with a degree in IS rather than CS, I drill very hard on their technical skills. Most seem to make that move because they aren't enjoying or just don't get the coding aspects. If this is the case, you will have a tougher time with me in making the STE bar. Not impossible, but it is more difficult.
What I look for when someone applies for PM
The best PM candidates have a MS/Phd in CS, excellent oral and written communication skills, understand the underlying technology, can build prototypes for proof of concept work, and are great negotiators. Pretty much, the best pm’s could be in Dev or QA if they wanted to be, but they have plus communication skills and a strong customer focus that they would rather focus on tying all the features together at a higher level rather than drilling into one area of technology. Warning signs: When I see someone with a BS in CS, then masters in business, and they want to be a PM. While I think that I understand the logic of this course, it rarely pans out well for candidates. They've lost any tech edge they may have had (they haven't taken a technical course in 2 years), and can’t talk about fundamental coding or design concepts any more. The other red flag: when people haven’t done the leg work to understand what the PM role is. You mean I can immediately manage people out of college? Wow, I want that job! PM's manage features and process, are not people managers (lead PM's would do both). Customer focus isn't enough in this role as well (I see many BS in IS trying for the PM role); you have to know your technical stuff too.
What I look for when someone applies for SDE/SDET
These people love to write code, live it, breath it, bring their laptop to the interview and are probably coding while their waiting for me to be done with the person in front of them in the interview queue. OK, that might be a slight exaggeration, but really, the best way to get technically proficient at a SDE/SDET core competency of writing code is to, well, write code. Lots of it. All the time. Candidates don't need to have perfect syntax, I'm not expecting that, but do they have a firm grasp on the concepts? Do their eyes light up as we talk about optimizations on a simple but elegant solution to a coding problem? Do I see that passion? For SDET, the bar goes up slightly in that I am looking for an additional skill. I look to see if they can test their own code. Sure, everyone tests their own code, right? It’s just part of the development process, right? Well, not exactly. Can they step back from the fact that they wrote the code, and look with a critical eye on their implementation? There are 4 types of developers from a QA perspective.
1. Can write code, can’t test other people’s code, can’t test his own code.
2. Can write code, can test other peoples code, can’t test his own code.
3. Can write code, can test other people code, can test his own code.
4. Can write code, can’t test other people’s code, can test his own code.
#1s don’t last too long at Microsoft. I characterize them in a very general way as either not enough experience or smarts to go beyond just writing code, or that they have such a huge ego that they believe that they never have bugs in their own code, and anything else being written doesn’t deserve their time. #2, they enjoy poking holes in other peoples designs, but have too big an ego to believe that there are holes in their own code. Ideally, we want to hire all #3 types for SDE or SDET, but we really need them in SDET roles. Why? Well, for test code, there is no additional organization that test’s the test code to ensure that it is working correctly, so these people are the last line of defense between the bugs in their code that cause test code to not uncover flaws in the shipping code. #4s are ok as SDE as well, they can test their own code, they just don’t help their peers that much via code reviews. Mostly, these people see one solution to a problem, and when people throw a different algorithm at them to solve a problem, they struggle grasping it, so reviewing someone else’s implementation is challenging for them.
I'll talk more about the industry recruiting route next time around.