What does it mean to be an SDET (Software Development Engineer in Test) in Exchange?

Hi folks, KC here. As I've mentioned before, we have many open SDET positions in Exchange. I thought it might help to pull together a few resources such as a post from an SDET in Exchange in combination with the job description. So, here is the job description from Zoe:

Job Title: Software Development Engineer in Test

Responsibilities:
·          Design, develop and implement automated tools and test infrastructure for validating Exchange features and interfaces;
·          Participate in ongoing product specification and code reviews;
·          Translate customer requirements and product goals into appropriate tests;
·          Overall 60-80% of your time will be developing code in C++ (moving toward C#).

Consideration for open positions requires:
·          A Bachelors or Masters degree in Computer Science or Computer Engineering;
·          A minimum of three years of systems/server side programming in a professional environment;
·          A minimum of 1 year of testing experience in a professional environment and/or an interest in this type of development;
·          Solid understanding and demonstrated use of C, C++ and/or C#;
·          Experience with Windows 2000/2003.

Knowledge in one or more of the following areas is preferred:
·          C#, ASP.NET, XML, Messaging, SQL Server, Active Directory, IIS, or Windows Server, Exchange 

For more information about our product and vision, please see http://www.microsoft.com/exchange.

And here's a post from Anand about being an SDET:

I was in college 4 years back studying Computer Science towards a Master’s degree. Due to my core area requirements I can say I happened to take a class in Software Engineering. The class was called "Software Project, Process and Quality Management". That was my first real insight into Software Project Management and Testing. I liked the class so much that I decided to enroll in "Software Verification, Validation and Testing" the very next semester. This class nailed it for me. A developer at heart, I decided that I wanted to be involved in Testing but was not quite sure how I’d be able to get a job with the appropriate mix.

After graduating I ended up working for a big Wireless Telecom company as a Developer writing call routing programs in the mammoth GSM based product. The longer I worked there, the more I felt that my subsystem got lost in this sea of sub-systems belonging to sub-systems of subsystems… literally. I felt that I didn’t have the big picture any more. I mainly fixed bugs and felt that there was not much room for innovation in a mature product like the one I worked on.

Not being able to truly see how I affected the big picture, I started to feel frustrated with my job after the first year and decided to look elsewhere. I was really curious by the SDE/T position Microsoft had open at the time. Simply put, an SDE/T is a developer who works in a test team and not a development team. The SDE/T has a keen sense of a tester yet loves writing code and lots of it. The SDE/T enables the test team with the tools and processes that need to be in place for the testers to do what they do best… test the living daylights out of the product and find as many bugs as possible before it goes to the market. An SDE/T has the ability to analyze the functionality and architecture of a Product and thus design and implement tools that helps testers test it. The SDE/T enjoys short project life cycles, designs and implements many tools and test frameworks in a single year, uses the latest technology and has plenty of room for innovation. Though product quality is a prime concern, the SDE/T doesn’t have the stressful days that developers have during the end of a product life cycle. In layman’s terms… an SDE/T back-side is rarely on the line.J

This was my dream job. I wanted to mainly write code but be involved in testing a product. Seemed like a perfect fit. I’ve worked in Exchange’s Setup Test team as an SDE/T for the last two and half years and I’ve loved every bit of it.

I’m the kind of person that, given a piece of software that needs to be developed, I like to know how each and every piece of that project works. Microsoft products have thousands and millions of lines of code. Either you understand the big picture completely or the inner workings of a component that makes the whole. So, where is it that I can design and implement fully functional pieces of software? Viola… you can do this in SDE/T land. Over the past two and half years, I’ve developed 3 major tools that have radically changed the way my test team tests the product. In one instance, the tool was compelling enough for as many as 12 other teams that have adopted it in their daily testing. Now, I have the big picture of what I design and implement and I also have the complete understanding of the nuts and bolts that make up these tools.

The test team is unique and SDE/T is an integral part of it. An SDE/T relies heavily on the test experience of the testers and the testers in turn rely heavily on the coding experience of the SDE/T. It’s a completely symbiotic relationship that breeds one thing… more and more bugs being found.

There’s plenty of room for growth in this position. If you love doing what you are doing as an SDE/T then you can grow to become a Test Architect. If you want to get involved in management, then you can progress towards becoming an SDE/T Lead and then Test Manager. If you want to just code and not be involved with testing then you can take the path of becoming a developer. Many people take this path. If you realize that your heart belongs to testing, then you can become a tester.

I’ve been on some recruiting trips and I’ve seen that students have this notion that SDE/T and test positions are easier to get than a developer’s. Among the CS grads, almost all the strong candidates wanted to become developers even though some have a lot of passion for testing and the not so strong and weak candidates want to become SDE/Ts and Testers. I think we’ve done a poor job of selling the SDE/T and Test jobs. Somehow, there’s this notion that Testers and SDE/T are lesser mortals. This is not true. Each has its role. Without one the other could not survive. I’d like to see a development team ship a product without quality control and testing. It just won’t work.

Microsoft is a strong believer in Passion. If you don’t have passion for testing, then you will not make it as an SDE/T or as a Tester. People need to understand their strengths and their passions and follow the career line that fulfils their desire to enjoy doing what they are doing. If you don’t enjoy testing and don’t believe testing is an important part of the software life-cycle, you will not make it in our test organization. It’s like trying to fit a square peg in a round hole.

- Anand Vijay