Are you a good developer who has a passion on quality and interested in working for the Windows Embedded Team? We have positions available for Developers in Test for the following teams:
- Embedded Enabling Features
- Connected TV
If you think have any interest, let's talk. E-mail us at firstname.lastname@example.org.
What's this about?
We’re hiring Software Development Engineers for the Test team (aka SDETs) and we’re looking for candidates with these traits:
Really, that's pretty generic isn't it? I'm not asking for specifics in C# or C++ or Win32 or Windows Internals or a Masters degree, etc...
That's because these are things that can be learned...and we're patient. We’re patient because we’re building the team for the long haul. Do not assume there are constraints to your success.
Re-read that first bullet up above. So if you've been a pure Java dev for the last 5 years and think you wouldn't make a good candidate because you hear everyone and their grandmother at Microsoft is coding in C, C++, C# then you might be wrong.
What matters is that your code is clean, reusable, high quality and that you're already comfortable with OOP. Hey, guess what? You met the bar for the first bullet! :-)
Again, it's the core developer competencies, passion for quality, getting stuff done and a thirst to know more that we mostly look for first in a candidate. Oh, you need to show that you have the ability to adapt and grow new skills of course since we're not just hiring to fill positions now but hiring for the future of the team.
Again, do not assume you have constraints to be successful and happy as an SDET on our team.
If you're familiar with the Embedded Windows platform we've delivered before then our team owns everything in that platform. If you're not aware of what comprises our product and its scope, here's our product team's portal, try this video introduction to the product:
Showcasing Windows Embedded Standard 7
Software Developer in Test, what is this?
Sure you can train almost any smart person to code, sometimes to even code well. Voila, you're now a programmer/coder/developer!
But what if the software you're shipping is delivered to millions of devices or PCs. Or what if the code was going to reside on a banking system or medical device? Being able to code or even code well just isn't good enough anymore when you think of it in those terms. This has been proven over the years especially seen in the terrible Customer Partner Experiences in Microsoft software in the 90's, so today quality software is a requirement of product teams.
Around 2000 or 2001 there was a shift within Microsoft with regards to how we validate the quality of the software that is shipping, in that we now staff the Test teams mostly with Developers. These SDETs work hand in hand with their feature peers in the Developer and Program Management teams to ensure that quality is being built into the product from day one and that every step of the way throughout the product cycle quality is considered and validated.
So now you're probably asking...
'As an SDET, how do you validate that quality'?
Part of the answer is through delivering our own software internally to exercise, monitor and attack the developer’s code as well as mimic as much of the customer scenarios as possible. What the SDETs can't test programmatically, like some of the end to end user scenarios, we'll have manual testers validate (most of this can be sourced out to our own lab or a remote lab).
So you can essentially look at the Microsoft Test teams as peer developers to the dev team, reviewing their design and code then making recommended changes to ensure it is meeting the customer's needs and is testable, then delivering on that test automation needed to exercise the dev's code.
Unlike the development team which a lot of times have boundaries placed around them with regards to how and what they deliver as their feature, you as an SDET have few boundaries! In fact you generally have quite a lot of freedom to design your test software.
To deliver on this encompasses all three of those bullets at the top:
One of the resources listed below is 'The Braidy Tester', here's a great quote of his from the article “Hallmarks of a Great SDET”:
A great SDET constantly invents new tools that help them find bugs. A great SDET sees a tool in every task they contemplate. A great SDET's driving force is writing code that breaks other code.
"Software Development Engineer in Test" doesn't tell the entire story. A great SDET is more than a great tester who happens to also be a great developer (or vice versa). A great SDET combines their deep knowledge of how applications are written with their deep knowledge of where bugs lurk and how to find them to create tools that help testers find more bugs and help developer write fewer bugs.
If you're interested in more details on the discipline in general here are some great resources:
- Embedded Windows Test Leads