
Ask HN: Developers – would you ever consider becoming an SDET? - grammernerd
TL;DR: If you are currently working as a developer, would you ever consider changing tracks to become an SDET - a developer who doesn&#x27;t work on front-facing code, but instead works on test code, internal tools, and does exploratory and computer-aided testing?
-----<p>I&#x27;m in the unenviable position of trying to hire an SDET(http:&#x2F;&#x2F;jobs.jobvite.com&#x2F;careers&#x2F;animoto&#x2F;job&#x2F;oWhy2fwx). It&#x27;s not easy.<p>Most of the applications you generally get for an SDET job (certainly in my experience in NYC, this may be different nearer to Redmond) are:
* Test Automators - people with experience writing automated tests, often in a proprietary scripting language. 
* New college grads who are just looking for anything with coding
* Developers who don&#x27;t really care about testing and want to get their foot in the door.<p>Now, any of those could work out great as an SDET if hired, but what I always hope for is someone with experience working as a <i>Developer focused on Test</i>, or even a Developer who genuinely wants to make the switch to SDET.<p>Of the SDETs that I&#x27;ve talked to, I&#x27;ve found that most wouldn&#x27;t rule out the possibility of doing some other kind of front-facing dev work, but I can&#x27;t remember ever meeting a developer who would go the other way. SDETs are rare and getting rarer!<p>If you search for &quot;SDE to SDET&quot; (just like that, with the quotes) all of the results you get back are STILL about switching from SDET to SDE! Apparently it&#x27;s unheard-of to move in the other direction.<p>So I&#x27;m curious; if you wouldn&#x27;t want to work as an SDET, why not? If you have switched to being an SDET, how and why did that happen?
======
MalcolmDiggs
It's an interesting question. I've always viewed SDET's as the red-headed
step-children within a dev organization...but I don't have a good reason for
feeling this way. It's a legitimate role, and takes a lot of skill. But for
some reason, when I'm on the job hunt, I never even come close to considering
positions that were labeled as SDET.

I'm not sure why SDET roles leave such a bad taste in my mouth. Maybe it's
because they're typically looking for junior devs, or maybe the role just
feels too removed-from-the-action.

Ironically, I've worked in positions that would be considered by some to be an
SDET role (I spent all day writing tests to raise the coverage on other
people's untested code) ...but those roles were advertised as "Senior Software
Engineer", and framed as "we need someone senior to come in and look after the
code that the junior guys are writing" so I felt better about it. I guess it's
all how you frame it. If you take the position that the role is less of a
janitor, and more of a manager, then you might attract more senior folks.

I your particular case, I'd also add the advice to remove the coding challenge
from step 1. As a senior/lead dev, I'm always up for a coding challenge during
the interview process, but only after I've touched base with a real human. I'd
never apply to a role that required a challenge up-front just to send in my
resume. Just my 2 cents.

~~~
grammernerd
A lot of this hits home. I like the idea of reframing the role as more of a
straight engineer - probably the the SDET title has become loaded and/or
widely misused. I think I probably also need to think some more about a solid
career track to get SDETs into a place where they can play the role of senior
engineers.

\- about the challenge in the job application - I actually did another Ask HN
about whether that was a good idea. Almost universal agreement that it was not
ensued, so I intended it to be very optional. I've not been penalizing anyone
who doesn't do it, but I immediately take notice when anyone does. Sounds like
I need to go back and work on making it more clear that it's optional.

------
poof131
Sounds like, “I’m looking for someone in the majors who is interested in
switching to playing minor league ball.” If you had a fantastic developer who
you could use to build new product that drives revenue or use them to write
tests for the current product, which task would you put them on? Which task
would your CEO want them on? Which task is going to get the most visibility in
the company and offer the best opportunity for promotion? If the org had a
huge issue with quality, I may temporarily put them on QA to get things
organized and structured, but after that I’d want them on new product or
refactoring current product for faster velocity.

A business can exist without tests, but tests can’t exist without a business.
I love and appreciate great QA people, but I also believe there is a hierarchy
and you can’t ignore it. You can offer a path up, either to manage QA or a
future switch to dev. You can offer to pay more for QA. You can integrate dev
and QA. But I don’t think you can realistically get the same caliber developer
at the same level in pure QA as in pure Dev without it being detrimental to
retention and the business. You can try to create parallel org charts for the
two roles, but the hierarchy will still form.

~~~
grammernerd
I think organizations make that kind of choice all the time. They take
fantastic devs and make them leads and managers in the hope that it will have
a multiplicative benefit on the business.

And they do devote resources to test - but by hiring testers. It might be
great if a company could devote some of its devs to test, but I suspect the
reason that they wouldn't is that the devs wouldn't want to.

I take the point about integrating Test and Dev, and probably it would need to
lead by example from the Test side...

:) I do also take your point about what actually happens in the real world.
This is the kind of response I was expecting - it's super helpful to see it
articulated.

------
faet
I was a software engineer at my previous job. I was mostly unhappy with the
environment (lack of challenge). My friend was a recruiter at a company and
was telling me about opportunities in said company. One of which was a SDET
roll. At first I was hesitant, but it isn't 100% testing. Although, I enjoy
the testing aspect.

Tbh, the biggest thing was 'getting my foot in the door' and they paid to move
me to a location more appealing. But, I've always enjoyed automation (bots,
scraping, fuzzing, etc) so it was a good fit for me.

The main concern with SDETs is the lack of mobility and lack of definition.
Many places I've seen that have SDETs just have a "SDET" roll. Maybe, a lead
roll as well. While they would also have SDE 1-5 + lead + management + etc. So
people feel there is no growth, you get in, you do your time, you get out.
Others are less dependent on the 'engineering' side. At my first job the SDET
didn't use visual studio at all, they used automated testing tools, where they
drag/dropped crap to make tests.

~~~
grammernerd
Lack of agreed definition, for sure. The title 'SDET' in itself doesn't at all
tell you enough about what a role is going to entail.

------
partisan
I don't think I would apply for a SDET job. The sense I get of such a job is
that I

\- would need to write automated tests, often in a proprietary language (yes I
am quoting you, but it hits the nail on the head)

\- wouldn't learn anything from the SDE perspective so it is a dead end if I
don't want to do SDET forever

\- would be under tight deadlines and would be encouraged to write
unmanageable code

\- would be working on rapidly changing APIs/UIs and so would want to write
unmanageable code because there is not too much reason to invest in quality
code that will be obsolete in a short time

Generally, it is a potential code monkey job, little skill and domain
knowledge required, and easy to outsource.

------
cakes
I could probably have been convinced at points but it's a hard bargain since
SDET career path almost feels like it requires SDET -> SDE. It helps that I've
done SDET in an environment where I was given the right mentoring/inputs that
I have a fondness for it. Otherwise, again, for career choices it seems like
SDET wouldn't last long.

Aside from career overall and given that I do enjoy automating things, playing
against bounds of things, etc. but, again from my personal experience and as
indicated, those skills are often in something that doesn't transfer (e.g.
proprietary languages) and/or is very product-centric.

------
meric
I'd do it if you offer equal or better pay as your other positions, and you
were in Sydney. I was the tech lead who introduced concepts such as code
reviews, jenkins, unit testing, code coverage into the company, so I have some
experience in that regard. I thought about asking if you'd hire remote but the
time difference is too much. Your challenge looks like a fun afternoon
otherwise.

------
zerr
You should have a hybrid position of SDE && SDET. So that prospective
candidates won't have that feeling - "I will be only testing other people's
code. I won't be able to work on new features" etc...

Also, remember that we're in XXI century, make it REMOTE.

