Hacker News Reader

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.

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.

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.

If he really wanted a higher calibre for tests than for product, he could offer 10% more salary for test engineers, and let the test engineers be the interviewers. May be detrimental for business. But he'd get his top notch engineers in test.

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.

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.

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.

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.

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.

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.

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.

Ask HN: Developers – would you ever consider becoming an SDET?