It’s been over a decade since I last wrote something about HRT. A lot has changed since then. HRT is much larger, and we trade in many more venues and in many different time horizons. But I still feel like the fundamental vibe is, thankfully, similar.

We do now have a much wider variety of engineering jobs, which, generally speaking, is a good thing. But it can be a little difficult for someone interested in engineering at HRT to figure out what exactly is happening internally and where they may best fit. I’ve found myself repeatedly giving the same “spiel” during interviews, and I figured it’d make sense to just write it down so everyone has access to the same information. The remainder of this post should help you get a better mental model of the topology of engineering at HRT and then explain how to approach the interview. Please keep in mind that I cannot possibly address every specialty at HRT in a single blog post. So if you have a skill set that would work at HRT and it’s not explicitly mentioned here, please still apply, and our recruiting team will help you find the right fit.

And finally, this blog post is only about engineering. Algo Development (aka quantitative research and trading), People Operations, Accounting, and numerous other job families are critical to HRT’s daily operations, but in this post I’m going to stick to what I know best.

Engineering Roles

Before I dive into engineering role topology, I want to briefly describe how Algo (trading teams) work, because ultimately they are the customer all engineers work to support. Algo is composed of a bunch of different trading teams. They are very roughly organized by the time horizon at which they trade, and then by asset class and region. People in Algo mostly work on researching various models and algorithms used to trade on electronic markets. They also actively deploy and monitor their trading. One very important thing to note about Algo: it is not a “pod” system where trading teams are siloed with IP barriers. This is especially important for engineers because it means you can work across all trading at the firm rather than being contained to some specific group. If you come from big tech this may not seem all that interesting, but if you come from finance, you’ll know that this is huge for engineering. 

At a very high level, our engineering is divided into two major groups: Trading Tech and Research & Development. Trading Tech is primarily concerned with what needs to be done in order to actually trade, with special focus on “today”. This includes parsing high speed data from exchanges, placing orders with exchanges, applying hardware acceleration (FPGA/ASIC), processing trades, clearing, reconciliation, etc. Research & Development is primarily concerned with enabling research with focus on “history” (versus Trading Tech’s “today”). This includes storage, data centers, CPU/GPU clusters, job scheduling/orchestration, data ETL, and research tools for the Algo group (our trading teams). I’d say that Trading Tech’s language focus is something like 70% C++ and 30% python, and that Research & Development’s is roughly 70% python and 30% C++. The quality bar is identical: R&D’s C++ teams are as serious about C++ as Trading Tech’s, and Trading Tech’s Python teams are as serious about Python as R&D’s. Trading Tech’s biggest technical challenge is “latency,” whereas Research & Development’s biggest technical challenge is “scale”.

Each of these two divisions has both Acceleration and Platform teams. The engineering group dedicated to working most directly with specific Algo teams is formally called “Acceleration” (e.g. Trading Acceleration and Research Acceleration), because their job is to accelerate our trading teams’ activities. Informally you will often hear this type of job  referred to as “an embedded engineering” job. The idea is that the engineer is “embedded into” the trading team, often aligned with a particular trading strategy or specific sub-team of Algo Developers.

We refer to everything that is not “Acceleration” as “Platform.” Broadly speaking, platform engineers are dedicated to one or more products that are used across all of Algo. Typically, platform teams work on a longer time horizon and plan product roadmaps that take many different trading teams’ requirements into account, whereas the Acceleration teams work on more iterative tasks and help customize Platform products for their specific trading team’s needs. One thing to note that may be different from other companies, especially other trading firms: our platform engineers interact with Algo on a daily basis. The intention is not to put Platform behind a layer, it’s more about project focus. 

So far I’ve discussed two dimensions we used to describe engineering roles: research vs live trading and platform vs acceleration. The final dimension I use to describe engineering at HRT is programming language skills. I actually was going to describe this as systems vs application engineering, or low-level vs high level programming, but I think the language requirements for a specific role are a good proxy for this and are less abstract. Generally speaking, if you interview in C++ at HRT, you are expected to have a fair bit of low-level knowledge (i.e. how computers work). If you interview in Python, you are expected to still have some systems knowledge (e.g. understand how virtual memory works) but less specifics than the C++ jobs. And some jobs are a mix. There are also some jobs where the systems knowledge is especially important, like hardware/software interfaces, kernel programming, or systems automation skills. So I’m just going to count that as its own language skill (Low Level C++) even though it’s not a perfect abstraction. Broadly speaking, a given job can be one of the following, in rough order of low level to high level:

• Verilog (Hardware/FPGA)
• Low Level C++ (LLC++)
• C++
• C++/Python
• Python
• Systems Automation/Python
• Typescript/Python

At this point I want to note something very important (to me anyway): these dimensions describe jobs at HRT, but many people are capable of performing multiple jobs over their career and we actively encourage people to “rotate” between different jobs, across all of these dimensions. My favorite example is that I had someone start in a Research Accel job many years ago [Research | Accel | Python] and he expressed interest in FPGA programming. He is now the group lead for the hardware/software integration team [Live Trading | Platform | LLC++]. He was great at both jobs. That being said, if you are applying to HRT, I encourage you to start in a job where you will have the fastest immediate impact. That is—start with your strength. The more impact you have, the easier it is to move around. 

Specific Examples

Now I’d like to take a few examples (not exhaustive!) of various engineering roles across HRT and map them to these dimensions:

• Distributed Compute Engineer. This is a job working on the scheduling and orchestration software that runs our clusters. It’s probably about 60% C++ and 40% Python. This falls within the R&D division, but is a platform job (since all Algo teams use this software) and it’s a mix of systems and application programming. [Research | Platform | C++/Python] 
• HFT Research Accel Engineer. An engineering role to help with the research and post trade analysis for our high frequency trading group. [Research | Accel | Python]
• BAT Engineer (Build Autotest Tools). This engineer would work on our internal development tools platforms, which include large scale distributed test systems (aka “autotest”), distributed and cached builds, and many more tools used by all engineering and trading teams at HRT. [Research | Platform | C++/Python] 
• Fullstack Engineer. Our fullstack team happens to live within Trading Tech since we have more custom live trading GUIs than we do custom research GUIs. Arguably this team could span both Trading Tech and R&D – maybe it will one day! For now this role requires typescript and python [Live Trading | Platform | Typescript/Python]
• Core Markets Engineer. An engineer here will work on order entry and market data connectivity for particular exchanges across a variety of asset classes, in addition to improving the underlying platform and frameworks that back it [Live Trading | Platform | C++] 
• Trading Tech Infrastructure Engineer. Engineers on this team might work on: the infrastructure responsible for routing data between datacenters across low-bandwidth, low-latency links, or on the software that interfaces with the hardware used for order entry and market data  [Live Trading | Platform | Low Level C++] 
• Options Trading Accel Engineer. Devs on this team support our options market making trading team; they implement market data + order entry protocols to global option exchanges, solve latency & scaling issues in the live trading path, and also work on strategy & execution logic [Live Trading | Accel | C++]
• Systems Software Engineer. This team maintains the software platform that is used to provision, manage, and monitor HRT’s servers and network equipment. This platform is shared between our live trading and research environments, so roles on this team span both worlds. The work is primarily Python development (with some Go mixed in), but also deploying and running high-reliability services. [Live trading and Research | Platform | Systems Automation/Python]

If you navigate to our careers page, what you’ll see is a number of open roles on the website for a number of different teams, some of which were mentioned earlier in this post.  We recommend that you apply to the one that most closely mirrors your expertise and your interests. That said, we have most roles flowing through the same pipeline so we can adjust where you’re headed once you’re further along in the interview process.

What is an interview like?

The interview process begins with a series of Zoom calls. Depending on the role and the candidate, these can be exploratory conversations or jump right into technical phone screens. Eventually all candidates will go through technical interviews. 

Right now you can choose between C++, Python, or Typescript/Python (for Fullstack) as your programming language of choice. I should note that you may be given problems that require you to analyze code in an unfamiliar language to gauge your ability to pattern-match and adapt (but when we grade these problems, we take candidates’ language familiarity into consideration). 

If things continue to go well, you will be invited to onsite interviews.  We much prefer at least some of the onsite interviews to be in person (which is also good for you to get a better feel for HRT). The interviews vary slightly between some roles, but they are generally composed of coding and debugging rounds, technical design discussions, and team fit. 

We do our best to stray away from “burst of insight” leet-code style questions. Our ideal would be that a strong programmer from a competitive firm would ace our technical interview with no studying. We want engineers with strong fundamentals but stay away from obscura and “tricks”. Of course what constitutes obscura is subjective, but you can at least have an idea what our intentions are. I will say that most people do not fail the interview because they lack some specialized piece of knowledge. That brings me to the next section.

Common Interview Pitfalls

I’ve been asked hundreds of times for tips on interviewing, so I’m going to be as transparent as I possibly can. Instead of listing a bunch of generic sounding traits, let’s just assume we want the best engineers in the world, and I’ll list the most common reasons I see candidates fail interviews (in rough order of frequency):

• A shallow understanding of fundamentals. Many people use tools, libraries, techniques, and math and don’t have a true intuition for how they work. Often, the true nature of these tools is rooted in how they originated: why they were invented or designed in the first place. It’s not about esoteric knowledge, it’s about truly understanding something inside and out. If you use virtual classes, do you know how most compilers implement them? If you use python lists, do you know the memory growth characteristic as it expands? 
• Communication issues. If you think that software engineering isn’t just as much about communicating to your peers and your users as it is about writing code, then HRT is not the right place for you. We rate our engineers as much on communication as we do on technical ability. This is the ability not only to clearly articulate your thoughts but also to understand what others are thinking, which leads us to the next pitfall. 
• Listening and Understanding. I see so much interview feedback that says something like “the candidate didn’t fully understand the problem before they dove in” or “I couldn’t get a word in edge-wise”. This is not only a technical red flag, but also can be an early warning sign that someone isn’t accustomed to practicing empathy and understanding the people around them. It doesn’t matter how good your technical skills are if you cannot understand the human context around the technical work.
• Avoiding Real Work. In an interview, this could appear as candidates avoiding tackling problems directly or proposing overly complex solutions instead of simply coding a practical answer. At HRT we value individual contribution. We expect engineers and engineering managers to make individual contributions on a quarterly basis. This is why we administer the same technical tests to candidates at all levels, even if you were the CTO of your last company. Anecdotally, the Architect of Research & Development was formerly a CTO, and he can code circles around most engineers. Expect to program during the interview and expect to do measurable technical work on the job, regardless of your level. The best engineers at HRT are thriving because they regard this as one of the biggest perks of the job as opposed to a requirement. 
• Arrogance. I think this should speak for itself, but hey— this is finance. We get world-class candidates every day, and while we admire their achievements, we expect them to conduct themselves with a grace commensurate with their reputation. HRT is full of people that were the top of their class, their company, and their industry. The highest performers are those who make everyone around them better, not those who stand apart.
• Indifference. I often see feedback like “the candidate just doesn’t seem that excited”. We are not looking for people that are bubbly cheerleaders for HRT (hey – they already have me 🙂 ). But we want people that illustrate some passion about their work. This can be as subtle as pride in the quality of their work. Someone that is going to just treat this job like any other job should probably just get any other job.
• Cheating. Some candidates attempt to cheat the earlier stages by using LLMs and the like, only to find that the later stages are done in a manner that makes cheating significantly more difficult, and then everyone’s time is wasted. We do not welcome cheating candidates to interview again at a later time.

Conclusion

I intend for this post to be for people who are already interested in HRT and want to understand more about our roles and the interview process and so I didn’t include a whole lot of “sell” in this post. Bear with me for just a teeny bit of cheerleading. At the time of this writing, I’ve been with HRT for about 13 years. I have worked in big tech, gaming, government, and finance. This is, by a wide margin, the best company I have worked for. It is not perfect, but it is great, and it is great because of the people who make up HRT. Our interview process heavily screens for people who are not only brilliant, but also open, curious, kind, practical, and actually enjoy working. I’m not entirely sure why you’d have read all the way to this point if you weren’t already sold on HRT, but if you have and this sounds like you, please do apply!

-Joe