Load Test Engineer

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

• 4+ years of software engineering experience, with meaningful ownership of what you shipped.
• Strong Python skills. This is the core language for the role.
• Hands-on cloud experience, ideally with AWS, including infrastructure as code and containers , and an understanding of what happens technically and financially when infrastructure is scaled aggressively.
• Enough breadth to confidently maintain a typed backend and React frontend you didn’t originally build, even if neither is your primary specialism.
• A practical understanding of distributed systems and their failure modes, including timeouts, back-pressure, connection limits, resource contention, and the difference between a system that is slow and one that is actually failing.
• The communication skills to lead a technical session with a customer, explain what you’re seeing clearly, and make sound engineering recommendations.
• Excellent spoken and written English.
• 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.

• The opportunity to work on systems behind products used by very large numbers of people, at the moments when reliability matters most.
• A role that combines hands-on engineering, deep technical problem-solving, and customer delivery rather than being purely a ticket queue or purely consultancy.
• Real ownership of a mature load-testing platform that is already built, proven, and working, with the freedom to improve it as our needs evolve.
• Room to grow with Cyrex. As you build expertise and take on more responsibility, there are opportunities to lead larger and more complex engagements, deepen your technical ownership, help shape how we approach performance engineering, and grow into broader technical or team leadership roles.
• Direct contact with the engineering teams you’re helping, with the opportunity to become a trusted technical counterpart to some of the world’s most demanding technology companies.
• Direct access to founders and leadership, with decisions made in days rather than quarters.
• Competitive compensation with straightforward, regular reviews.
• A small, multicultural team where your contribution is visible and where there is room to shape your role as the company evolves.

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.