Why I’m An SDE/T

WH writes:

I've got an on-campus interview with MS and I'm (hopefully) looking at an SDET internship.  I was wondering:  What do you like most about being an SDET?  What do you like the least?

The bug-finding problem space sounds completely interesting to me, but I thought it'd be best to get some thoughts from someone who's actively doing it.  Anything you have to say on the matter is appreciated.

Excellent questions! My answers forthwith:

What I like most about being an SDE/T is an answer in three parts:  First, I spend my day breaking things.  You mean I get paid to bang on stuff until it busts?  How cool is that?  Mindless banging works for awhile, but once you get past the obvious bugs (that even a *Dev* could find <g/>) you have to get smart and devious if you want to experience the unmitigated pleasure of watching your app melt down.

Second, I get to design and write code all day.  I'm a complete coding geek:  I stare at my computer screen all day, then go home and stare at it all evening.  And all weekend.  And on vacation.  I love to code.  Writing code to make my app die horrible deaths is pure heaven. 

Third, I have a pivotal role in making my customers happy by making my product the best it can be.  This may sound hokey, but really I do this to make your life easier by giving you a high quality product that solves your problems.  (A few of them, anyway; all of them is a bit out of my reach.)  Making my developers cry is just a fortuitous side effect.  <g/>

What I like least about being an SDE/T is postponing bugs.  I get very frustrated when I can't do as much testing as I would like to, or when a bug is resolved by anything other than fixing it.  I know there are marketing and financial reasons to release on a certain date with a certain set of features, and I'll sign off that my features are good enough to ship if they really are even though I think they could be better yet, but I would much rather ship a little later with a few less features but zero bugs.

Now that I'm a Test Technical Lead the amount of time I spend SDE/Ting is less and less, so let me answer the same questions about that role:

What I like most about being a Test Tech Lead is growing my team and helping them do great things.  I've always enjoyed helping other people learn, and that's a big part of my job now.  I have a great team to work with, too.  By no means is it a one way relationship, either; I get at least as much out of the relationship as they do.

What I like least about being a Test Tech Lead, without a doubt, is politics.  There's much less of it on my current team than there has been on other teams of which I've been part, but anytime a team has more than one person you have to deal with politics.  I don't really understand politics -- nor do I want to -- but so far I've done well enough to avoid getting fired.  <g/>

The best part of being a SDE/T at Microsoft is all the great people I work with.  A very smart friend of mine says he's intimidated by all the smarties running around campus, and I have to agree.  Knowing that everyone else in the room is way more intelligent than you is not exactly an ego booster, but it is good incentive to remedy that fact!  Intelligent people who are passionate about what they're doing -- you couldn't ask for better teammates.

*** Comments, questions, feedback?  Want a fun job on a great team?  Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com.  I need a senior tester and my team needs a dev lead and program managers.   Great coding skills required for all positions.

Comments (3)

  1. Kate says:

    Writing code to break other’s code is what I fascinate about. Hope I can get this kind of job in the near future.

    Now comes the question: When you write a tool to test other’s code, what makes you trust the code you wrote? Since you’re the ultimate tester (not your current role as a lead), how could you ensure your tool works fine? Could you please

    shed any light on this? Thanks a lot!

  2. The Braidy Tester says:

    Ah, yes…Who tests the test code? And who tests that code? And who tests that code? The short answer is "code reviews". The long answer will be my next post!

Skip to main content