Hire Test Automation Engineers: Rates, Vetting and Engagement Models

What a test automation engineer actually does, and where hiring goes wrong

A client came to us with 1,400 Cypress tests and a green dashboard. Their release confidence was zero. Nobody trusted the suite, because the way it stayed green was that an engineer had quietly added retries to the flaky specs, and when retries stopped working, added cy.wait(3000), and when that stopped working, marked the spec as skipped. Of the 1,400 tests, 260 were skipped, about 400 asserted nothing meaningful beyond that a page rendered, and the whole run took 51 minutes on a single machine. They had paid for two years of test automation and what they owned was a very expensive screensaver.

That is the job, and that is the failure mode. A test automation engineer is not the person who writes tests. They are the person who owns the answer to one question: when this pipeline goes red, does that mean the product is broken? Everything else follows from that. They design the page object or component model so a UI change touches one file instead of forty. They decide what belongs in a Playwright end to end test versus a React Testing Library component test versus a plain unit test, because pushing everything to the browser layer is how a suite gets to 51 minutes. They own the test data strategy, which is usually the real reason a suite is flaky. They wire the thing into GitHub Actions or CircleCI with sharding and parallelism so the feedback loop stays under ten minutes. They stub third parties with Mock Service Worker or WireMock so a Stripe sandbox outage does not block a deploy. And they hunt flakes with actual rigor, quarantining and fixing rather than retrying.

Where hiring goes wrong is that founders hire a "QA person" and get a manual tester who learned Selenium from a course. That person can write a passing test. They cannot tell you why your suite will be unmaintainable in eight months, and they will not push back when a developer asks them to add a wait instead of fixing the race condition. The other failure is the opposite: hiring a strong backend developer and expecting them to do this part time. They will build something clever, ship it, and never maintain it, because to a product developer test infrastructure is always the thing that gets dropped when the sprint gets tight.

Engagement models and the honest trade-offs

In-house SDET. Right when you have four or more product teams shipping daily, a suite over roughly 500 tests, and a real CI bill. At that scale the job stops being "write tests" and becomes owning a platform: the runner infrastructure, the data seeding service, the flake dashboard, the standards other engineers follow. That needs someone in your Slack every day, absorbing context. It is a bad fit for a 12 person company with one app, because the person will finish the interesting work in four months and then get bored and leave.

Freelancer. Good for a bounded, ugly job. Convert a Protractor suite off a dead framework. Get a Cypress suite running in parallel on CI. Write the first 50 API tests against a documented OpenAPI spec. Freelancers are cheap and fast on defined scope. They are risky on foundations, because framework architecture decisions bite you 18 months later, and the freelancer is gone by then. If you do use one for architecture, insist the design is reviewed by someone who will still be around.

Agency, fixed scope. Fits a one time build: stand up the framework, cover the critical paths, hand it over with documentation. You get a team, not a person, so a sick day does not stop the work. The trade-off is that agencies optimize for the deliverable, and the deliverable is usually "tests exist." Test count is a terrible metric. If you buy fixed scope, define the acceptance in outcomes: the suite runs in CI under N minutes, the flake rate over 30 consecutive runs is under 2 percent, and a named engineer on your team can add a test without help.

Staff augmentation. This is what we recommend most often for this specific role, and it is what Digital Heroes staffs most. You get a dedicated engineer who sits in your standups, learns your product, and reports to your lead, but you are not carrying a permanent seat for a workload that spikes during the build and settles into maintenance. It suits the shape of automation work almost exactly: heavy for one quarter, steady after that. The honest downside is that context lives partly outside your company, so you need documentation discipline and you need the engineer to train someone on your side.

Rates and what it really costs

These ranges reflect Digital Heroes delivery and what we see quoted in the market. They are not survey data and they move with region, seniority, and how much infrastructure work is in scope.

Offshore engineers in India, Eastern Europe, or Southeast Asia land roughly $25 to $55 per hour. The bottom of that band buys someone who writes tests against a framework you already have. The top buys someone who can design one. Nearshore in Latin America runs closer to $40 to $70 with better timezone overlap. Onshore US or UK contractors run $60 to $110 per hour, higher if you need someone who has done performance work with k6 or Gatling alongside the functional suite.

For an in-house hire, base salary in a US metro for a strong SDET typically sits around $95,000 to $150,000 in the offers we see, with senior people who own the CI platform above that. The mistake is stopping at base. Payroll taxes, health coverage, retirement match, equipment, software licenses, and your share of office and admin overhead push the real cost meaningfully above base, and we plan client budgets at roughly 1.25 to 1.4 times base. Add recruiting: an agency fee at 20 percent of first year salary on a $120,000 role is $24,000, and even hiring direct you are burning engineering hours on screening. Then add ramp. A test automation engineer is not productive on day one, because they need to understand your domain before they know what is worth testing. Three months to real output is normal, six is not unusual on a complex product. And there is a cost nobody budgets: your CI bill. A badly parallelized Playwright suite running on every push to a busy repo can add hundreds of dollars a month in runner minutes, and that number scales with your team, not your test count.

How to vet a test automation engineer

Skip the tool trivia. Anyone can recite Playwright's API. Probe for judgment about failure.

Ask: "Walk me through the last flaky test you fixed. What was actually flaky?" This is the single best question in the interview. A weak candidate says they added a wait or a retry. A strong one describes a real race: an optimistic UI update that resolved before the API call, a toast that auto-dismissed at 3 seconds while the assertion ran at 3.1, a test that depended on data another test in the same shard was deleting. They will talk about test isolation and independent data, and they will say retries hide bugs rather than fix them.

Ask: "How do you get test data into the system?" If they say "we click through the signup flow before each test," that is your answer and it is the wrong one. You want to hear API seeding, factories, per-test database transactions or per-worker isolated tenants, cleanup that runs even when the test fails. Test data strategy separates people who have run a suite at scale from people who have not.

Ask: "What would you not automate?" Everyone can list what to automate. Good engineers have a clear answer here: exploratory work, one-off migrations, anything where the UI is changing weekly, anything whose failure you would ignore. Someone who wants to automate everything will build you a suite you cannot afford to maintain.

Ask about selectors. "How do you locate elements?" A CSS-class-and-XPath answer means every restyle breaks their tests. You want data-testid attributes, or Playwright's role and label based locators, and you want them to say they will ask developers to add test hooks to the markup. That last part matters, because it means they see themselves as part of the engineering team, not a downstream consumer.

Ask about the runner config, by name. In Playwright: what does fullyParallel do to your tests, how do you use projects and a setup project with storageState so specs do not log in through the UI, when do you use test.step, and what do you upload as an artifact when CI goes red. In Cypress: what breaks when you try to test a flow that crosses origins, and what does cy.intercept with an alias buy you over a wait. For an API layer, ask whether they reach for supertest, REST Assured, or pytest with requests and why for your stack. Someone who has only ever run tests locally will have thin answers to all of these.

The take-home. Do not ask them to write ten tests. Give them a small running app with three deliberately broken things: one test that fails intermittently because of a real race, one selector coupled to a CSS class, and one test that depends on state from a previous test. Ask them to make the suite trustworthy and write a short note on what they changed and why. Two to three hours, paid. What you learn is whether they diagnose or patch. The patcher adds a wait and a retry and calls it green. The engineer fixes the race, swaps the selector to a test id, and makes the tests independent, and then tells you the third test was hiding a real bug.

The portfolio review. If they have a public repo, look for the CI config, not the tests. Does it shard? Is there a retry policy, and is it bounded and reported rather than silent? Is there a flake quarantine? Do they upload traces or videos on failure so you can debug a red build without rerunning locally? And check the ratio: a repo with 300 end to end tests and 20 unit tests belongs to someone who reaches for the browser by default, and that person will build you a slow suite.

Red flags

They lead with test count or coverage percentage. "I got them to 85 percent coverage" tells you nothing about whether the tests assert anything. Ask instead: "How did the team's confidence in deploying change, and how did you know?"

Hardcoded sleeps in their sample code. A Thread.sleep(5000) or cy.wait(3000) is a confession. It means they treat symptoms. Ask: "What is the difference between waiting for a duration and waiting for a condition, and when have you had to use the first one?" There are legitimate rare cases, and a good engineer can name one.

They only know one tool, and it is Selenium with no CI story. Selenium is fine and still runs plenty of production suites. The problem is the candidate whose entire world is recording scripts in an IDE with no view on where the suite runs, how long it takes, or who fixes it when it breaks at 2am. Ask: "Where does your suite execute, and what happens when it fails on the main branch?"

They have never asked a developer to change application code. A test automation engineer who cannot say "add a test id here" or "make this endpoint return a deterministic ordering" is not embedded in the team, and their tests will be brittle scaffolding bolted to the outside of your app. Ask: "What is the last change you asked a product developer to make so the app was easier to test?"

They talk about automation replacing manual testing. This one is subtle and it signals inexperience. Automation catches regressions in known paths. It never finds the bug nobody imagined. Ask: "What does automation not catch, and how should we cover that?"

When to hire this role at all, and how Digital Heroes staffs it

If you have under 5,000 lines of application code, no CI, and you ship once a month, do not hire a test automation engineer. Pay a strong backend or frontend developer to write API and unit tests as part of feature work, and put your money into getting a CI pipeline that runs on every pull request. Automation without CI is theater. If your problem is that features arrive half-finished and requirements are vague, you need a QA lead or a product person who writes clear acceptance criteria, not someone to codify the confusion in Playwright. If your product is a browser UI that changes weekly because you are still finding fit, automation will fight you, and API level tests plus a short manual smoke checklist will serve you better for another two quarters.

Hire this role when the same regression has bitten you twice, when your team hesitates before a Friday deploy, or when manual regression before each release takes more than a day. Those are the signals that the maintenance cost of a suite is now smaller than the cost of not having one.

Digital Heroes staffs this as a dedicated engineer inside your team, usually starting with a 3 month build phase. The first two weeks are diagnosis: we map your critical paths, look at where bugs have actually escaped, and pick the framework based on your stack rather than our preference, which usually means Playwright for a modern web app, Cypress if your team already lives there, and API level tests with Rest Assured, supertest, or pytest carrying the bulk of the coverage. Then we build the framework, the data seeding, and the CI wiring, and we cover critical paths first. We hold ourselves to run time and flake rate, not test count. After the build phase, most clients drop to part time maintenance, and the engineer's last job is making sure your own developers can add a test without asking anyone.