%% poor accu ] quantDev: Sg+U.S.

My past experiences are underwhelming. I thought that once I become experienced and proven in quant dev domain, things will be easier and I could move from one job to another. Wrong!

  • Barclays? helped me get into OC since OC interviewers are very interested in how things are done in Barclays. Didn’t really help me go anywhere else
  • Stirt? helped me a bit with Mac interview
  • MSFM? didn’t help me get anywhere

OC/Stirt/Mac gave me no insight no breakthrough in my understanding no thick->thin->thick

The number of quant dev positions is much fewer than in market data!



Update: I told bbg (Karin?) and Trex interviewers that domain isn’t a big concern to me. Even a back office IT role can turn out to be better.

  1. quantDev
  2. algoTrading
  3. bigData

… are the 3 big directions for trySomethingNew. I’m cautious about each.

quantDev — low demand; poor market depth; unable to find another job; See also %% poor accu ] quantDev

algoTrading — perhaps I should try java and medium frequency?

bigData — no consolidation; questionable accumulation and value-creation

quant developer requirement

Many quant developers (in our department) program in c# (for excel

plugin) or build infrastructure code modules around quant lib, but

they don't touch c++ quant business logic classes. C++ quant lib

(model) programming is reserved for the mathematicians, typically


Many of these non-C++ quant developers have good product knowledge and

can sometimes move into business side of trading.

I was told these quant developers don't need advanced math knowledge.

—-quant interviews

Mostly C++ questions. Most candidates are filtered out here.

2nd group – probability, (different from statistics)

Some finance intuitions (eg — each item in the BS formula)

Some brain teasers

— some typical C++ questions (everything can be found from the Scott

Meyers books)

exceptions during ctor/dtor

virtual ctor

Given a codebase, how do you detect memory leak

multiple inheritance (fairly common in practice)



[[heard on the street]] and [[A Practical Guide To Quantitative

Finance Interviews]]

Another book by Shreve.


chat with Yi Hai on quant finance education

i see more and more young people with this kinda degree getting good salaries (50% to 66% of our salaries within 3 years of graduation) as researchers or analysts. This skill has higher value than programming skill. More importantly, this skill suffers no “technology churn”.

My training so far is on derivative pricing (+ modeling) theories and portfolio theory. These are all classic topics with well-established theories. very academic, idealized theories, but surprisingly generations of students get trained on these and go into the field and make good money.

i have working knowledge in option pricing, bond math and a bit of personal experience as an equity investor. I find the theories too academic, too idealist, far removed from real trading. I feel like learning traditional Chinese landscape painting — seriously distorted and out of perspective.

These theories are actually the content of all the major quant finance programs. Therefore, many young quants every year are trained on these theories.

In fact, the professors can't teach anything but academic theories. These are what they are best at. Professors aren't traders or fund managers, so their strength is not in application of theories to practical challenges in order to achieve investment success.

The theories are impressive efforts to simplify the complicated realities in finance. (Best examples would be tail risk, volatility skew) But they are still rather imperfect. However, the trainees often went on to get good jobs and make good money.


junior quant – interview skills needed

* A lot of Jargon (need a bit of intuition)
** how each instrument is priced
** using what mkt data

* the math theory below the surface

* probability puzzles, math algorithms.

* c++, matlab


quant trend – more stats, less theory or complex model

I see increasing evidence (though anecdotal) that real world quant roles now require less math theory, and more programming.

A Barcap friend told me many (mostly buy-side) pricing systems basically take market quotes as the most reliable price, rather than computing a theoretical price from a complicated model. Why hire so many math wizards to build a model when the output is … questionable in the face of live price on the market? You can tune (based on market data!) your model to output a price, but I feel it has to be consistent with market prices. When they become inconsistent, either your model is imperfect or it has “discovered” a mispriced security or some rare trading opportunity like a stat arb. Well, I feel the chance of “discovery” is higher the simpler your model is. Further, how do you know this “opportunity” (if true) can’t be discovered by a simple analysis without a model? If you are after such opportunities, then the faster you process market data, the earlier you catch the opportunity. That means simpler math. Complicated model is harder to program right, i.e. more bugs.

A Danske quant shared how important programming is to a quant. Ultimately, the quants are hired to help traders make decisions. Every Trader loves usable soft market data they can play with. Whatever great idea you have, you’ve got to put it into a computer, otherwise no one will use it.

My young quant friends in Barcap and MS shared that in the first few years as a quant, programming is probably the most important skill.

For a buy-side quant (usually in eq and FX), stats know-how is probably more relevant than stoch or volatility. I think a high frequency shop won’t trade a lot of options, since liquidity is much lower. I guess many buy-sides do trade options, largely for hedging or to earn the premium.

On the other hand, there’s still a demand for the deep theoretical knowledge. I feel the math jargon is still an entry requirement for any quant role. Otherwise you don’t know what people are talking about. These jargon terms require a hell lot of background knowledge, probably taking a few years. Even the basic BS model can easily throw a curve ball. I bet you can’t catch unless you did a few months of “home work”.

Now a much bigger curve ball — Interest rate derivatives are the most math-intensive. (Danske is actually an IRD sell-side.) I was told credit derivatives add additional complexity, but I’d guess bulk of the math complexity is in the IR stoch vol. There are even more complicated products (MBS?) out there but the total profit in that market must be big enough to justify hiring quants. Structured derivatives market probably qualify as such a market.

Structured derivatives (aka exotics) are more math-intensive than vanilla derivatives. The vendor (sell-side) must price it carefully to protect himself. Overpriced, no client wants it and it’s a waste of vendor’s effort [1]. Under-priced, vendor himself is under-protected. Therefore pricing requires deep math — risk, modelling, embedded optionality, back testing… This is a prime example of high-touch (relationship-based) trading. Unfortunately, I feel technology (and other market factors) is driving the other direction — low touch (i.e. automated), high volume flow trading. Just one simple example — in recent years I see more FX option products offered electronically — A high touch product going low-touch?

[1] I was a client for some of these simple structured products. I found the price too high. I could see the vendor spent time selling it and finally withdrawing it. Such unattractive, hard-to-sell products in the structured product marketplace are common — lower revenue, higher cost, lower margin for the vendor, and lower salary.


seminar by the Danske quant

Some of the historic models




—- 2nd era





2nd Era triggered by …. IRS.


Bermuda options ….


—CVA calculation



__Tan Bin (+65)6530 1386 OC Centre #17__



most used c++ libraries in quant codebase

STL, Nag, Not boost, not ACE

Smart pointer is also needed.


quant fund preference: y Eq/FX imt FI/commodities %%take

I feel quant funds (including HFT funds)

* does a large number of small trades and
* relies on a large volume of market data for statistical research/analysis. Sample size must be statistically meaningful.
I guess most FI and commodity markets often don’t support these. Some popular FI/Comm instruments have rich data volume, but doesn’t support small in-and-out trades. In FI/Comm, you buy and hold, rather than quick in-and-out trades. But how about high-volume listed FI instruments (like ED futures?) I hope the bid/ask is small enough to support in-and-out.
How about listed options? I feel percentage spread (bid/ask spread divided by mid-quote) is usually too large, so quick in-and-out trades are not always possible?

small old-guard quant fund – some facts and figures

This is one of the earliest quant funds – stat arb sort of thing. “Definitely a quant fund, rather than a macro fund, but not high frequency.”

Quant group 12 guys. Write most of (what i call) the business modules. (In contrast, mkt data consumption and OMS – 2 infrastructure pillars — are owned by the System group — what i call the pure tech, math-free modules) These business modules generate orders, achieve certain target positions, manage risks… As [[blackbox]] pointed out, quant traders think in terms of entering/exiting positions.

System group – 2 system admins and 4 c++ developers. I guess one of them is a network guy.

Mostly equity cash, but also commodities and (eq?) options. Trading is fully automated, forecast-based.

One model may have a trading horizon of hours
One model may have a trading horizon of days
These 2 models may overlap if they cover the same name. There is a feature of the trading system to manage the overlap.

(No model with trading horizon of seconds – not really high frequency.)

GUI is x-win. Whole company is linux/solaris, without windows.

Sybase – used lightly, now phased out. Persistence is done without database, probably in flat files.

Primary app language is c++ — threading, IPC, TCP, multicast for mkt data feed handler. No RV.

Various scripts – often in perl.