Partilhar via

Looking for Good Software Developers In Test to Join Our Team

  • Artigo

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:

- Componentization

- Embedded Enabling Features

- Connected TV

- POSReady

If you think have any interest, let's talk. E-mail us at ewjobs@microsoft.com.

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:

  • Great coding skills
  • You get things done
  • Passion for quality in your own code and in other's code
  • You have an unquenchable thirst for knowledge in technology and science. You may be just as interested in Black Hole theory and nano-tech as you are in the latest release of .Net Framework.

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.

Examples -

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'?

Good question.

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:

  • You need a passion for quality not just in your own code but ensuring that your peer dev is doing the right thing
  • You need great coding skills so that you can recognize faults in other's code but can also deliver your own high quality / re-usable test code. You are representing the customer when you're in the code review meeting with your peers, it's your responsibility to ensure the dev is doing the right thing for the customer and their scenarios. If you're a sloppy coder you'll likely miss things that are not discovered until a customer has assembled the 'perfect storm' of software and hardware configuration that exposes a heinous bug. Having developers on the Test team deep dive into the feature code is a 'must have' for our team to be successful.
  • If you're on the Test team and you're not passionate about software or afraid to ask questions about how and why methods are implemented in the code to ensure the right thing was done, then this is the wrong discipline for you.

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