You're about to start selling jobs in an industry that measures time in millionths of a second.

Start with one question, because almost everything else follows from it. Whose money is at risk?

A hedge fund generally manages capital on behalf of investors (pension schemes, university endowments, insurers, very wealthy individuals) and is paid for looking after it and for making it grow. A proprietary trading firm primarily risks the firm's own balance sheet. It may still have shareholders and financing, but it is not managing a fund of outside client capital and charging those investors management and performance fees.

That sounds administrative. It isn't. It shapes incentives, structure, risk appetite and (most usefully for you) who they want to hire.

How they earn, and what that does to the culture

Hedge funds are traditionally described as charging two and twenty: two per cent of the money each year for managing it, and twenty per cent of the profit. Treat that as the famous version rather than today's universal rule: real fee structures vary widely and have generally moved. The shape is what matters. A fund earns by attracting capital and generating a return on it, so it needs both performance and the credibility to raise money in the first place.

A proprietary firm has no management fee to fall back on. It lives directly from trading profit and loss.

That difference explains the culture better than anything on a careers page. When the reward depends on outcomes, being right matters more than being busy. And a candidate should understand that before joining. It suits some people and not others. Telling which is which, before they resign from a job they liked, is much of what you'll be paid for.

High-frequency trading is a style, not a species

HFT describes how a firm trades: very fast, heavily automated, often holding a position for a fraction of a second. It does not describe what kind of company it is. Proprietary firms are its most common home, which is why the terms get used interchangeably. They aren't synonyms. A proprietary firm can trade slowly, and a hedge fund can run high-frequency strategies.

One related term worth having: a market maker quotes both a price at which it will buy and one at which it will sell, and aims to earn the difference. It is not free money. The firm accumulates inventory it has to manage, and risks trading against someone who knows more than it does. That is precisely why speed and pricing quality matter so much to them.

Why they need technologists

At these firms technology can be the edge, not the support. And where that's true, the engineering budget stops looking like an overhead. You can see it from outside. They employ people whose whole job is finding microseconds. They put their servers in the same building as the exchange's matching engines. And some move trading logic onto field-programmable gate arrays, reconfigurable hardware that does a job without the delays of a normal software stack.

The underlying logic is that some opportunities are fleeting. Picture a £10 note on the pavement: whoever reaches it first takes it. In trading, price-time priority can reward being first, and a stale quote may be traded against before it is updated. This does not describe every trade or strategy, but where it applies a small speed advantage can convert into revenue. And the spending stops looking eccentric.

One structure worth recognising

The multi-manager or pod shop: many small independent teams, each given capital to trade and a limit on what they may lose, sharing infrastructure under one roof. It matters commercially because hiring decisions often sit with the pod rather than the centre. This changes who you are really selling to, and who can say yes.

Same title, entirely different job

A Senior Software Engineer at a multi-manager hedge fund and one at a market-making firm share a job title and remarkably little else. The first might be building research tooling and data pipelines in Python for a pod that wants an idea tested by Thursday. The second might be shaving microseconds off an order path in C++, close enough to the network card to care what it is made of.

Same words on the CV. Different problems, different technology, different people who want the job. Reading the firm rather than the title is the skill this academy is built around.

One piece of vocabulary unlocks a surprising amount. Funds are the buy side. Banks are the sell side. It is exactly what it sounds like (banks sell services, funds buy them) and once it clicks, half the language in this industry sorts itself out.

It is useful industry shorthand, not a map that perfectly contains every firm. Proprietary trading and market-making businesses do not always sit neatly inside it.

Investment banks

A large investment bank is several businesses wearing one name. It advises companies on mergers and flotations. It underwrites new debt and equity, putting its own balance sheet behind a deal so a company can raise money. It lends. It trades. And it gives other institutions access to markets they cannot reach directly.

Different businesses, different economics, and no single sentence covers them. What they share is scale. A bank processes enormous volumes that must settle correctly every day, under regulatory scrutiny, on systems that must stay available.

So the technology profile looks very different from a trading firm's. These are large, regulated systems where reliability and getting every transaction right is what counts. Not shaving microseconds. With one exception: electronic trading in equities, foreign exchange, futures and options is genuinely low-latency work, and banks run market-making desks of their own. Picture every bank engineer counting microseconds, though, and you'll misread most of the roles you see.

Asset managers

An asset manager invests inside someone else's objectives and obligations. As a fiduciary it looks after its clients' money (pension money, insurance money, retail savings) capital that has to be there in thirty years, invested inside mandates that constrain what the manager may do.

The technology problem is different in kind: less about microseconds, more about handling vast portfolios, reporting accurately to clients and regulators, and managing risk across thousands of positions at once. It may appeal to candidates who prefer large, long-lived investment platforms, fiduciary responsibility to clients, and problems shaped by client mandates, reporting and risk.

The line between an asset manager and a hedge fund manager is blurrier than it looks. Several large firms run both long-only and alternative strategies, and describe themselves as alternative investment managers precisely because neither label fits on its own.

FinTechs

Here is a pattern that has worked repeatedly: take one thing a bank does badly, do only that thing, and do it well on a phone in about four taps. Monzo on current accounts, Wise on sending money abroad, others on lending, payments and investing.

Treat that as a useful pattern rather than a definition. FinTech more broadly means technology applied to financial products or financial infrastructure, and a great deal of it is unglamorous plumbing sold to other businesses rather than an app you would recognise.

FinTechs often begin with newer systems and less inherited technology than an established bank. No thirty-year-old platform to work around, decisions made in days rather than quarters. That advantage reduces as they grow, acquire companies and take on regulation.

The label covers very different stages. An early-stage fintech may be living on investor runway with a handful of engineers. An established one may have millions of customers, real revenue, a banking licence and much of the same complexity as the institutions it set out to beat.

Wise now runs a broad international account and payments business; Monzo presents itself as a regulated bank offering current accounts. Neither is a startup. And treating every fintech as one will misprice your conversation with a candidate.

Startups and scale-ups

Two words used loosely; here is the practical working distinction we use at Stanford Black. A startup is early. Still establishing whether there is demand for what it makes, usually small, usually funded by investors rather than by profits. A scale-up has found that demand and is trying to grow quickly without breaking, which is a different and often harder engineering problem.

For a candidate the difference is concrete. Equity may be a bigger part of the package than at a bank or an established fund. So part of the reward rides on the company's uncertain future value, and that uncertainty is usually greater at an early-stage business.

So does ownership. At an early company one engineer may own a whole product. Thrilling for some, exposing for others. Working out which sort of person you're talking to is most of the conversation.

The tells. Evidence, not verdicts

You can often place a firm before you finish reading a job specification. Java and a large regulatory programme suggests a bank. C++ and microseconds suggests it isn't. And if it is, it will be one of the electronic trading desks. Equity in the package suggests a startup or scale-up. A long, formal, multi-stage process suggests scale.

Each of those is a clue rather than proof. The language, the technology stack, the size of the problem and the shape of the hiring process can each reveal more than the job title does. But read several together, and hold your conclusion loosely enough to revise it.

Forget finance for a moment. A market is two people agreeing a price. One wants to buy, one wants to sell, and somewhere between what the buyer will pay and what the seller will accept, they meet. Everything else in this chapter (exchanges, brokers, clearing houses, risk checks) is machinery built around that single act to make it happen millions of times a day between strangers who will never speak.

What gets traded

Four categories cover most of it. Shares are slices of ownership in a company. Bonds are loans to a company or a government, repaid with interest. Currencies are exchanged against one another, which is what foreign exchange means. Commodities are physical things (oil, wheat, metals) or contracts on them.

Where it happens

An exchange is a venue where orders meet. The London Stock Exchange, CME, Euronext. A broker arranges access and executes on a client’s behalf, for clients who cannot or do not want to connect to the exchange directly.

Not everything trades on an exchange. A great deal of activity happens directly between two parties, which is called trading over the counter. Large bond and currency trades often work this way. If you assume every trade passes through a public exchange you will misread a large part of the market.

The price is two numbers, not one

This is the single most useful thing in the chapter. In a quoted, two-sided market you will normally see a best bid (the highest price someone is willing to pay) and a best offer, the lowest price someone is willing to sell at. The gap between them is the spread.

If the best bid is 100 and the best offer 101, the spread is 1. Buy now and you pay 101; sell now and you get 100. A market maker aims to capture some of that spread while managing inventory, fees and the risk of trading against better-informed participants. Which is why an entire category of firm cares so much about quoting quickly and accurately.

Two orders you will hear constantly. A market order prioritises immediate execution over price: it will normally execute where willing buyers or sellers and a functioning market are available, but neither execution nor price is universally guaranteed. A limit order controls the worst price the trader is willing to accept, but it may not execute at all. Almost every trading system sits somewhere in that trade-off.

Liquidity is how easily something can be bought or sold without moving its price. A liquid market absorbs your order; an illiquid one moves against you the moment you try to trade in size. Volatility is how much a price moves about. High volatility means more risk and, for some firms, more opportunity. Which is why certain clients hire hardest when markets are chaotic.

Betting on down as well as up

A long position generally gains value when the underlying price rises. A short position generally gains when it falls (which surprises people the first time they hear it) although financing, fees, leverage and the method used all affect the final result.

Short positions can be constructed in several ways: borrowing an asset in order to sell it, or using derivatives. The risks differ by method. What matters here is that a firm can make money when prices fall, because a great many funds describe themselves as long/short and you need to know what that means.

The life of a trade

An idea becomes a position through a sequence of steps. The broad shape is similar in most places, but the detail varies a great deal. An order sent to an exchange may be matched electronically against another order; an over-the-counter trade may instead be agreed through a dealer, a platform, or directly with a counterparty. Clearing does not apply to everything, and settlement timescales differ by product and market.

Try putting them in order below. Most technology roles in this industry live at one point on this line, and knowing where a role sits tells you more about the day-to-day work than the job title does.

Five ways to be in the market

The same instruments get traded by firms doing quite different things.

Investing: committing capital for a longer-term objective, expecting returns from price rises, income or both. The horizon is usually longer than short-term trading, if not always measured in years.

Discretionary trading: a human makes the call, supported by data and technology. Systematic trading: models or preset rules drive the decision, and execution is often automated.

Market making: quoting both sides continuously, aiming to capture some of the spread while managing inventory and risk. High-frequency trading: not a category but a style, defined by speed and automation, and usually sitting inside market making or short-horizon proprietary strategies.

Many firms do more than one. The distinction that matters for you is who decides and how fast, because it predicts the technology, the team and the kind of person the client wants.

Why any of this matters to a recruiter

A client who says they need someone who understands the whole trade lifecycle is not being vague. They mean the role touches several of those steps, or has to work with the teams that do, and that a candidate who only knows the moment of execution will struggle.

You are not being asked to trade anything. You are being asked to hear “pre-trade risk” or “post-trade settlement” or “execution” and know roughly where on the line that sits, what the engineer is optimising for, and what the sensible next question is.

This is the chapter people dread, so here is the central idea before anything else. Technologies are selected to solve problems inside an existing system. They are not a league table of which language or platform is best.

Nobody is going to ask you whether Python is better than C++. They are going to ask why a firm chose one, and the honest answer is almost always about the problem, the ecosystem around it, and what already exists that the new thing has to live with.

The layer cake

Software does not run on its own. Underneath every application there is a stack of things that have to be there, and each layer is somebody’s job.

Picture it as a stack, each layer resting on the one below. Software is the application. The thing that does the job. It runs on compute (processors doing the work) and keeps things in storage as data. It sits on an operating system, which manages the hardware for it, and talks to other machines over a network. Underneath it all is infrastructure: the servers, connections and services that keep the whole thing standing.

We are using “the technology stack” broadly here, to show what software depends on. Be careful with the job title full-stack engineer: that normally means someone working across the user-facing front end and the server-side back end of an application, not someone who is an expert in every infrastructure layer.

Operating systems, and why Linux keeps appearing

An operating system decides which programme gets the processor, where memory goes, and how a request reaches the network card. Most of the time you never think about it. Unless microseconds matter, in which case you think about very little else.

Linux runs across server and cloud infrastructure, and powers critical production-trading platforms at firms in this market. That is why Linux experience shows up so often in technical hiring.

It is open source, so it can be modified and tuned. And firms that care about latency tune it heavily. That is why “Linux engineer” is a discipline, not a line on a CV.

Languages are chosen for problems

Eight names cover most of what you will see. These are typical uses, not exclusive ones, and the table is not a ranking. Every one of these languages is used well outside the row it sits in.

You do not need to write any of them. You need to know that a firm asking for C++ and one asking for Python are usually solving different problems. And that the second question, the useful one, is what the candidate built with it.

Data, and where it lives

A database is an organised store you can ask questions of. Market data is the price and trade information pouring in from venues. And in this industry it arrives in enormous volume, fast, and has to be handled accurately.

A lot of engineering is just moving that data from where it lands to where it can be used. That is what data engineering means.

Cloud is more than renting computers

The opening analogy is that cloud means using someone else’s computers instead of buying your own. That is a useful start, but incomplete: cloud providers also supply managed platforms, storage, databases and services that a firm would otherwise have to build and run itself.

Firms may use public cloud for some workloads while keeping others on dedicated or internal infrastructure, because of latency, control, cost, security, data or regulatory considerations. A research team may run enormous experiments in the cloud while the trading path stays on machines the firm owns, in a building it chose deliberately. Asking which workloads sit where, and why, is a far better question than asking whether a firm “uses cloud”.

Artificial intelligence, minus the marketing

Machine learning is the development of systems that learn patterns or adapt from data rather than being explicitly programmed with every rule. Generative AI and large language models produce text, code or images from patterns learned in training, and answering a request is called inference. All of it depends on data: quantity, quality and the right to use it.

The word appears on a great many job specifications, and it is worth distinguishing four situations. AI can be the product. The company sells it. It can be a feature inside a larger product. It can be an internal tool that helps staff work faster. Or it can be marketing language attached to something conventional.

Working out which one you are looking at is a genuinely useful skill, and asking politely is usually enough. A short set of questions does it: what does the system do? Which model or service does it rely on? What data does it use? How is the output evaluated? And what happens when it is wrong?

Networks and security

Networks carry data between machines, and in this industry the physical route matters: a longer path takes measurably longer, which is the whole reason co-location exists. Cybersecurity protects systems and data from attack, and in financial services it is heavily regulated and continuously tested. Both are specialisms with their own labour markets.

Infrastructure underpins all of it (the servers, connectivity and services that keep everything running) and the tools used to build, test and release software safely are their own discipline again.

What to do with all this

Nothing here makes you technical, and it is not supposed to. It should mean that when a client says they need a C++ engineer with kernel experience for a co-located system, you know roughly what each of those words is doing in the sentence, and can ask what the system does rather than nodding and hoping.

This chapter is about the people you will place. Same aim as before: recognition, not mastery. You are not going to learn to do these jobs, and you do not need to.

What you need is sharper. Recognise each role. Spot when one job title is hiding two different jobs. And know the questions that turn a list of technologies into evidence.

The role families

A quick tour. For each one: what they do, the problem they own, the clue you may see on a CV, and the trap to avoid.

Software engineer. Does: builds software and the systems that run it. Owns: making something work, and keeping it working. On a CV: the broadest, least informative title here. Trap: taking the title at face value instead of asking what they build and where it runs.

Quant researcher vs quant developer. Does: the researcher devises and tests the models; the developer turns them into production systems. Owns: the idea, versus making it run reliably, fast and at scale. On a CV: “researched and back-tested strategies” versus “built and optimised the production system”. Trap: pitching a researcher into a build role, or the reverse.

Data engineer. Does: moves data from where it arrives to where it can be used, reliably and at volume. Owns: the pipelines and plumbing, not the analysis at the end. On a CV: pipelines, streaming, very large data volumes, tools like kdb+ or Spark. Trap: confusing them with a data analyst or scientist, who work on the data once it has landed.

Platform engineer vs Linux/infrastructure engineer. Does: the platform engineer builds the platforms and services others deploy onto; the infrastructure engineer works closer to the metal. Owns: developer self-service, versus the servers, networking and operating system underneath. On a CV: “internal platform, Kubernetes, developer tooling” versus “kernel, networking, OS tuning, latency”. Trap: treating the two as interchangeable when you qualify the brief.

DevOps vs site reliability engineer. Does: DevOps automates the path from writing code to shipping it; an SRE keeps live services reliable. Owns: “ship faster and safer”, versus uptime: service-level objectives, error budgets, on-call. On a CV: “CI/CD, release automation” versus “on-call, incident response, reliability targets”. Trap: reading one when the client actually needs the other.

Cybersecurity engineer. Does: protects systems and data from attack; in financial services, heavily regulated and constantly tested. Owns: keeping the firm defensible, and able to prove it to regulators. On a CV: incident response, threat modelling, security clearances, compliance regimes. Trap: assuming security people move for the same reasons as application engineers. Qualify their motivation on its own terms.

Now the habit that matters most. Two people can both be “Senior Software Engineer” and do almost unrelated jobs.

One is building data pipelines in Python for a research pod that wants an idea tested by Thursday. The other is shaving microseconds off an order path in C++, close enough to the network card to care what it is made of. Same three words on the CV. Nothing else in common.

Read the firm and the problem, not the title. It is what stops you sending a strong candidate into a process they were never going to pass.

Fundamentals, and why clients test them

Clients often test computer-science fundamentals even when a candidate clearly knows the language. From outside it looks pedantic. It isn’t.

Knowing the name of a language does not show how someone reasons about scale, memory, failure and correctness. That reasoning is what matters when the dataset is a thousand times bigger, or the system is failing in production.

You do not need to teach any of this. You need to know why it is on the table. In a line each:

Data structures and algorithms: how work is organised, and how fast it can be done. Complexity: why something instant on a laptop can collapse at scale, because the cost grows with the input, and Big-O measures how fast. Memory: how it is allocated and kept safe, which affects speed and reliability. Concurrency: several things happening at once without corrupting the result. Networking, operating systems, databases and distributed systems: machines talking, sharing compute, storing data, and behaving like one service while parts fail. And testing and observability: how anyone knows the software works, and what happened when it didn’t.

Here is the useful bit. When a client says the last hire could write the language perfectly but couldn’t keep the system standing under load, you will hear a gap in fundamentals, not syntax, and know to ask what broke, why, and what they changed.

Evidence over keywords

A CV is a set of claims. Your job is to turn claims into evidence, and the difference is almost always the question you ask next.

Years, a recognisable employer, a long list of technologies. All signals, none proof. Every one can be true of someone who merely sat near the interesting work.

A few questions do most of the work. What did you personally own? At what scale? What made it hard? What changed because of you? How did you know it worked? What failed, and what did you learn?

Answer those about your own work and you are describing evidence. Answer only about the team, the company or the tech list and you are describing proximity. At Stanford Black, ownership, scale and outcome beat proximity. And finding out which you have in the first call saves everyone a wasted process.

Quality and fit are different judgements

A brilliant engineer can still be the wrong person for a role. Confusing quality with fit is one of the more expensive mistakes a new recruiter makes.

Fit is not one thing. Some engineers want to build from scratch; others enjoy improving something large and established. Some want broad ownership; others want to go very deep. Some want stability; others want reward tied hard to outcomes.

None is better than another. But a greenfield builder will be miserable maintaining a regulated legacy platform, however well they interview. Put the right person in the wrong environment and you still get the wrong hire. Matching the person to the place is most of the job.

Let’s be honest about what this job is not. It is not forwarding CVs, and it is not reading a job spec back to a candidate. Anyone can post a vacancy or search a network. If that were the whole job, no client would pay a fee for it.

What a specialist consultant sells is judgement. Knowing what a role really needs. Finding the evidence that a person can do it. Reaching people who aren’t looking. Working out whether the opportunity and the person genuinely fit. The database is the cheap part. Knowing what the entries in it mean is the part worth paying for.

Most of that rests on knowledge you can’t buy in an afternoon: which firms are hiring and why, which teams are quietly strong, who the good people are, and what would actually move them. Many of the best candidates aren’t applying to anything. Reaching them (with something relevant enough that they take the call) is a large part of the work.

The shape of the work

A good search is not magic. It is a series of fairly ordinary things done properly. And most failed searches can be traced back to one of them being skipped.

Understand the real problem behind the vacancy. Turn it into an honest brief, not a wish list. Research the market. Approach the right people.

Qualify their evidence, motivation and fit. Present them straight, strengths and concerns together. Manage the interviews, the feedback and the expectations on both sides. Surface risks before they become failed processes. And keep the relationship alive once the role is filled.

None of it is glamorous, and all of it is where the fee is earned. The same clients and candidates come back for years, so every honest, well-run search is quietly an investment in the next one. That is why we would rather run a search well than force the fastest possible close.

What good qualification looks like

Most searches start with too little to go on. A brief that’s really a wish list, or three lines and a job title. What you do next is almost the whole game. The difference between a consultant a client trusts and one they tolerate is qualification, on both sides of the search.

Weak qualification asks a candidate which technologies they’ve used. Strong qualification establishes what they personally built, and why it mattered.

Weak qualification repeats a candidate’s stated motivation back to them; strong qualification tests whether the move actually solves what they say they want. With a client, weak qualification takes a vague brief and starts searching. Strong qualification pins down the problem, the constraints, and what success looks like.

One habit protects you more than any script: never pretend to understand something you don’t. Ask the next intelligent question instead. Nobody expects a recruiter to be an engineer. But bluffing costs trust, and a good question builds it.

Motivation is its own discipline. What someone says they want (more money, a bigger title) is often shorthand for something they haven’t named: more ownership, less firefighting, a manager they respect, work that is visibly going somewhere. Get to the real reason and you can judge whether a role solves their problem or just changes its address. You can’t do that while you’re talking.

The same honesty runs into your advice. A consultant worth the fee tells a candidate when a move is wrong for them, and tells a client when a brief is unrealistic or a slow process is losing them the people they want. It feels like arguing against your own placement. It is the opposite: advice both sides can trust is the whole reason either one picks up the phone next time.

When it gets tempting to fudge it

Picture the offer stage. A relocation problem surfaces that should have come up weeks ago. The placement (your fee) is one silence away from closing. This is the moment the job is really testing you. Stay quiet and you might get the offer over the line; you will also have staked your name on a problem that doesn’t disappear. So you raise it, with both sides, and work it.

The same instinct holds everywhere it counts: don’t invent credibility you don’t have, don’t manufacture urgency, don’t bury a real concern to close a deal. It isn’t the soft part of the job. It’s the commercial part. This is a small market with a long memory. Clients and candidates remember whether you told them the truth, especially when it would have been easier not to. Forcing one deal at the cost of that is a bad trade, every time.

One last thing. And it’s the fun one. Everything so far has been recognition. This is an invitation to go and be curious about a real firm, on your own terms. No test, nothing to submit, nobody marking it.

Most of what a consultant does starts exactly here: a firm you don’t know well, a role to understand fast, and not much to go on. The work is to find out (from the firm’s own words first) what they really do, who for, and who they need. You did a gentler version in the classification exercises. This time you choose.

Below are twelve firms across the six kinds of place we recruit into. Two in each. Some names will be familiar. Others may not be. Pick whichever category you like, then go and research the one that gives you the most to discover. The point is the curiosity, not the marks.

And unfamiliar says nothing about size or importance. Several of the less obvious names here are large, formidable firms that simply don’t advertise to the public. Assuming unfamiliar means small is exactly the reflex worth breaking.