The engineering team had grown to forty developers without a dedicated QA hire. Every time someone suggested they needed quality engineering, the CTO had the same response: "Developers test their own code. We don't need testers. QA is a bottleneck from the waterfall era."
For a while, this philosophy seemed to work. The team moved fast, shipped frequently, and felt productive. Then the production incidents started accumulating. Customer complaints about bugs that should have been caught. A regression that took down the checkout flow for six hours. A data corruption issue that required a painful weekend of manual recovery.
The bugs that made it to production weren't exotic edge cases—they were scenarios that any competent tester would have caught in five minutes. The developers testing their own code weren't finding them because they were too close to the code, knew the happy paths too well, and didn't think like users.
"Okay," the CTO finally admitted after the fourth major incident in two months, "maybe we need QA."
But QA in 2026 isn't what the CTO remembered from early in his career. The role has evolved from manual test execution to engineering discipline. Modern QA is about automation, infrastructure, test strategy, and quality culture—not just clicking through the application after developers declare something "done." Hiring for it requires understanding what quality actually means in your organization.
At SmithSpektrum, I've placed over 80 QA engineers and SDETs across companies at every stage[^1]. The successful hires share certain patterns. The failed hires share different patterns. Understanding both helps you hire quality engineers who will actually improve your product.
The Evolution of Quality Engineering
The old model of QA is largely obsolete. In that model, QA was a gate at the end of the development cycle. Developers finished features, threw them over the wall to QA, and QA tried to break things before release. It was adversarial by design: developers versus testers, speed versus quality.
That model broke down for several reasons. Agile development cycles made the end-of-cycle gate impractical—when you're shipping every two weeks (or every day), you can't spend a week on manual testing. The complexity of modern systems made manual testing insufficient—too many paths, too many configurations, too many integration points to test by hand. And the cultural shift toward developer ownership made QA-as-gatekeeper feel like an organizational dysfunction.
The new model treats quality as engineering. SDETs (Software Development Engineers in Test) write code—not the product code, but the infrastructure that enables reliable quality. They build automation frameworks, design test strategies, create the tooling that allows developers to test effectively. Their work multiplies the quality impact of everyone on the team.
The distinction matters because it changes who you're looking for. Old-school QA required attention to detail and methodical execution. Modern quality engineering requires programming skills, systems thinking, and the ability to design testing infrastructure that scales. If you hire someone expecting the old model and give them the new job, they'll struggle. If you hire someone expecting the new model and put them in a manual testing role, they'll leave.
What Kind of Quality Engineer Do You Need?
Before you write a job description, you need to understand what problem you're solving.
If you have no QA at all and need to start building quality practices, you want a senior SDET or test automation architect who can establish foundations. This person will build your first automation framework, define testing patterns, and help developers write better tests. They're setting up infrastructure that will scale, not just running tests.
| QA Role Type | Primary Skills | Background | Typical Salary Range |
|---|---|---|---|
| Manual QA | Test case design, exploratory testing | Domain expertise | $70K - $100K |
| SDET | Automation frameworks, programming | SWE with QA interest | $120K - $180K |
| Performance | Load testing, profiling, infrastructure | DevOps or SWE | $130K - $190K |
| Security QA | Penetration testing, vulnerability assessment | Security background | $140K - $200K |
| QA Lead | Strategy, process, team management | Senior QA + leadership | $150K - $220K |
If you have growing test automation but it's becoming unmanageable, you want a quality platform engineer who can scale what exists. Test suites that take hours to run, flaky tests that nobody trusts, infrastructure that can't handle parallel execution—these are platform problems that require platform engineering.
If you have specific testing needs that automation doesn't cover well, you might still need manual QA specialists—exploratory testers who find the bugs that automation misses, accessibility specialists, or people with domain expertise in complex regulatory environments.
Most modern teams need some combination, with the balance depending on product complexity, release cadence, and quality requirements. A medical device company with regulatory compliance needs looks different from a consumer app shipping daily.
The ratio of QA to developers has compressed over time as automation has made quality engineers more leveraged. At ten developers, you might have one quality engineer. At fifty developers, maybe five to eight. At two hundred developers, perhaps twenty to forty. But these are rough guides—a complex product with high quality stakes needs more; a simpler product with more risk tolerance needs fewer.
Skills That Matter
For an SDET role, programming skills are non-negotiable. They should pass a coding assessment at roughly the same level as your developers. Someone who can't write clean, maintainable code can't build test infrastructure that will be maintainable. The specific language matters less than the ability—someone skilled in Python can learn JavaScript.
Beyond raw programming, SDETs need test architecture skills: how to design test suites that are fast, reliable, and informative. How to structure automation that's maintainable as the product evolves. How to build frameworks that other engineers can use effectively. This is systems design applied to testing.
CI/CD integration is essential because tests that don't run automatically on every change aren't protecting you. The SDET needs to understand build pipelines, deployment processes, and how testing fits into the development workflow. They're not just writing tests; they're designing how tests run and when.
Test strategy encompasses the judgment of what to test at which level. Unit tests versus integration tests versus end-to-end tests. What to automate versus what to test manually. Where to invest coverage versus where to accept risk. Good SDETs think strategically about quality, not just tactically about individual tests.
Communication matters because SDETs work across the organization. They help developers write better tests. They explain quality metrics to leadership. They advocate for quality investment when it competes with feature work. Someone who can only talk to other testers won't have the impact you need.
Compensation Reality
Quality engineers command strong compensation, particularly at senior levels where the gap between mediocre and excellent is enormous.
In major tech markets, manual QA still exists as an entry point but tops out relatively quickly—$80K to $120K base salary for experienced manual testers. Automation engineers who write test scripts but don't build infrastructure earn $110K to $150K base, with total compensation reaching $130K to $180K. SDETs who build frameworks and design test architecture earn $140K to $190K base, with senior SDETs reaching $170K to $220K and staff SDETs $200K to $260K.
The common question is how SDET compensation compares to software engineering. At junior levels, SDETs typically earn 85-95% of equivalent developer compensation. At mid levels, 90-95%. At senior and staff levels, the gap should close to near parity—95-100%. If you're paying senior SDETs significantly less than senior developers, you're signaling that quality work is less valued than feature work, and you'll lose your best people.
The premiums follow specialization. Security testing expertise commands 10-15% above standard SDET rates. Performance engineering—load testing, optimization, capacity planning—adds similar premiums. Mobile automation specialists are in demand. Machine learning testing expertise is increasingly valuable and increasingly scarce.
Sourcing Quality Engineers
Finding strong quality engineers requires looking in different places than typical developer recruiting.
Developer communities are often the best source because many strong SDETs have development backgrounds. They moved into quality engineering because they found test automation intellectually interesting, not because they couldn't make it as developers. Reaching them through general developer channels with messaging that emphasizes the engineering nature of the role works better than QA-specific channels.
QA-specific communities like Ministry of Testing, software testing forums, and automation-focused meetups reach engaged practitioners. But be aware that these communities span the full range from manual testers to automation architects—you'll need to screen accordingly.
Automation tool communities—Selenium, Playwright, Cypress, Appium—attract people who are serious about automation engineering. Active contributors to these projects or their ecosystems are usually strong candidates.
Referrals from your own developers can be excellent. Engineers know who the good quality people are from working with them. They know who writes tests that actually find bugs, who builds frameworks that other people want to use, who thinks carefully about quality strategy.
When reaching out, lead with engineering. "SDET role building test infrastructure for [interesting technical challenge]" performs better than "QA position." Emphasize the technical depth, the impact on product quality, and the career path. Strong SDETs have options; they're choosing you as much as you're choosing them.
The Interview Process
Assessment should cover both technical skills and quality-specific thinking.
Programming assessment should be roughly equivalent to what you give developers. A coding exercise that requires building something functional, solving a problem algorithmically, or debugging a complex issue. If someone can't pass your developer coding screen, they can't build the automation infrastructure you need.
Test design assessment explores how they think about quality. Present a feature or API and ask how they'd approach testing it. What scenarios would they cover? What would they automate versus test manually? How would they prioritize if they couldn't test everything? You're looking for systematic thinking, edge case awareness, and strategic judgment about coverage.
Framework design or review assesses their ability to build maintainable test infrastructure. You might ask them to design a test automation framework for a scenario, or to review existing test code and identify problems and improvements. This shows whether they can think at the architectural level or only at the script level.
Behavioral questions should probe collaboration and influence. How do they work with developers who don't prioritize quality? How do they handle flaky tests? How do they balance coverage with test suite speed? The best SDETs are collaborative partners who make everyone's quality work more effective, not adversarial gatekeepers.
Strong signals include: contributions to test frameworks (open source or internal), advocacy for quality practices that goes beyond their immediate role, understanding of CI/CD and how testing integrates with development workflow, ability to balance thoroughness with pragmatism, and communication skills that work across technical and non-technical audiences.
Red flags include: focus only on finding bugs rather than preventing them, adversarial framing of their relationship with developers, narrow tool knowledge without broader automation concepts, inability to discuss test strategy at the architectural level, and blaming developers for quality problems without proposing collaborative solutions.
Building Quality Culture
Hiring an SDET doesn't automatically create quality culture. The organizational context matters as much as the individual hire.
Quality must be a shared responsibility. If developers treat QA as someone else's problem—ship it and let QA find the bugs—you don't have quality culture regardless of how good your SDET is. The SDET's role should be to multiply everyone's quality effectiveness, not to be the sole owner of quality.
SDETs need influence, not just execution. They should have a voice in technical decisions that affect testability. They should be consulted on architecture and design, not just brought in after the fact to test what's already built. If they're relegated to writing tests for whatever developers produce, they'll be limited in their impact.
Quality investment must be protected. Test infrastructure is invisible until it fails. Without explicit commitment to maintaining and improving test systems, quality engineering will always lose to feature work in priority discussions. Leadership needs to understand and protect quality investment.
The organizational model matters. Embedded SDETs on product teams get deep context and close collaboration but can feel isolated from quality engineering peers. Central quality teams build expertise and shared infrastructure but can be perceived as bottlenecks. Many organizations use a hybrid—a platform quality team that builds shared tooling with some embedded quality engineers on teams that need deep specialization.
The CTO who declared "we don't need testers" eventually hired their first SDET. She didn't just find bugs—she built test infrastructure that let every developer write more effective tests. She established automation patterns that scaled with the growing codebase. She helped shift the team's thinking from "QA finds bugs" to "quality is everyone's responsibility, and QA makes everyone better at it."
A year later, production incidents had dropped 80%. Developer confidence in deployments had increased dramatically. The checkout flow hadn't had a significant bug escape in eight months.
"I was wrong about what QA meant," the CTO admitted. "I was picturing manual testers from fifteen years ago. Modern quality engineering is completely different. It's not about testing—it's about engineering quality into the system."
References
[^1]: SmithSpektrum QA/SDET placements, 80+ engineers, 2020-2026. [^2]: Ministry of Testing, "State of Testing Report," 2025. [^3]: Stack Overflow Developer Survey, "QA and Testing," 2025. [^4]: Google Testing Blog, "SDET Best Practices," various posts.
Hiring QA engineers or SDETs? Contact SmithSpektrum for hiring strategy and search support.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum