Hire Automation Test Engineers
The failure mode in test automation is specific and common: a large suite is built, it fails intermittently for reasons nobody can reproduce, the team learns to re-run it until it passes, and then stops looking at it. A muted suite is worse than no suite, because it cost money.
Discuss your projectFlakiness is the thing to hire against
A test that fails one time in twenty teaches your team that red does not mean broken. Once that lesson is learned, the suite stops providing information and the discipline around it collapses — people merge on red, investigate nothing, and the real failure that eventually appears is indistinguishable from the noise.
So the most important thing to screen for is whether a candidate treats flakiness as a defect in the test rather than an inconvenience to retry. Good automation engineers have strong opinions here: waiting on conditions rather than sleeping for a fixed duration, selecting elements by stable test attributes rather than by CSS paths that change with styling, controlling test data so tests do not depend on each other's leftovers, and isolating tests so they can run in any order.
The second thing is layer discipline. Driving a browser is the slowest and least stable way to verify behaviour, and it is where inexperienced automation engineers put everything. Most logic is better tested through the API, which is faster, far more stable, and easier to diagnose when it fails. Browser tests should cover the handful of journeys where the interface itself is the thing being verified.
What to interview for
These questions reliably separate engineers who have maintained a suite from those who have written one.
- What they do about a flaky test. The answer you want is diagnose and fix or delete, not add a retry. A candidate who reaches for retries first will hand you a suite nobody trusts.
- How they select elements. Dedicated test attributes rather than CSS selectors or XPath tied to layout. This single practice accounts for a large share of suite maintenance cost.
- Waiting strategy. Waiting for a condition, never a fixed sleep. Ask what they do about a slow API call in a test.
- Test data. Whether each test creates and cleans up its own data, or whether tests depend on a shared fixture that one of them mutates. The second produces order-dependent failures that are miserable to debug.
- What they would not automate. A good answer includes rarely-used screens, anything with heavy visual judgement, and exploratory work. A candidate who wants to automate everything will build something unmaintainable.
- Where to test what. Whether they would verify business logic through the API rather than the browser, and why.
- Coverage scepticism. Whether they can explain why eighty percent coverage with no test of the payment path is worse than thirty percent that covers what must not break.
- CI integration. Whether the suite runs on every pull request, how long it takes, and what they would do if it took forty minutes. Parallelisation and splitting by layer should come up.
What they work on
Building a suite from nothing
Starting with the handful of journeys where failure costs you money, getting those stable in CI, and widening from a trusted base rather than aiming for breadth first.
Rescuing an existing suite
Common work. Usually means deleting a large number of brittle tests, which is uncomfortable and correct — a smaller trusted suite beats a large ignored one.
API and contract testing
Where most logic should be verified. Faster, more stable, and better value per test than browser automation.
Mobile automation
Appium or Detox on real devices, which is harder and slower than web automation and needs realistic expectations about coverage.
CI pipeline integration
Making the suite run on every change, fast enough that nobody is tempted to skip it, with failures reported where developers will see them.
Performance and load testing
With k6 or JMeter, at realistic data volumes rather than against an empty database.
Common questions
Related in Staff Augmentation
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch