Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been working as a Software Development Engineer in Test (SDET) at Microsoft for last 2 years and I am contemplating a change in role to a Software Development Engineer (SDE) position. I have a few questions regarding this career path change.

  • Does the IT industry discriminate between the two roles?
  • How hard is it to switch from Test to Dev role?
  • When do you think is right time to switch? The temptation to stay in current role (where you are familiar with Job and are already a good performer) and grow in level and then try a switch is high.
  • Does it become hard to switch roles after spending multiple years in Test?
share|improve this question

closed as off-topic by Justin Cave, MichaelT, James McLeod, Dan Pichelman, GlenH7 Nov 3 at 3:36

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Justin Cave, MichaelT, James McLeod, Dan Pichelman, GlenH7
If this question can be reworded to fit the rules in the help center, please edit the question.

3  
No one at MS has ever been through this before or considered it? –  JeffO Aug 15 '11 at 14:04
    
Just few clarification. My current role involves coding, it's just that code written by me is not getting shipped (and therefore less emphasis on quality and performance). I have seen few people making the transition, but number is low. –  Derek Aug 15 '11 at 14:09
    
An SDE is an SDE; delivery may differ but the the same could be said in transition from one company to another. –  Aaron McIver Aug 15 '11 at 14:23
2  
I agree with @Jeff O. I would talk to HR and see if other people have made the transition. Perhaps some SDEs that you work with have and would be in a position to tell you how it is at Microsoft and give better answers to your questions than random Internet people. –  Thomas Owens Aug 15 '11 at 15:53
    
For future reference, please don't cross-post the same question to multiple SE sites. –  Anna Lear Aug 23 '11 at 18:14

5 Answers 5

I have found that yes, it is difficult to transition, and many of the people I know who went the other way (Developer --> Tester) have found it hard to get back into development.

It is often very hard to find testers that have the ability to write code, and so are self-sufficient in writing their own test cases or test harness. Because of this, I have found that places would much rather keep good testers as just that, good testers.

I don't have any specific knowledge of what things are like at Microsoft with respect to that though. Ask your colleagues. If you can't find someone else at Microsoft who did the switch successfully, maybe there's your answer.

share|improve this answer
    
Apparently he's a programmer who writes tests. –  JeffO Aug 15 '11 at 16:51
    
Yes, I figured that's what the position and his skillset was. I just meant that a lot of the time, it's hard to find testers with s/w development skills who build tools & frameworks for effective testing, so that makes him an exceptionally valuable tester. Good testers are hard to find. –  Shawn D. Aug 15 '11 at 16:57
    
He may discover that his career path conflicts with their preferences. It would be a shame to have to leave. –  JeffO Aug 15 '11 at 20:16

I've known a few who went that route, and they did a pretty good job of it, but that was almost entirely due to their personalities and motivations. In some places, testers get some sort of script to run through and ensure that the script works, and maybe they explore a little bit outside the script for the sake of catching unexpected things. Other places, testers are told exactly what to do and to never stray. If you are the former, I'd say you're more likely to succeed, while the latter you are less likely. The reason for this is that to be a programmer, you really need independent thought, and the ability to really be creative and think outside the box. That's kind of cliche, but I've found it to be true.

When writing programs, there is no set way to achieve an objective. There may be generally accepted ways, even architecture documents and diagrams to help you along, but in my experience, when it comes down to it, the coder just has to figure stuff out on their own and get the job done; no one will tell them exactly how to do any specific task, because the bosses almost never know the code well enough (just the overall design) to understand what code changes really need to be made.

share|improve this answer

You'll have to be able to answer the interview question: Why did you accept this position instead of one in a department that ships? There are a few basic areas of why you did it:

  • took first job I could get
  • didn't realize I liked/was a fit for programming
  • misunderstood what a tester did/ discovered it's not for me

You'll have to be able to tailor the story to your situation and be convincing. Wanting a higher paying job or better career path is not going to cut it unless you can prove you're a really good program (Which should always be the case, but life isn't always fair.).

(This is not for going from a tester to developer, but to a department making products)

share|improve this answer

My first job out of college was a Software Engineer in Test, at a company that was attempting to emulate Microsoft's SDET program. The program was actually headed up by a former Microsoft employee that has worked in that department for quite some time. I took the job not really understanding that there was any distinction between it and any other programming job. I found myself writing a ton of C#, ASP.NET, SQL, and even a bit of SharePoint. In fact, I've never written that much code before or since, and I think it was an excellent experience for someone first starting out. But when attempting to find a job at the end of my tenure there, I was startled to find that the distinction in title was a very sore point and hindered me for sometime.

Here are my observations, I am assuming that this has been your first (or close to your first job). Also, keep in mind that I work on the east coast of the US, you my find it different where you are:

  • I think that it is important to know that even though Microsoft is very structured and differentiates between these roles (QA vs Programmer vs SDET), most of the industry does not. It is not even on their radar. Most places if they needed a role like this would just go out and hire another programmer.
  • Most, effectively all people, will look at the test part in the title and think QA and initial impressions are everything. Trying to explain this to a hiring manager, they never get their initial impression out of their heads. They think 'okay the QA guy that wasn't really QA'. This is poisonous when people are looking at a resume, and have 100 in front of them that they have to weed out, or explaining to recruiters who have zero time for anything that doesn't fit into their spreadsheets as a check off requirement.
  • I'd put your job title down as Software Developer, or Software Engineer, in the description put down very clearly that you worked in the SDET department, then explain that you focused on internal tools and frameworks (automated testing, reporting and the like) that increased the quality of the products.
  • It will be tough to have as many bullet points of skills on your resume leaving your job as you might have had otherwise. For instance, it might be hard to claim you were working with ASP.NET, if you were only testing an ASP.NET application and did little actually ASP.NET coding (despite the fact that you might need to know ASP.NET very well in order to write tools and such to test it).
  • Hopefully your knowledge will speak for itself during the interview. If your job was anything like mine, I can almost guarantee you'll be a better coder out of the gate than most people with your same level experience. Also, you'll have way better answers during an interview as well (you know first hand common mistakes that cascade into bigger problems, you know edge cases to be concerned with during initial coding, less likely to produce bugs).
  • If your experience was anything like mine, you will be surprised how applicable a lot of experience is. You will have had a larger role during the whole life cycle of a project. You might have had to interact with more Project Managers, Business Users, stake holders, etc, then you would have in the similar junior level position.

Overall, I am glad that I took that job. I learned a whole lot. I wish they had not had a different title though since I was doing a considerable amount of coding at that time and it hindered my job search later on. Today, I just put Software Engineer down my resume and have bullet points underneath with exactly what I did and was responsible for, and I do not believe this is a misstatement in anyway.

Having worked in maybe a dozen environments since then (as a full time employee or a consultant/contractor) I've observed that unless you end up a top notch shop later on, you will be appalled at level of quality most places put into their product. Having a build server, much less a continuous integration environment is a luxury. And I've never seen a shop that run test a suite of unit test against the latest builds as part of their CI set up since then.

share|improve this answer

It is certainly possible and I will add that some of the best software developers I have ever worked with started as testers.

In almost all occassions the ones that make the jump however are exemplary people who are bright, think outside the box, and are self learners who demonstrate their abilities.

Because of this the testers who are involved in writing test and deployment scripts tend to make the jump more often because they need some level of technical knowledge to do these tasks.

Unfortunately, many QA testers are trained to do manual functional testing which is important but leaves their technical skills lacking.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.