Office Professional 2007 blog are-you-a-good-enoug

So, as I used to be composing this post my laptop or computer completely crashed and I lost everything. Maybe this one will be better then the first – one can only hope the crash was a sign that my original post stunk up the place. This is the third time that my laptop has crashed this year and I have misplaced every thing on my hard drive. Um…can you say time for some new equipment?


Anyway – the whole point and intent of my publish was to talk about the Software Development in Test (SDET) position at Microsoft. We’ve been getting a lot of questions about the SDET role and with it are noticing that there are a lot of preconceived notions about the position. This is a difficult role to explain because a lot of other companies don’t have this type of function. There are test and quality assurance for sure at other software development houses, but Microsoft always seems to put a unique twist on the role.


I am going to do my best to describe the general nature of the position based on the recruiting experience I have. I have also consulted some SDETs,Windows 7 Professional, Test Architects and Test Managers on this information so hopefully it is pretty accurate.


General Description


To boil the SDET role down into its simplest form you can just break down the job title itself. It is a Software Development Engineer in Test. You know from previous posts about Software Development and Program Management that Microsoft core technical positions are basically divided into three categories – Development,Windows 7 Product Key, Program Management and Test. Gretchen also posted early on about Software Test Engineers. You should have a good understanding that these three areas work in conjunction throughout the development process in order to ship our products.

The SDET position itself is a role that combines two software lifecycle responsibilities into one contiguous role – Development and Testing. In other words, SDETs drive product robustness through designing, developing, and optimizing automated tests.

As with the other roles at Microsoft, there are many opportunities to work as an SDET across different product groups on different technologies. There are SDETs that work on system and server level, user interface, and applications and yes even test tool development.

The reason why I think that this role is so unique and cool is that it offers you the chance to become the gatekeeper of product quality and ultimately the bottom line of the company. As an SDET it is your responsibility to think of all the possible ways a product could fail, build automation to support those test (often producing even more creative code than some devs), and ultimately signing off on your particular area. If we don’t have this type of position our products ships with bugs, which makes the customer unhappy, which means they are unlikely to purchase again or they may tell their friends not to,Office Professional 2007, which leads to lower profits for the company. If you want to talk impact, this is an opportunity to really make a difference on a product.

Okay, so I had to sell the position a little bit in this post. Can’t blame a recruiter for trying! Anyway, there are some common job responsibilities for SDETs across Microsoft. Some of those include:

Planning – SDETs spend time in this phase working with their Program Manager and SDE counterparts to determine what features to work on and prioritize those features. They may also spend time doing research and investigation on how they will actually test the specification including building executable models.

Development – this is the heads down coding piece of the cycle. You take ideas and turn them into code. You may be producing automated test cases or new automation tools or both. Again most of the development that takes place is done in C/C++ and now more than ever C#. We also tend to look for people who have skills in different scripting languages as well – but they also need to have the hard core development background.

Test/Stabilization – Working with the folks from development you spend a lot of time analyzing failures and advocating bug fixes to make sure we are shipping quality code. You may also spend a lot of time debugging and suggesting fixes (both designing fixes and creating the code for them).

Release – In a sense this is when you are shipping the product. You also might be working on high priority fixes and then start planning again for the next release during this phase.

Again, I spoke with some folks about how they would break out the time they would spend in each of these areas. Based on a standard 12 month ship cycle, they said you could spend about 15% of your time planning, 30% of your time developing code, 45% in test and stabilization and the remainder on the release stage. In all, the amount of time that you will spend developing code is similar if not the same as any other developer at Microsoft.

This position is probably one of the most creative at Microsoft. Unlike some positions, you aren’t taking a specification and just implementing it. As an SDET you are the PM, Dev and Tester of your tools and samples. You also have the opportunity to design and develop samples that ship as part of SDKs or ship tools and diagnostic tests to our customers.

Career path

As with any role at Microsoft, describing a typical career path is difficult. It sounds cheesy, but it’s all about where you want to go today and how you envision your career in the future. There may be a couple different ways you approach that at Microsoft.

You might decide that you are ready and interested in taking on people management skills. This means moving into a lead or manager role. On the career site titles for these positions are Software Development Engineer in Test Lead or Manager. You may also see people take on the title of Test Manager as they fill out there teams with not only SDETs but STEs and be responsible for running the test labs as well. Again, you may still continue to own coding and testing at this point, but you will also have more scope over things such as planning, scheduling, resource distribution,Office Professional 2007, personnel management and meetings.

Or you may decide that you are interested in staying purely technical. Again, we you will have the opportunity to move into more of a “technical lead” type position. You won’t manage people, but you will be responsible for broader strategies,Office Professional Plus 2010, planning, meetings, etc. Sometimes on this path people move into Test Architect roles or they may move onto the last path.

Finally, you can continue as a senior level individual contributor. There is a lot of value in this role as we need people that can continue to contribute at a high level within the team. You might be given ownership of a broader set of features to work against without taking on the people management aspect. You may also be asked to mentor new hires and thus contribute to the overall wellbeing of the team. I forgot to mention this in similar posts, but I really do want o emphasize the importance of this role.

What I look for in an SDET as a recruiter

Just as in the other roles we have described, there are some key skills that I look for doing the phone conversation and on resumes. Again, this is just in general and there are skills that other teams look for outside of this area. One of the main differences that I look for when I am trying to find a SDE vs. a SDET is not just that you are an expert coder, but also an expert tester.

Technical skills – These vary by product team at Microsoft, but you have to have strong technical skills for most SDET positions at Microsoft. This means being able to understand the algorithmic ideas behind the code and software development fundamentals. Most of the people that I have hired into this role have come from a development background. Development is a key skill for this role and you must be able to code in C/C++ and/or C#. Most of the people that I have hired also have degrees in Pc Science or Laptop or computer Engineering.

Testing skills – This is another key skill to have for the role. You don’t necessarily have to have deep testing experience, but you have to have passion and interest in testing if you want this role. Can you think broadly and outside the box? How can you most efficiently and effectively try various combinations? How can you create dynamic, reusable tests? Can you break the product, both in traditional functional ways, but also in terms of security penetration, stress, etc.

Requirements analysis – Are you able to take requirements and specification information, analyze it and turn it into a model? What processes or methodologies do you use to analyze requirements? These are just some of the questions that I ask to determine if you have this skill set.

Passion for the customer – Some may think this is a given, but not in my book. You have to have an interest in making products better for the end user. How do you consider the end user when you are testing the product?

Again, these are probably just the basics. I think the two most important areas are the development/technical skills and experience/interest in testing. If you have these, I probably will be able to find you a great role at Microsoft as an SDET.

What usually doesn’t make and SDET at Microsoft

There are a lot of people with passion and interest in testing, but because they are lacking the technical/development skills we need aren’t a good match for the SDET role. Typically we are not looking for people that are:

Traditional manual testers – for this position we need people that have a strong ability to develop code that creates automation. Manual testers have a strong understanding of testing methodologies and principles perhaps, but in my experience not the code development skills needed for this position.

Quality Assurance and Requirements Analysts – From my experience these types of candidates again don’t have the development skills needed for the role. Analyzing requirements is only a portion of the skill set a good SDET needs.

WinRunner/Silk/Rational Robot experts – Yes, these are great test tools that save you time. Unfortunately, we need SDETs to build their own automation without relying on tools such as these. Again, people with this skill have great test but not the development experience needed.

Now, if you do work in this capacity or have these skills and write code then you may be a potential candidate for the SDET position.

Dispelling myths

There are three common myths that I hear about the SDET position when I am speaking with candidates:

SDETs are junior positions so someone with more than 3 years of experience wouldn’t be right for the position.

Absolutely not! Just as with the SDE and PM role we hire SDETs at various experience levels. We have to in order to provide a great product to our customer. In my experience recruiting for this position, I have hired people into this role with 1 year of experience all they way up to 10+ years of experience. I hope that is clear in the career portion of this publish.

The SDET is a stepping stone for an SDE position – a way to get your foot in the door.

If you are talking to me about the SDET role (or any position for that matter) please, please, please do not tell me that you only are interested in the SDET position to get your foot in the door for an SDE role. We encourage movement within Microsoft to better align to your career goals and sometimes is make sense for people to move to different disciplines. However, I would highly encourage you to NOT to take an SDET role if you feel that you will want to move to a SDE position in a year or less. You would be doing yourself and the team a disservice. I feel pretty passionately about this and already have another post queued up to address this topic

All SDETs do is testing and the work is not interesting or challenging.

Again, I hope of I have dispelled this myth as a general part of the overall publish. Just to reiterate, we require the same level of development ability for the SDET role as we do for the SDE position. Part of the job is testing, but that is not the only job responsibility you have. In terms of challenges, I think it is fairly easy to say that trying to figure out a way to ship the highest quality product possible is pretty challenging.

Summing it up


The SDET role is critical to the successful ship of a high quality product at Microsoft. Today we have roughly 300 positions open in this discipline and this is a critical hiring need for the company. I would highly encourage you to check out this position as a potential career path at Microsoft.


I was looking online for some resources about the SDET role. The best publish from Microsoft that I have seen on this role to date is one by Anand Vijay from the Exchange Server team. Otherwise, you can check out the main career site (though this doesn’t do the role justice) and the college recruiting site (this still applies to industry/experience folks) that has some information on SDETs.


There are some people waiting in the wings to write a post about what it is like to get an SDET. In the meantime, check out the references above and if you are interested in learning more about testing software here are a few other resources:


How to Break Software: A Practical Guide to Testing by James A. Whittaker

Testing Computer Software, 2nd Edition by Cem Kaner (Author), et al


As always, please feel free to let me know about other resources that are out there!



Your ever faithful moon gal,


zoë