I got some questions on my last blog post, so I’ll do my best to answer them now:
Q. How hard is it to get a job at Microsoft?
Well, that’s a tough question to answer. There are hundreds of variables there. If you know someone and they submit your resume as a referral because they know your work, and you do legwork on open positions that you feel would be an excellent match (and you carefully chose which ones you are best suited for, because recruiters dislike nothing more than someone who applies for 27 different open positions just hoping to get any of them), then you’ve significantly improved your chances at getting at least a phone call from a recruiter.
It also depends on if you are in school still, or have been out of school for more than a year, because the recruiting process is handled differently for ‘industry’ candidates and ‘campus’ candidates.
No matter which bucket you fall into, you should read Gretchen and Zoe’s blog to understand all about how recruiting works.
Q. How does it work at Microsoft for a job change to occur (such as Test Engineer to Development Engineer)?
The short answer: you would interview for the job. The long answer: one of the great things about Microsoft is the ability to not only move between teams working on various technologies, but move between job functions as well. All the job openings that we have (did I mention that I have 3 openings on my team?) are posted both internally and externally. If you were to stay within a functional discipline, you would most likely go through what we call an ‘informational’ interview process to see if the job is a good fit, etc. If both the hiring manager and the person applying for the position wished to continue the interview process, then typically a formal interview loop with several people would be scheduled. Sometimes this is waived, but that is strongly discouraged. For functional changes, a formal interview is mandatory.
Q. Is there a central body that determines if someone can code well enough to take a development job, or is up to the individual managers for the different teams?
Coding, while a very valuable skill to have, is just one of many skills necessary to succeed in many jobs, but you really shouldn’t focus down strictly on coding, as you need to meet the bar across a broad skill set to succeed. There are people that can code, and have the interpersonal skills of a yak. But to get back to the question, there is no central body; the Hiring Manager for every job makes the final hire/no hire decision at the end of the interview.
Q. What does someone have to do to show he can code?
Again, that’s generally demonstrated during the interview process.
Most of these questions are focused primarily on a move from Test to Development. That can be a common path, but by no means is there any ‘norm’. I’ve seen dev to pm, pm to dev, test to pm, pm to test, dev to test, writers to qa, even moves into recruiting and marketing. Gretchen (and Zoe, who you should read if you are really interested in understanding recruiting and interviewing at Microsoft) made a post on how she loves what she is doing, and that she’s certain that there is another career here at Microsoft for her.
Of course my focus is QA, and as a company, we are working on retaining more senior developers in quality roles. In fact the Technical Lead in Test and the Test Architect positions within QA organizations are becoming more frequent as we build even more complex systems and the technical demands in QA grow proportionately with the complexity of the systems being tested. While the path into management is one road for growth in QA, (and I will readily admit that for some time it was the only path for growth) that is no longer the case.
I have a personal jihad of sorts about the type of people we need to hire into QA. I’ve spent my career at Microsoft in developer tools. In order to be an expert tester for a developer tool, you really have to be a developer. So we’ve always hired a lot of developers on the teams I’ve been on. On my current team, I hired all developers who can test (software design engineer in test, or SDET). Every single person on the team writes code; in fact, they write a lot of code. Sure, we write test plans to define what code we will write; we write design documents for our tools, and we do the occasional buddy test/manual test/bug bash thing. Mostly we focus on test automation for a variety of reasons. There’s lots of opinions on efficacy of automated vs manual testing, and I’ll leave that for a future post topic.