Cyrex, a Magic Media company, is a media and tech start-up powered by creativity and innovation. We work with leading developers and publishers in the games industry, providing support and solutions designed around individual needs and carried out by global experts.
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.
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.
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
Requirements
Experience with performance or load-testing tools such as Locust, k6, JMeter, Gatling, or tooling youâve built yourself is a strong advantage.
Experience with games, real-time systems, or high-traffic consumer platforms is also useful, but not required.
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.
Benefits