Employee Spotlight: Radoslav Zlatev, Principal Engineer

Radoslav brings a passion for hard technical problems and a mathematician’s instinct for clarity to Tower Research Capital. As a Principal Engineer overseeing core aspects of Tower’s core trading platform, he is a key part of the team building systems that perform, scale and adapt to the diverse needs of our business. For him, great engineering is about writing software that works, then steadily improving it with discipline. And with programming languages and AI-driven tooling accelerating fast, he’s excited about how those advances will reshape how engineers reason about – and evolve – complex systems.

Read on for Radoslav’s perspective on mathematical thinking, engineering culture, and why simplicity is often the most powerful form of performance.To learn more about careers at Tower, explore here.

You completed a PhD in mathematics. How did that background shape the kind of problems you wanted to solve professionally?

I’ve always liked working on difficult problems. Grad school, though, teaches you to keep refining a solution until it reaches its most elegant and concise form. In software engineering, you have to balance that with pragmatism – often, having a quick working implementation matters more than coming up with a perfect one.

You help oversee Tower’s codebase – can you describe what that responsibility entails on a day-to-day basis?

There are a few parts to it. One is setting the overall direction for how the codebase evolves. Another is facilitating broad or cross-team changes – things that can’t be handled by individual owners alone. And the last is saying a hard “no” when you catch something that’s off. It’s a bit of a Sisyphean task, and it doesn’t always go as planned.

Tower has a performance-driven culture. How does that mindset influence engineering decisions?

It affects every decision you make – you immediately start thinking about memory access patterns or the CPU’s instruction cache. But the premature-optimization trap is real, so in recent years I’ve been encouraging people to write clean, correct code first – and optimize later.

Tower houses multiple independent trading teams. What does it take to build a platform that can support such a wide range of strategies?

This is one of our biggest ongoing challenges. Some strategies rely on specialized hardware for ultra-low-latency market making on the world’s most liquid exchanges. Others use neural networks that wake up every few minutes to rebalance portfolios through a broker.

Supporting both within the same platform means distilling each component’s boundaries, topology, and responsibilities to their most essential form – abstract enough to serve radically different workloads, but precise enough to compose into a coherent whole. Once that’s done, the implementation is usually straightforward or can be separated. When components are designed in this ground state, it’s easy to extend them with decorators, bridges, or adaptors as new needs emerge..

What qualities do you look for in engineers? What kinds of candidates tend to thrive at Tower?

Ideally, you want people who write software that just works – and who leave any piece of code better than they found it.

Everyone is different, but our top engineers tend to share a few traits: innate curiosity, attention to detail, and a drive to keep learning and improving. You also want people with the courage to challenge the status quo – tempered by integrity and grit, and by respect for the work that’s been done, or for the sometimes-elusive reasons why it was done.

These qualities reveal themselves quickly once you start working with someone, though they can be hard to spot in a one-hour interview. From personal experience, I’ve also learned to factor in whatever challenges or context a person might be facing in their life before drawing conclusions.

Tower has a long track record of innovation. Where do you see the most exciting challenges ahead for its engineers?

I think the most exciting challenges will come from two fronts: evolving programming languages and the rise of LLMs.

Each new C++ standard now feels like a new language. From C++11’s overhaul, to C++17’s if constexpr, to C++20’s concepts and (still-nascent) modules, and soon C++26’s reflection and contracts – we can express almost everything more elegantly and safely through the language itself. That expressiveness, in turn, enables LLMs to reason about and improve large codebases holistically – something that was previously infeasible.

The real challenge is knowing when to use these tools. Rewriting code for novelty’s sake isn’t progress; it has to be driven by clear business value.