Software engineering at quant firms: roles, skills and how to make the move

Engineering at a quant firm is often described as one job: write fast C++, sit next to a trader. That description is narrow enough to send people into the wrong process. Several firms publish their own engineering maps, and those maps show separate functions with different problems, different languages and different definitions of a good week.

This guide sets out those functions, what transfers into each from different engineering backgrounds, how to assess a team, and how to prepare. Firm-specific detail below is attributed to the firm that published it. None of it is a population statistic about the sector.

The engineering functions quant firms actually run

Two axes explain most of the variation. The first is what the code is for: getting orders into a market, or letting researchers ask questions of history. The second is where the team sits: embedded with one trading group, or owning a product the whole firm uses.

Hudson River Trading publishes a version of exactly this. It splits engineering into Trading Tech, the work needed to actually trade, and Research and Development, the work needed to run research at scale, and describes a second split between teams embedded with a trading group and teams owning firm-wide platforms. It says the quality bar is the same on both sides (Hudson River Trading, Engineering and Interviewing at HRT).

Firms resolve the same problem differently. Jane Street describes a deliberately small technology group covering programming, networks, IT operations, product management, data science and technical writing, with OCaml as the primary development platform across trading systems, tooling and research code (Jane Street, Technology at Jane Street). A small group with wide scope produces generalists; a larger divisional structure produces specialists. Both exist, and the interview you get reflects which one you applied to.

Five functions are worth naming separately, because the skills do not interchange.

Research engineering

The environment researchers work in: data ingestion, storage layout, simulation and backtesting, job orchestration, research libraries. The hard problem is correctness at volume and the ability to reproduce a result from six months ago, not microseconds. HRT reports its Research and Development side as roughly 70 per cent Python and 30 per cent C++ (HRT).

The interesting engineering here is usually invisible from outside: how a backtest avoids seeing data it could not have seen at the time, how a result is pinned to an exact code and data version, how a thousand experiments are scheduled without starving each other.

Execution and low-latency systems

Market data decoding, order entry, the live path, and in some firms hardware acceleration. HRT puts Trading Tech at roughly the inverse language mix, and names roles covering order entry and market data connectivity, inter-datacentre routing and the software that talks to order-entry hardware (HRT).

What distinguishes this work is not speed as an aesthetic. It is determinism: knowing what the worst case costs, not the average, and being able to show it.

Data and machine-learning platforms

Feature production, storage and compute scheduling, and the tooling that turns raw market and alternative data into something modellable. Jane Street lists machine learning as an interview discipline separate from technology, quantitative trading and quantitative research (Jane Street, Prepare for your interview), which tells you it can be a career rather than a rotation.

Infrastructure, systems and reliability

Provisioning, networks, datacentres, monitoring and alerting. This is a substantial function, not an afterthought. HRT describes a systems team building the platform that provisions and monitors the firm's servers and network equipment across both trading and research, mainly in Python with some Go, and published HeraclesQL, a Python DSL its systems developers wrote after thousands of hand-written alert queries became repetitive and hard to express (HRT, HeraclesQL).

That example is worth noticing for a reason beyond monitoring: the team's answer to a scale problem was to build a language. Infrastructure work at these firms tends to be treated as a product problem, which is a different job from keeping a fleet alive.

Full-stack and internal products

The interfaces people use to run the firm: real-time position and trading views, dashboards, control surfaces, internal tools. This is a career, not a waiting room for a core-quant seat. HRT's fullstack team published HRTWorker, a SharedWorker framework built because several open dashboards were each loading and processing the same real-time data (HRT, HRTWorker), and HRT lists Fullstack as a named role using TypeScript and Python (HRT).

The engineering constraint is unusual and genuinely hard: a browser showing state that changes many times a second, where a stale number is worse than a missing one.

Role and skills comparison

Language proportions and role names in this table come from HRT's published description of its own engineering. Read them as one firm's structure. Jane Street's OCaml choice is the obvious counterexample, and neither is an industry standard.

What transfers from your background

Product and web experience is not a disqualification, and full-stack work at these firms is not a lesser version of the job. What usually changes is the depth expected below the abstraction you use daily. HRT names a shallow understanding of fundamentals as the most common reason it turns engineers down (HRT); that is one firm's stated experience, and a reasonable thing to prepare for wherever you apply.

What published interview processes look like

Jane Street describes working through coding challenges in the tools you normally use, and says a finance background is not required across its disciplines (Jane Street, Prepare for your interview). HRT describes screens followed by onsite coding and debugging rounds, technical design discussion and team fit, with a choice of C++, Python or TypeScript with Python, and says it avoids puzzle questions that turn on a single insight (HRT).

Two firms are not a sector. What generalises is the shape of the question to ask: which rounds exist, what each one is assessing, and whether debugging or design carries more weight than raw coding speed. Ask that in the first call; most recruiters will answer it directly.

A worked example: framing a project you have already done

The instruction "explain your project well" is useless without a sample. Here is a complete one. The context below is invented for illustration, and the numbers are placeholders: the point is the structure, not the figures.

Illustrative scenario, not a real engagement. You maintained a nightly batch job that produced a risk report for a lending team. It was overrunning its window and the report was arriving after the morning meeting.

The weaker version. "I migrated our reporting pipeline from a nightly Spark job to an incremental design. It cut runtime substantially and the team was happy with it."

The stronger version, same facts, spoken in about ninety seconds.

"The report had to be on someone's screen by 07:00. We were finishing between 06:20 and 08:10, so roughly one morning a week it was late, and on those days the meeting ran on yesterday's numbers. I instrumented the stages first, because I did not trust my own guess about where the time went: about 70 per cent of it was re-reading the full history every night to recompute balances that had not changed.

"I moved to an incremental design keyed on the event identity the source already gave us, with a daily recompute of the previous seven days to absorb late-arriving corrections. That choice was the interesting part. Records arrived late often enough that a pure append would drift, so I made writes idempotent on that identity and accepted at-least-once delivery rather than trying to guarantee exactly-once across two systems.

"The failure I did not predict was a source that occasionally reissued a corrected record under the same identity. My write resolved conflicts by arrival order, so whichever copy landed last won, and on one account the original beat the correction. I found it because the daily recompute and the incremental path disagreed by a small amount there, and I had added that comparison as an independent check rather than trusting either path to police itself. The fix was to order by the revision number the source publishes alongside each record, keep the write idempotent on identity plus revision, and ignore any copy whose revision we had already applied. Ordering by arrival timestamp would not have helped, and making the timestamp part of the key would have turned a correction into a second row.

"After the change the 95th percentile finish was around 04:40 (illustrative figure) and we stopped missing the deadline. The cost was real: two code paths to maintain, and a replay now takes longer than the old full rebuild did. If the correction volume had been higher I would have argued for the simpler nightly rebuild on more hardware instead."

Why this version works: it opens with the constraint rather than the technology, names the guarantee it chose and why, shows the measurement, includes the bug the engineer did not foresee and how the evidence surfaced it, and states what the design cost. Use your own project and your own numbers, and only use numbers you can still reconstruct if someone asks how you measured them.

Preparation, by readiness rather than by calendar

Fixed schedules are guesswork: two weeks is plenty for someone who writes systems code daily and nothing like enough for someone who has not opened a profiler in three years. Work to readiness checks instead, and stop when you can pass them.

Readiness checks everyone should clear

• You can explain what happens underneath a data structure you use every day, in your strongest language, without notes.
• You can debug unfamiliar code out loud while someone interrupts you, and you narrate your hypothesis before your fix.
• You can deliver the project narrative above in ninety seconds, then defend any single sentence of it for five minutes.

Then work the checks for your target function

• Execution and low latency: you can describe the cache behaviour of a hot loop you wrote, read a profile without guessing, and say what your compiler did with code you wrote.
• Research engineering and data platform: you can explain a storage format trade-off, describe reprocessing semantics under late data, and discuss leakage and sample size with a researcher without bluffing.
• Infrastructure and reliability: you can design an alert that is actionable rather than noisy, and talk through one incident you owned end to end including what you changed afterwards.
• Full-stack and internal products: you can explain how you keep a high-frequency update stream from overwhelming rendering, and what browser primitive underlies the framework behaviour you rely on.

Market context is worth a little time, not a syllabus: order types, the difference between quoting and taking, what a fill is, why latency has value. Jane Street states candidates do not need to know about trading before joining (Jane Street), so treat it as conversational ground rather than an entry requirement.

Questions to assess a team before you accept

• Which division and team is this seat in, and is it embedded with a trading group or building something used across the firm?
• What proportion of the week is new development, support of existing systems, and operational work?
• Is there an on-call rotation, and what is in scope for it?
• Who sets this team's roadmap, and over what horizon?
• Has anyone moved between functions here recently, and what happened to their compensation when they did? HRT says it encourages rotation across its engineering dimensions (HRT); ask any firm for a concrete recent example rather than the policy.
• How is engineering contribution assessed, and how is variable pay determined?

Two things this guide does not tell you

There is no reliable timeline for the move, and engineering pay at these firms is not uniformly above large technology employers; it varies by function, seniority and market. Research is also not the destination. It is a separate discipline with its own interview process, and the five functions above are long-term careers in their own right.