SDET = Software Development Engineer in Test.  It isn’t a common title in the industry, and the job that goes with it isn’t common either.  The test teams at Microsoft build and run test suites to be sure, but it goes a lot further than that. 

As an SDET, you learn deeply about your product and customers—quality isn’t about code coverage, it is about making sure our customer’s experience with our products is the best it can be.  The SDET mantra is “what could go wrong?  SDETs participate in product design from the earliest stage, using what could go wrong to simplify confusing product behavior, avoid fragile designs, and build good diagnosis and recovery directly into the product.  In the SQL BI teams, many SDETs work directly with beta customers to see what can go wrong, and get it fixed before the product ships.

And then there is the scale.  Microsoft products ship on a huge variety of hardware and software platforms, often packaged in multiple ways. Test matrices explode.  So we have built some of the largest build and test automation systems in the world.  Some SDETs specialize in building innovation in those systems, and in other ways to automatically verify parts of the product.  SDETs may write more code than the developers do.

The flip side of scale is impact.  SQL Server is has the largest unit share of any database vendor: there are more people using this product for more purposes than any other.  And SQL BI has been driving the growth, so our products are seeing more new customers every day than almost anywhere else in the company.  Every product feature is used and every detail is magnifiedwe have to get it right.   Towards the end of the ship cycle, the SQL test teams steer the ship, with their daily activities focused on finding those shipstopper bugs and getting them fixed before the release is in customer hands.

So SDET is a key role at Microsoft.  What do we look for in an SDET?  A background in QA is helpful, but not required.  We are looking more for the fundamentals:

  • A passion for quality, for getting it right.  And the conviction and drive to achieve it.
  • Detail oriented, with the ability to think through what could go wrong?
  • Strong coding and debugging skills.  Structured languages like C# or Java are useful.  C++ even more so.  But if you've developed your share of giant script libraries, we know good coding skills when we see them.
  • Problem solving: how do we scale our automation systems and get better leverage out of our testing effort?
  • Ability to handle and prioritize multiple projects simultaneously.
  • Desire and ability to learn new products, new technologies, new customer scenarios.

And finally, a passion for our business—databases and business intelligence— is important. My team does ETL and so we care deeply about understanding multiple data systems, high-performance data processing, and user interfaces that are easy to use and productive.  And we care about data warehousing, the most common environment we are used in.  So while it is not necessary, experience with ETL, data warehousing or data centers in practice is a big plus for an SDET: there is nothing like being a customer to help us understand what getting it right should mean.

I hope this has given you a better idea of what being an SDET is like at Microsoft, and in SQL BI in particular.  And if you haven’t before, I hope that you will consider signing up for the challenge of being an SDET.   If you are the best, we’re hiring.

Here are some of the official job listings (we have multiple openings in each team):

Integration Services SDET posting.
Analysis Services SDET posting.

You can apply directly through those postings, or drop me a line. 

Denise Draper / Product Unit Manager of SSIS Team / denised -at- microsoft.com