You’ve got Questions, I’ve got answers.

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.



Comments (13)
  1. Matt says:

    In response to your answer to "How does it work at Microsoft for a job change to occur..", my question is: since a functional change from ste to sde requires a formal interview, does already working for MS as a ste give you any advantage over someone from outside the company?

    I heard that when someone tries to switch from ste to sde they are assigned a mentor to help with the process, is this true?

  2. adamu says:

    I’d like to say, no, it gives you no advantage, that every internal and external candidate are given the same opportunity for each job opening. That said, being able to see reviews for an internal candidate (with their permission), speaking to their manager (with permission) and knowing that they have already demonstrated what Microsoft calls core competencies and company values(no matter what discipline you are there are a core set of things that everyone needs to succeed at: communication, integrity/honesty, conviction/courage, etc,) should eliminate the need to drill into those areas, and allow the hiring manager to focus primarily on the technical skills for the position. With someone external to the company applying for a job, you’d have to spend time drilling into those areas and a candidate may have strong technical skills but not get hired because of those core competencies or company value concerns.

  3. Matt says:

    Thanks Adam.

    How do you recommend someone gain the technical experience neccessary that is required by MSFT for:

    1. Being an STE?

    2. Being an SDE?

    Is a computer science background + MCAD certification enough for SDE?

    What type of background is adequate/recommended for STE?

    Thank you for taking the time to answer these questions.

  4. adamu says:

    Hi Matt,

    Thanks for the follow up questions. I’ll speak to the path of both campus candidates and industry candidates in my next post, and hopefully answer your questions about technical experience in a more general fashion.

  5. People always seem interested in the move from Test to Dev. I understand this idea, in most of the industry test isn’t respected as a career path and a solid technical contributor to the process.

    I’d like to go on record and say that it’s a much better world at Microsoft. Testing has always been the most interesting part of the software lifecycle for me, and I interviewed with a lot of companies when I graduated from school. Most of them were shocked that someone with my qualifications wanted to work in test. Only at Microsoft did I get the sense that they really take testing seriously as a technical discipline.

    I know there were companies I missed, so I don’t need to get in a conversation about who has what kinds of testing. But I do want to once again reiterate that testers here aren’t the second class citizens they are in most development orgs.


  6. Dave says:

    Chris & Adamu:

    Have any of you read ‘Proudly Serving My Corporate Masters: What I learned in 10 years as a Microsoft programmer’ By Adam Barr? (ISBN: 0595161286)

    Adam describes testers to be "on average, less qualified" (pg. 67) and "for a variety of reasons they are viewed as lower on the pecking order than program managers and developers" (pg. 50)

    He further rants negatively about testers especially in chapter 4.

    Considering Adam worked at MSFT for 10 years, its disconcerting how he describes testers. It would be great if Chris or Adamu could comment on this book.

    Thank you.

  7. adamu says:

    I haven’t read it. I commented in a previous post that many developers are pretty arrogant about being developers and mentioned this post as a typical example.

    A lot has changed since 2000, and it continues to evolve. The move away from large quantities of contract testing is one positive step.

    Since Adam Barr was as MS from 1990 to 2000, I would say yes, during most of that period, MS didn’t understand the true value of a technically excellent testing organization. I would say that 30% of the people on campus were contractors when I started in 1996. 50% of the first test organization I was in was contract testers. That is no longer the case. I’ve had exactly 2 contract testers in the last 4 years on the projects I’ve worked on, and those were for brief periods.

    Last week I went to the 2nd Engineering Excellence day at Microsoft, and all the content, just like last year, is about ‘pushing quality upstream’. How do we get QA more involved earlier in the process?

    Quality matters, and getting technically strong people in QA roles is important, and we as a company are finally getting it right.

    My take on pecking orders? They are too group and personality dependent to make any generalizations. I’ve seen groups dominated by QA, by PM, and by Dev in my 8 years.

    Any functional discipline at Microsoft in any organization, if it doesn’t hire carefully, can fill itself with mediocre talent, and the results can be long reaching.

  8. Adam Barr says:

    I’m the author of "Proudly Serving My Corporate Masters", and I happened to find this post when I was trolling around looking for references to the book (which is what authors do when they are bored).

    Anyway, the point of what I wrote about testers was to try to COUNTERACT the prevailing feeling that testers are second-class citizens. It’s would take a while to summarize my argument here, but basically what I am trying to debunk around p. 67 is this myth that testers are people who are fully qualified as developers but just have a different bent, they like to break things, etc. This has always been presented by management as the reason why testers should be respected — "because they are just as qualified to be developers as the actual developers". What I am saying on p. 67 (to complete the quote) is that this is false, that testers are less qualified AS PROGRAMMERS. This is not meant as a knock on testers, it’s just that if you try to base your "testers are important" argument on this fallacy, it destroys the whole notion that testers are important.

    (I don’t want to get into a big argument about whether testers are less qualified as programmers or not. I think the basic fact is that if someone is qualified to be a developer, they will be hired as a developer. The move from test to dev is viewed as a promotion; the move from dev to test is a demotion. It’s true that many SDETs are extremely good programmers who could be working as "full" programmers at other companies, but at Microsoft they are not).

    So what I am trying to argue in the book is that testers are just as important as developers, in fact they may be more important, but it’s not because they are as good developers as the developers, it’s because they are good testers! That should be reason enough to respect them. In fact I make the claim that Microsoft started out in the "era of the developer", moved to the "era of the program manager" around 1990 when Windows 3.0 shipped, and has now moved to the "era of the tester" — except nobody realizes this, and it is hurting the company.

    [As an aside, William Poundstone managed to completely misquote me about testers in "How Would You Move Mount Fuji?", getting my argument backwards and making it sound like I was bagging on testers].

    Anyway you can read the book (it’s linked to online from my website if you don’t want to buy a copy) to get the full argument, it’s scattered throughout chapter 3, on pages 40-60. But please understand that I was trying to raise testers up to equality with dev and PM. I’m not sure what "He further rants negatively about testers especially in chapter 4" means but I don’t recall doing any negative ranting about testers. I rant negatively about the ATTITUDE towards testers. The quote on p. 50 about "for a variety of reasons they are viewed as lower on the pecking order than program managers and developers" is not me bragging about the way things should be, it’s me lamenting about the way they are.

    – adam

  9. Adam Barr says:

    I was just looking at the book and the discussion of testers continues into chapter 4, pages 61-69 or so.

    – adam

  10. Yo Adam, when’re you going to create your blog and start writing again?

  11. swetha says:

    this is software testing question

  12. Adam says:

    Great question, and I’ll answer it in my next post.

Comments are closed.

Skip to main content