After four years as a Quant in Goldman Sachs, I left earlier this year.
In that time, I worked on 3 different desks across Fixed Income & Equities and completed about 20 to 30 different projects.
Here are the 9 non-glamorous things you should know about working as a sell-side Quant.
Of course, this is based on my subjective judgement and experience.
Every bank/hedge fund/coffee shop is different and might not necessarily share the observations listed here.
Nonetheless, many items did resonate with other Quants that I met throughout my career.
Let’s start!
1. Primary responsibility of a quant/strat is to help traders calculate prices and risks of their books correctly.
Modelling or developing comes second.
If a trader thinks the PnL or risks are wrong, that becomes the primary focus for someone in the team.
If not resolved promptly, it becomes the focus for the entire team.
If still not resolved, it becomes the focus of the people who can really make you wish it was resolved sooner.
Excellent motivators.
They can really help you find that inner strength.
Even at 1 am.
2. Big part of the job is checking the numbers:
- Why is my dollar delta “a bit off”?
- Why am I not seeing the PnL on a new trade?
- The market hasn’t moved overnight, but now I get a different price for my perpetual Quanto Autocallable on a 1,000 stocks basket!
Sometimes it’s something simple.
But sometimes, it can easily take a few hours or days debugging a vast array of different inputs that feed into a single number.
The reasons can range from stale market data to someone in Tokyo making a code change and signing off for the day.
Of course, you also need to know what “a bit off” means and translate that into a specific, clear and measurable set of requirements.
Hence:
3. One of the key skills of a quant is the ability to clarify and get to the bottom of what is needed.
Going from an empty email with the subject line “my vega looks weird!” to a complete problem specification is a long way to go.
You can start by talking to the trader.
After a short clarification exchange, you find that “obviously” he meant delta, not vega.
And that the delta in question is within the XXX portfolio, inside the YYY book, on ZZZ trade. But not the one with the lookback feature. The other one.
You tell the trader that it’s a basket trade and none of the asset deltas are null or n/a
He kindly clarifies:
“ya of course it’s a multi-asset trade…looking at AAPL…
…delta is 53.4…should be higher…
…around 53.5…
…I mean, look at where the stock is trading!”
You can learn many things by watching trader’s Bloomberg screens while waiting on him to talk to you.
4. Interesting projects are hard to come by.
Many mathematical pricing models have already been built and just need a few quants to support them.
In order to do some model development, there needs to be a business justification for it.
Either a bank wants to trade a new product, or it wants to enable a new feature on an existing product.
It doesn’t happen often – over the last 20 years, sell-side banks managed to implement pricing models for the most obscene kind of payoffs.
The likelihood that something new comes up that wasn’t covered already isn’t very high.
And if it does, what are the chances that you or your team will get to work on it?
5. Mathematicians doing software development.
Focus has also long shifted from building sophisticated pricing models to building software and automating processes.
It’s not “who has the best model”’ anymore, but “who has the best systems” – i.e. who can get the price faster, process more deals, automate everything etc.
With increased competition and lower margins across many markets, the only way to stay profitable is to ramp up the volume.
More automation.
Less manual intervention.
More integration.
Less customization.
Many projects don’t really need quants to do them – a team of software devs with a detailed requirements document can be enough.
As a result:
6. I would argue that traders in exotic products are more quants than quants.
When a quant is doing “quant’s work”, they study a specific model and then implement it.
A quant will certainly know how the model works.
But a trader will have a feel for it.
Traders seem to spend more time thinking about how this or that model parameter impacts the price and risks.
Or how the model behaves in different market scenarios.
It is impossible to learn this from writing model tests.
7. Similar to FAANG companies, one is rewarded for rolling out new features rather than improving/supporting old ones.
No one is interested if your code runs better and is easy to debug and extend.
If it works and meets the “barely usable” criteria, then it’s good enough.
Ship it and send that congratulatory email to sales and trading.
There is significantly more emphasis on items that qualify as deliverables and can be shown to senior management.
Time spent fixing issues, improving your code or helping other teams doesn’t count as such.
8. If everything is urgent, nothing is urgent.
Every request is for a live $100mm trade, and we need the price yesterday.
Before you can clarify what’s the issue, Sales tell you the client traded away.
“Hi team, is anyone looking, please?”
Of course, we’re looking! After all, you didn’t include your two MDs in the CC for nothing, right?
The volatility of requests that get thrown at you during the day is pretty high.
Sometimes, it’s calm, and it’s just you and your code.
And sometimes, it’s like riding a bike:
9. Not everyone quits to join a hedge fund.
Some quants take the unconventional route and quit to start a YouTube channel.
This is what I did.
If you want to see how it goes, it would be great to have you on board!
You can expect educational and entertaining videos covering stocks, options and other topics within the incredible world of financial markets.
Follow me on Twitter to make sure you won’t miss the next video.
And subscribe directly to the channel: https://www.youtube.com/c/PerfilievFinancialTraining
