Real Talk About SDET Hiring - From Someone Who's Been on Both Sides I had to smile this morning while reviewing some SDET job descriptions that landed in my inbox. They reminded me of my mother's shopping lists - you know, the ones where she writes down everything in the store just in case she needs it. Look, I get it. I've been heading automation teams for years now, and yes, we all want rockstar engineers. But here's what I'm seeing everywhere: "Required Skills:" - Must know every automation framework created since the dawn of testing - Should code fluently in roughly 4-5 programming languages - Must have mastered all CI/CD tools (including the ones still in beta) - Need expert-level knowledge in... well, everything Here's the thing - I've hired and worked with some brilliant SDETs over the years. Want to know what made them exceptional? It wasn't their encyclopedic knowledge of every tool in existence. The real MVPs in my teams have always been engineers who: - Really understand how to design robust test architecture - Have solid coding skills in one or two languages (and can learn others when needed) - Know how to pick the right tool for the job (not just the trending one) - Can explain complex testing concepts to non-technical folks - Actually think about maintainability (bless their souls) Let's be real for a minute. If you're posting job requirements that look like a copy-paste of the entire testing section of Stack Overflow, you might be doing it wrong. What if instead, we tried something radical - like being honest about what the job actually needs? Here's my approach: 1. List the core tech stack they'll use daily (the real one, not the aspirational one) 2. Focus on problem-solving abilities (because that weird edge case won't test itself) 3. Look for architectural thinking (because someone needs to think about the big picture) 4. Value learning aptitude (because today's hot framework is tomorrow's legacy code) After all, I've never met an engineer who simultaneously used Cypress, Playwright, Selenium, and Appium all in one day. And if you have, please check if they're okay. Fellow engineering leaders - what's your take on this? How do you cut through the noise when writing job descriptions? #SoftwareEngineering #TestAutomation #HiringInTech #EngineeringLeadership #RealTalk #SDET #QualityEngineering
- must understand and contribute to system architecture like our senior architect - must write code, set standards and lead engineers like our tech lead - must understand all our infrastructure, networking and security like our principal SRE - must deeply understand our product, develop our roadmap and create/refine user stories like our head of product - must be responsible for all risks, if something goes wrong, it's on you and what you missed - most importantly, must be ok with half the salary of anyone else on the team ... Over 100 applicants have applied for this role
SDET/QA/Testing/ blah blah has been a real mess over the years now ? You know why because it's a supporting role which a very few companies think of as a direct advisor for revenue generation. For e.g. if a major company x works starts with spring boot + cypress + appium it will disrupt the market making people believe this is the ultimate silver bullet but the reality is this role is about the quality and how we achieve it is secondary but the core of it will remain solid tech and product knowledge with actual customer experience. Tell me if this is an easy job .
One of the reasons why I feel such a thing happens is because of "Chinese Whispers" Delivery, fulfillment, bench, sales are most of the times, handled by different teams and the handshake is not so smooth (if it happens in the first place) Who do you need: Automation engineer Which tech stack: did not spend enough time discussing this Here is JD used for last opening, reuse and add this ask (unique to this JD) too Now it's bloated to an extent. Repeat this for 10 iterations and suddenly, we have a JD that's super bloated, unrealistic, catch all JD and everyone suffers. Shared ownership adds more salt to this injury 🤕
I agree. Some job descriptions really feel like they’re looking for a tester-turned-superhero—fluent in 5 languages, mastering every automation tool ever created, and somehow using Cypress, Selenium, and Playwright in the same day. Seriously, are they okay? 😂 The best SDETs I know focus on: ✅ Scalable, maintainable test systems. ✅ Smart tool choices (not chasing trends). ✅ Explaining complex concepts without a tech dictionary. Instead of endless buzzwords, let’s post roles that focus on real needs. And let’s be honest—today’s “must-have” tool is tomorrow’s legacy headache. What’s the funniest job requirement you’ve ever seen? Let’s hear it! 👇
The problem is, that things you mention, which are really valuable in the job, are not the things which are typically written in a resumee. No one writes "I think about maintainability" or "I know how to pick the right tool for the task" etc. The job descriptions abstract the genuine demand away and replace it with a list of keywords. Which presumably corresponds in some indirect way with the genuine demand. Because applicants do not know what your genuine demand is (as the companies usually do not know either) candidates follow the strategy to put in as much keywords as possible, hoping that some of them will find the needed associative connection in the head of the reader. And the companies may not know about their genuine demand in advance. Because, see, the skills you found to be useful is in fact an "a posteriori" knowledge. And even if they would include the a posteriori knowledge into the job descriptions, there always would be a tendency to "increase the chances" - which leads to extending the list of keywords in the requirements or selecting most ambiguous buzzwords.
I think we should carefully prioritize essential skills for the job over trendy keywords. I think - a clear job description should focus on core strengths like strong problem-solving, a deep understanding of software quality practices, and expertise in only a few critical tools or languages. And then the actual interview should 'walk the talk'.
Requirements these days are mostly setup by non technical teams. Secondly as mentioned by, SDETs or Engineers in majority should possess versatile skills instead of encyclopedia knowledge. It's not possible to know and implement every tool in the market.
What about testing acumen? What ever you talked about you can get from a good developer also ….
Your articles are an absolute goldmine please keep on sharing your knowledge ☺️
I agree. I worry about technology and tool emphasis above solid programming and design skills. Though not guaranteed, that sort of thing is evidence that maybe the hiring team sees SDET work as cookie cutter scripting instead of real development. For an SDET I want solid coding skills, solid testing skills.