For more than a decade, Cyrex has secured and stress-tested the products of some of the world’s most demanding technology companies, from global entertainment platforms to regulated financial and healthcare infrastructure. We’re a small team, but we’ve built a client list and track record that go well beyond our size.
Load testing is one of the things we’re best known for. Studios and platform teams come to us ahead of a launch, major release, or marketing push, the point where years of work suddenly meets a very large number of simultaneous users, with no opportunity for a second attempt. Our job is to simulate that moment before it happens, find what breaks, understand why, and work alongside the customer to fix it.
We do this using a load-testing platform we built ourselves. It’s mature, proven, and already in production. Part of your role will be keeping it that way: maintenance, bug fixes, dependency and infrastructure upgrades, and targeted improvements when an engagement requires them.
The platform spans a Go backend, two React frontends, and AWS infrastructure capable of spinning up enough load generation to put serious systems under real strain.Platform maintenance isn’t a full-time job, though, and we won’t pretend it is. The larger part of this role is the load testing itself. That starts with test engineering: designing scenarios that accurately model how real users behave and implementing them in Python against whatever protocols the customer’s system happens to use.
It also means working directly with customers. Our load testing is expert-led; we don’t hand over a dashboard and disappear. We work through iterations with the customer’s engineering team: agree on what we’re trying to prove, build the scenario, run the test, analyse the results together, identify the bottleneck, make changes, and go again. You’ll be part of those sessions and, as you grow into the role, expected to lead them.
That combination is why we’re looking for someone with range rather than a narrow specialist. This role sits somewhere between software engineering, performance engineering, systems analysis, and technical delivery, and you need to be comfortable moving between all four.
A practical note about the role
Some test windows happen outside normal office hours.
That’s the nature of the work: tests sometimes need to run when a customer’s environment is available, or when engineering teams across multiple time zones can participate.
It isn’t constant, and we plan around it when it happens, but it is a real part of the role and we’d rather be clear about that from the beginning.
We’re looking for an engineer who is genuinely comfortable moving across a stack and equally comfortable working directly with a customer. You write strong Python. It’s the language of our test scenarios and much of the tooling around them, so it’s where you’ll spend most of your development time. But you’re not attached to staying in one language: keeping the platform healthy means being willing to work in Go, TypeScript, Terraform, and AWS as the situation demands. You’re comfortable working in codebases you didn’t write. A mature platform benefits from careful, well-scoped changes rather than unnecessary rewrites. You can step into unfamiliar code, understand how it works, diagnose the actual problem, fix it properly, and ideally leave things a little better than you found them. You find systems under stress interesting. When something starts falling over at high concurrency, your instinct is to understand exactly why. You’re comfortable digging through metrics, traces, logs, and application behaviour until you can explain what is actually happening, and you know the first explanation is not always the right one. You can also communicate that reasoning clearly to customers. Not in a sales sense, but as an engineer: explaining what a latency curve is telling their team, challenging a test scenario that won’t answer the question they think it will, and staying calm and methodical when a live test produces an unexpected result. Our customers are technical. They rely on our judgement as much as they rely on our tooling. Finally, you’re pragmatic about the less glamorous parts of performance engineering. Test data, account pools, flaky protocol clients, awkward environments, and reproducing behaviour that only appears under load are not distractions from the job, they are the job. The engineers who do well here enjoy solving those problems too. The stack Test engineering: Python, using open-source load-testing tooling that we extend heavily Platform backend: Go, PostgreSQL Frontend: React, TypeScript Infrastructure: AWS, infrastructure as code, containers Protocols: HTTP, WebSockets, gRPC, protobuf, and occasionally bespoke binary protocols