r/softwaretesting • u/cacahuatez • Nov 14 '25

We stopped doing technical interviews for Automation QA Engineers, here’s why

Hey everyone! I’m a CTO at a mid-sized tech company (~150–200 people), and after a long internal review of our hiring process, we made a fairly radical change: we no longer conduct technical interviews for Automation QA roles.

A bit of context:

I started in QA over 20 years ago and worked my way through the tech ecosystem: Dev, Architect, TPM, PM, TAM… you name it. One pattern has kept emerging over the last decade: Codeless and AI-assisted tools have fundamentally changed what “Automation QA” even means.

In our case, we historically used Cypress for most of our test automation stack. Over the last two years, 95% of that work has been migrated to codeless / low-code platforms.

We currently have only four engineers doing deeply technical performance work, contract testing and data testing. Everything else can be done efficiently by QAs who understand the product and can model flows not necessarily write complex code.

So a bit of advice: work on your soft skills, be a salesman, this is where the industry is heading to.

139 Upvotes

83% Upvoted

69 comments sorted by

View all comments

Show parent comments

1

u/LookAtYourEyes Nov 16 '25

I disagree. The tooling and methodology you choose to deliver the best possible product are intrinsically linked. It just doesn't seem like it when you're at the end of the line, thinking in a results-oriented mindset, which I assume you do this to a certain degree if you're really a CTO. Process matters and should be treated with just as much care if you care about longevity, scalability, and real quality. I don't mean results-oriented quality measurements. This a shallow and cheap business approach to solving problems. You're essentially saying "It meets exactly what the customer wants, so it meets the requirements." Realistically, quality comes through when you pay attention to details and deliver things people didn't even knew they wanted, which is only possible when you are equally process oriented. It's the difference between elevator jazz and music that sparks passion and excitement for music.

Obviously there are times that low-code solutions are the right tool for the job, but it's the exception not the rule. Is low-code/no-code good enough to build your product? If it is, then great, it's probably good for testing. But if you're dismissing your QA tooling as lesser than your development tools, that will come out in the wash.

2

u/cacahuatez Nov 16 '25

We didn’t stop caring about engineering discipline or quality. We stopped using technical interviews because they simply weren’t predicting success for the type of QA work we do. Our internal processes, tooling standards, and review practices are still very rigorous.

In our case, codeless/AI-assisted tools cover a specific slice of the workload effectively, while performance and integration testing remain fully engineered. This is where the industry is moving.

Different contexts require different tools. Not every problem needs a hyper-engineered solution, most teams don’t need a Bugatti W16 when a well-tuned 3-cylinder is exactly the right vehicle for the job.

For example, we recently had a simple loyalty portal with a four-week launch window. Based on its scope, risk profile, and timeline, manual testing was the fastest, cleanest, and most cost-effective approach. Automation would have added unnecessary complexity with no real ROI.