I love going out to college campuses and meeting students, chatting about their projects and giving them a coding problem or two.  Every college has its only flavor and emphasis - some focus on Java, others C or C++, and some C#.  The programming language doesn’t really matter – they all give us a chance to talk about a coding problem, tradeoffs with optimization and interesting things to test.  There are hands-on schools where coding skills are quite good while others tend to be more theoretical and students have less coding experience.  In general, coding skills aren’t as important as problem solving, raw smarts, and of course a passion for software.  Technologies and even languages come and go, so your ability to learn and ramp up on the next technology or language is more important that deep skills in the technology of the day if you can't learn the next.   This last Winter I made a visit to the University of Waterloo, Ontario. (We have several Waterloo alums on C# team.)  Waterloo has a really cool coop program where students take 6-8 coops over the course of their degree.  I never did an internship or coop during college, but wish I had – it’s a great learning experience.  I also got a chance to visit Virginia Tech, another one of my favorite schools.  While doing recruiting at colleges, we’re looking for great hires for any discipline (Developer, Developer in Test and Program Management) and any team at Microsoft.

My team (C# and the VS Debugger) is looking for Developers in Test (aka SDET), which is probably the least understood discipline outside of Microsoft.  Santosh wrote a nice blog entry on what it’s like to be a tester at MS.  Scott Guthrie, Product Unit Manager, of ASP.NET, also has a thorough description of the whole testing process.  Check out the jobsblog for a couple other good descriptions (Are you a good enough developer to be a Microsoft SDET? and 3 reasons to consider SDET ).  You can also listen to Peter Hauge's podcastThe biggest misconception about testing at Microsoft is that it’s not technical.  I think a lot of this perception comes from people’s experience working for software companies where testers primarily do manual testing and the ratio is on the order of 1 tester for every 10 developers (or even fewer).  In those cases, testers really don't have the time to dedicate to the technical side of testing.  Depending on the team, the ratio at MS is one SDET to one SDE.  SDET’s are essentially developers that work on the testing problem.  One of the coolest things about the SDET role in my opinion is the mix of creativity, technical and problem solving you get to apply to most testing problems.  Many times the design and implementation is a known quantity, but the testing can be approached from many different ways - restricted to your imagination really.

If you are interested in an SDET position send me your resume at rustym@removeme.microsoft.com.  Our C# and Debugger job descriptions can be found
here.

Rusty Miller
Visual C# Test Manager