QA & Test Infrastructure Engineer

• Build data generation and anonymisation tooling so teams can test against realistic data without touching real client data. Confidentiality here is not negotiable.

• Manage environment parity and seeding, so a test that passes in CI means something about production.

• Own the lifecycle: refresh, reset, versioning, and cleanup, so test data doesn’t quietly rot into something nobody trusts.

Quality Signals and Flakiness

• Treat flakiness as a defect in the platform, not an inconvenience. Detect it, quantify it, quarantine it, and drive it down with data.

• Own the quality signals engineering runs on: coverage where it’s meaningful, test suite duration, failure rates, escaped defects, and change failure rate.

• Make those signals visible and useful to engineering managers and product leadership, and report honestly when the trend is going the wrong way.

• Analyse escaped defects to find the gap in the testing strategy rather than the person who missed it.

• Work with SRE so pre-production quality signals and production reliability data tell one coherent story.

Testing Probabilistic and AI-Enabled Features

• Build the test infrastructure for AI-enabled features, where the same input can produce different valid outputs and assert-equals stops working.

• Implement the techniques that do work: snapshot and tolerance-based assertions, schema and constraint validation, property-based testing, and deterministic seams around non-deterministic components.

• Build the infrastructure that AI evaluation runs on — harness execution, dataset management, and CI integration — in partnership with our AI Evaluation Engineer, who owns eval methodology and scoring.

• Help teams draw the line clearly between what a deterministic test should assert and what belongs in an eval suite.

Enablement and Practice

• Enable teams to own their own testing. Build the tooling, set the patterns, and hand it over rather than becoming the team that tests everything.

• Define and champion the testing strategy across engineering: what belongs in unit, integration, contract, end-to-end, and eval, and why the shape of that pyramid matters.

• Train engineers and test engineers on testing practice, including testing probabilistic systems, which needs to be taught as its own discipline.

• Review test approaches at design time and ask how a feature will be verified before it’s built, not after.

• Write documentation and reference implementations people copy.

What You Bring

• Hands-on engineering experience building test infrastructure, automation frameworks, or developer tooling. This is a software engineering role and you’ll be judged on the code you write.

• Strong programming ability in at least one of Python, Java, or TypeScript, and comfort reading all three. Our services span them.

• Real experience owning test automation in CI/CD, including the unglamorous work of making a slow, flaky suite fast and trustworthy.

• Working knowledge of Kubernetes and containers, enough to build and debug ephemeral environments.

• Experience with test data management, particularly where privacy or confidentiality constrains what you can use.

• Demonstrated experience with contract, integration, and end-to-end testing across a distributed system, and clear judgement about what belongs at each level.

• Familiarity with performance and load testing, and with reading the results properly.

• Interest in testing AI-enabled features, and an understanding of why non-determinism breaks conventional assertions. Prior experience here is a strong plus rather than a requirement.

• A platform mindset. You measure your work by what other engineers can do without you.

• Experience in a scaleup where you had to raise the quality bar while the product and team were still growing.

• Tool-agnostic judgement. We name our stack, but we’d rather hire someone who picks the right tool than someone who defends a favourite.

• FinTech or financial services experience is a plus. Willingness to understand what a correct financial output looks like is not optional — you can’t design good fixtures for a domain you don’t understand.

• Clear communication. You can write a testing strategy engineers will follow and explain a quality trend to leadership without over-simplifying it.

How You Work With AI

We’re an AI-first company, and that has to mean something more than having a coding assistant installed. We expect engineers here to have genuinely changed how they work.

• You use AI as a working tool across the job: generating test cases and edge-case fixtures, exploring untested paths in unfamiliar code, triaging failures and clustering flaky tests, drafting test plans, and writing the documentation nobody else wants to write.

• You go beyond prompt-and-paste. You’ve built or configured something (agentic workflows, automated triage or review, evaluation harnesses, custom tooling, MCP integrations) that made a repeatable part of engineering measurably faster or more reliable.

• You know where AI output cannot be trusted. A generated test that asserts the current behaviour rather than the correct behaviour locks in the bug. You verify, you review, and you can explain how you verified.

• You apply the same scrutiny to AI-generated tests as to any pull request: read it, challenge it, own it once you ship it.

• You share what works. A technique you discovered that stays on your machine is worth a fraction of one the whole team adopts.

If your answer to “how do you use AI” is autocomplete and the occasional chat window, this role will feel like a stretch — and we’d rather tell you that now.

You Will Excel If You…

• Question everything. A test suite with high coverage and no assertions, a flaky test everyone retries, a staging environment nobody believes: you raise it rather than work around it.

• Believe a slow test suite is a correctness problem, because engineers stop running it.

• Would rather build the tooling ten teams use than test ten teams’ features yourself.

• Find flaky-test investigation satisfying rather than tedious.

• Care that the numbers are right, because in our business a wrong number reaches an investment committee.

• Are comfortable owning something end to end, including the pager for the platform you build.

• Know the difference between pragmatic and sloppy, and won’t compromise on the former to avoid the latter.