ruthless march@technology

There’s a concept of “best practices across industry”, as I experienced in Macq. Using new technology, things can be done faster, at a large scale, and more automated, even though I may feel it doesn’t make such a difference.

CTO’s don’t want to be seen as laggards. Same motivation at MS-Iceman, Quoine …

  • PWM-billing, PWM-comm. I remember Mark wanted “strategic improvement” not incremental improvement. He needs it for his promotion 政绩
  • RTS infrastructure was considered (by Jack He and outsiders) outdated and lagging behind competitors

You can call it “ruthless march of technology” — a ruthless progress. At a fundamental level, this “progress” can wipe out the promised benefit of “slow-changing, stable domain knowledge”

  1. quant skillset
  2. SQL skillset — affected by noSQL
  3. c++ skillset — perhaps affected by c++0x
  4. FIX skillset — perhaps affected by faster proprietary exchange APIs?
  5. … However, the skills above are still relatively robust. Other skillsets (they are not today’s focus) have proved arguably more robust against this march — sockets, pthread, STL, coreJava, bond math,.. I listed them in my spreadsheet pastTechBet.xlsx.

##[19]low-churn,easy domains4career{50

I am always looking for low-churn, accumulating skillset that I can rely on after age 50, without strenuous effort. Such effort is possibly harmful for the brain.

My chosen domains are not white hot domains attracting the young bright kids. I always hope to pick up these skills and try to build them into my “portfolio” of skill assets. If 3 out of 5 decline, I still have the other assets to provide meaningful employment till 70. I have more listed in my spreadsheets “techBets” + “marketableDomains”

  • 😦 #1 example Quant dev — turns out to be too competitive. Low churn but I need strenuous effort even now.. see quant≠sure good for aging dev (also ruthless march@technology)
  • 🙂 mkt data — feels better
  • 🙂 bond math — feels even better
  • VaR math?
  • FIX?
  • algo trading — I didn’t choose it because too competitive
  • — technical skills
  • 🙂 python — worked out well
  • 😦 c# — abandoned
  • 😦 swing — abandoned
  • 😦 MOM — fell out of fashion


cod`drill^quant self-study

quant knowledge used to be a halo, now replaced by coding IV skills like

  • classic generators
  • DP, recursion
  • clever data structures
  • clever graph algos
  • speed coding

In 2012 When I was studying quant in my spare time, I was on a powerful ascent. In the subsequent years, I gradually lost steam. The quant sector was shrinking and market depth was disappointing.

Since 2018, my coding drill feels very relevant, even though the gap behind the strong players continues to be a pain and a de-motivation. When I stop comparing myself with the stronger players, I would feel my improvement in a highly valuable skill

unnoticed gain{SG3jobs: 看破quantDev

All three jobs were java-lite , with some quantDev exposure. Through these jobs, I gained the crucial clarity about the bleak reality of the quantDev career direction. The clarity enabled me to take the bold decision to stop the brave but costly TSN attempts to secure a foothold. Foothold is simply too tough and futile.

Traditional QuantDev in derivative pricing is a shrinking job pool. Poor portability of skills without any standard set of interview topics.

at same pay, now I would prefer eq than drv pricing domain, due to mkt depth and job pool.

QuantDev offers no contract roles !

Instead, I successfully established some c#/py/c++ trec. The c++ accu, though incomplete, was especially difficult and precious.

Without these progresses, I would be lacking the confidence in py/c#/c++ professional dev that enabled me to work towards and achieve multiple job offers. I would still be stuck in the quantDev direction.

decline@quant-dev domain: low value-add

Q: why drv pricing quant jobs used to be more abundant and pay a premium even though the economic value-add of the quant skill has always been questionable?
%%A: because the traders made money for a few years and subsequently received a big budget. Now budget is lower.

Same can happen to quant funds in NY, Chicago, HK…

Some UChicago lecturer once commented that everyone should get some quant training .. (almost as every high school student does math). But I think it is not necessary….

I am more theoretical and was naturally attracted to this domain but the value-add reality soon prevailed in my case.

Tech shops love algo challenges and speed-coding which have dubious value-add similar to the quant skills. However, the hot money in tech sector is bigger and last longer.

y I said you looked too dissatisfied #XR

聊天每 10次 觉得你有5 次(太多 🙂 流露对自己的处境严重不满。这方面我们俩类似, 所以我也有同感。正因如此, 我觉得你没必要这么不满意, 更不必苦闷。

从没听你提到你父亲。我父亲这方面给我宝贵的指点. 更重要是, 反复指点 — 我的思维习惯好难改变, 我一直有独立思考的性格和信心, 真固执 , 甚至顽固不化。我感激他不厌其烦指出我的愚人自扰.

光感激没啥用. 更重要的是 我被他的智慧和耐心逐渐地感化, 认识到自己并非顽固不化。

你我对很多问题的看法差异都与我父亲相关。比如学区;比如名校招生偏向弱族;比如各国教育系统哪个更成功; 比如对孩子评估过早…

还是说个人事业吧. 我深感自己 IQ/EQ 有限, 实在没必要和高薪的技术人员比.(更不要去比管理型人才). 所以我说目前处境不错, 偷笑还来不及.

刷题并不一定要有经济效益 — 比如拿个硅谷 或是高频 顶级公司聘约. 我比较重视能力提高,技能积累. 几年候 就算积累效果不佳, 我也希望能做到心安理得.

我的 UChicago 硕士读下来这个状况, 心安理得 着实不容易 . 我的总结 — 金融数学职位太少而且要求比我能力高, 薪水不一定比程序员高多少, 也没有 Contract 可言. 没法发挥我 (和 CSDoctor) coding 方面的特长和经验. 所以说 2013 年选择这个硕士课程, 实情了解得不够. 上了船才知道。

这次惨痛的经历决定了我对各种新技术新领域的谨慎, 徘徊, 举足不前.

既然我不看好这些领域的”钱”途, 我也没你那么不满现状. 话说回来,

* i’m good at scripting/SQL/data-processing compared to other developers I know;
* I like analyzing complex data, with attention to details;
* I have formal math training including statistics

So IF there’s some high-paying domain for me, I am open to it. That’s a big IF. The way I see it, most of those data analyst jobs are not paying well. If it pays well, it would be too hard to get in.

overvalued analytics applications #CSDoctor

Is GPS navigator necessary? Are side signal lights necessary? Some things are more necessary than others.

Trading system, risk systems, market data systems are mainstream. In contrast, I have found out that pricing analytics system is not really mainstream. Many buy-side and most smaller sell-side firms don’t use any pricing analytics beyond rudimentary derivations from raw market data.

There are also a number of sophisticated derivative and fixed-income analytics vendors including Bloomberg, Murex, Numerix.. These vendors focus on analytics so their customers don’t need deep expertise. OCBC’s quant team’s main job was validating the analytics offered by Murex.

Pricing analytics tools are “advisory” and not mandatory. The creators of those tools (like CSDoctor) tend to over-value their creations as if they are going to make the traders faster, safer, more profitable. In reality, traders can always choose not to use them.

As a contrast, take market data as example – 80% of trading shops need to build or buy market data systems as they can’t operate without it.

Math+intelligence ] trading ≠> high value-add

  • — Examples of math applied outside traditional proven quant domains like VaR
  • Trade analytics, execution analytics systems — analyzing past executions, and uses statistic tools to derive some empirical or parametric distribution.
  • Sell-side pre-trade analytics to evaluate a proposed trade….
  • Real-time risk analytics

Q: How much math in these systems? Not that much.

  • Fundamentally, trading domain is math-lite…
  • Risk management is slightly more mathematical due to large data set, relaxed latency requirement, many scenarios
  • The fancier and more advanced math, the more dubious

Q: Value-add? Questionable. That’s one reason why most financial institutions don’t spend billions building such systems. They do spend billions on traditional automation systems.

Q: Who would want to pay to use these systems? Rather Few.

Q: Python? Possibly.

case study: CSDoctor’s — value-add@analytics #CSDoctor

quant≠sure good for aging dev

I now feel the quant domain knowledge doesn’t change so fast, but ..

1) Quant domain is an elitist, exclusive sector with low market depth (highly specialized).

I think many intelligent/powerful developers can succeed as a quant dev, even without formal quant training, if motivated or interested enough. Abilities + effort (due to keen interest) is all I needed when I succeeded at Barcap

Not a semi-retirement domain. When you lose the mental power (Re A.Brooks) you better get out from this hot domain.

2) The high salary + analytical complexity + limelight attracts bright young people. Bright young people tend to be innovative, even when there’s no such necessity

3) see my blogpost ruthless march of technology

how is mkt data used ] buy-side FI analytics@@

This is a BIG bond asset manager… They use 2-factor HJM model, among others.

They use EOD market data for risk measure + risk sensitivity calculations. No real time.

Models were written by 40+ quants untrained in c++. The 16-strong IT team integrates the models

I asked “Do you use liquid fixed income market data mostly to calibrate models and use the model to price illiquid instruments?”

A: both

  • To calibrate model — every day, as explained in [[complete guide]] P436
  • To derive valuation directly on existing positions if the instruments are comparable (between ref data instrument and position instrment)

python usage in FI quant lib #Pimco

In one of world’s biggest fixed income buy-side firms’ quant library, the codebase is 3/4 c++ and ¼ python including pandas, numpy, machine learning, grid computing modules. I think this is similar to Macquarie FICC quant lib.

C++ is much faster, but data structures are very limited including STL containers.

I think the funds hold mostly bonds and mortgages. How about futures, IRS? Perhaps for hedging?

##[18]orgro lens:which past accu proved long-term # !!quant

(There’s a recoll on this accumulation lens concept…. )

This post is Not focused on IV or GTD. More like zbs.

Holy grail is orgro, thin->thick->thin…, but most of my endeavors fell short. I have no choice but keep shifting focus. A focus on apache+mysql+php+javascript would have left me with rather few options.

  • —-hall of famers
  • 1) [T] data structure theory + implementation in java, STL, c# for IV — unneeded in projects
  • 2) [CRT] core java knowledge including java OO has seen rather low churn,
    • comparable to c++
    • much better than j2EE and c#
  • 3) [T] threading? Yes insight and essential techniques. Only for interviews. C# is adding to the churn.
  • 4) [j] java/c++/c# instrumentation using various tools. Essential for real projects and indirectly helps interviews
  • [C] core C++ knowledge
  • [C] GTD knowledge in perl/python/sh scripting
  • [j] google-style algo quiz — Only for high-end tech interviews. Unneeded in any project
  • [R] SQL? yes but not a tier one skill like c++ or c#
  • coding IV — improved a lot at RTS
  • ————————also-ran :
  • devops
  • [C] personal productivity scripts
  • [T] probability IV
  • [C] regex – needed for many coding interviews and real projects
  • [C] low level C skills@RTS {static; array; cStr; reinterpret_cast;  enum; typedef; namespace; memcpy}
  • [!T] bond math? Not really my chosen direction, so no serious investment
  • [!T] option math?
  • SQL tuning? not much demand in the trading interviews, but better in other interviews
  • [R] Unix — power-user GTD skills.. instrumentation, automation? frequently used but only occasionally quizzed
  • [R] Excel + VBA? Not my chosen direction
  • [jR !D] JGC +jvm tuning

C= churn rate is comfortable
D = has depth, can accumulate
R= robust demand
T= thin->thick->thin achieved
j|J = relevant|important to job hunting

22surprises{U.S.reentry #traction#stigma

There are many valuable observations below, but let’s not spend too much time polishing…

  1. self-esteem regained — in tech IV/GTD, after 5Y bleeding self-confidence #stigma
  2. coding tests — continues to spread. I improved progressively, gained traction — I even find it enjoyable.
    • dnlg — all 3 domain knowledge categories are losing weight in interviews. Note half my recent interviews are outside ibanks.
  3. my c++ competence (esp.sockets) finally gained traction, thanks to the interviews.
  4. rise of west coast salary level. U.S. tech job market didn’t lose steam. U.S. geek economy continues to grow
  5. Tristate housing — school-district housing is more expensive than I thought, but Edison/Bayonne can be quite affordable
  6. ! java remains robust and dominant in ibanks. c++ is robust too. There are still many c++ roles in U.S.
  7. [c] concentration window — proved to be extremely important to my learning, career planning and reflections. Parenting and household chores are real drags.
  8. [c] my peers didn’t “leave me in the slow track”. Most of them are still regular developers. I guess they can’t move up unless they were already in a lead role by age 35
  9. “strategic technology bet” — is thoroughly discredited, through repeated introspection

–Next 20

  1. [c] ibanks interviews — (including coding IV) continue to play to my advantage, after 5 years
  2. [c] Java QQ continues to feel natural to me… I didn’t lose most of my java QQ strength…
  3. [c] aging developers — I see good examples in Shubin, Paul, Shanyou, Alan, Daniel, Kam, Pinsky, John etc
  4. U.S. high-end contract rate — has grown from $90 to $110
  5. start-ups — There are many interesting start-ups both in U.S. and Singapore, able to pay.
  6. retire — I have decided to retire in Singapore not U.S. I see my Singapore citizenship as a huge strategic advantage over my Chinese/Indian peers.
  7. [c] wife was competent at her job and continues to keep the kids in the current condition without deterioration
  8. [c] kids — my daughter didn’t become alienated; my son didn’t get out of control.
  9. [c] I continue to take unpaid leaves to learn from interviews
  10. mkt data — enjoys growing demand and I gained traction more than I gained a new defensible territory.
  11. quant career and math aptitude — broken dream. Disillusioned. deep pain
  12. U.S. investment yield is typically 6%, higher than what I observe in Singapore.
  13. [c] ibanks didn’t reduce IT budget or go offshore as some predicted
  14. [c] HFT — is robust
  15. c++ demographics — mostly older
  16. apps and coding jobs … (in the global economy) are becoming more important, more wide-spread than I anticipated.
  17. [c = continuation, but unexpected]

j4 stick2c++: Score big{losing@quant/c#

See also vindicative specializations , what if I transition to desk quant role but don’t rise up@@ and j4 c#: hind sight

I already give up several “investments”. If I take a java job, I would again forgo so many years of investment in c++. Now after I got more c++ offers, I feel /triumphant/vindicative/.

swing py c# quant 2010~13 quant af 2013 c/c++  (Zoom out …)
 $0 $0  $0 S$70k $ invested
 $0 $0 S$5k/Y  $0 $1k/Y cf
nonQuant job
up to USD20k/Y pretax opportunity cost
6M 2Y since barc 2Y  1Y 3Y 6Y since 1998 nominal effort
3M 4M 1Y  6M 2.5Y 4Y serious effort incl. STS
3M 2M 1M  2M 2Y 2Y spare time sacrificed(STS)
-2 -3 -6  -5 #more than py -15 -16 points invested
Barx passed some IVs OC, Bbg, Reuters 95G/OC Stirt/Mac/CVA ~18 offers job “offers”
Trex,bbg.. DRW; Nomura; Mako; Trex; Pimco analytics too many help interviews
helps my WPF xx value@algo IV deepens java nlg brain teasers; math cfd; contrarian insight into bigData/quantTrading; see y re-enter c++ other ROTI
2 more than
3 #built real
professional xp
more than invested 9 #50%+ more than invested points SCORED
 no loss? no loss -3 no loss -7 no loss net points lost

[11]quant library in java/c# !! catching on


You once told me java can emulate the same quant lib functionality of C/C++. I asked quants in GS, MS, ML, Barcap and a few other banks. I don’t remember anyone saying their quant lib is in java. I now feel there’s no industry momentum behind such a migration. Further, I feel there’s no justification either. I’d go out on a limb and say there’s justification for sticking to C++.

A java implementation is less accessible from dotnet, python, and other scripting languages that could be making (slow) inroads into trading floors.  In contrast, all major languages support an decent interface to integrate with a C library. C is the common denominator.

More importantly, the sponsors of the quant lib are business users (not only traders) and they
know none of the languages but they know MSExcel. I’d say Excel integration is a must for every quant lib, otherwise traders may refuse to use it. C implementations easily integrate with MSExcel, via the
Microsoft COM interface and other interfaces. C# also integrates well with Excel.

Some quant libs are used in visualization and GUI. Dotnet and WPF are a market leader in GUI.

I also feel C implementation tends to be faster, at least no slower, than java quant lib. In pre-trade real time apps, a quant lib needs to be fast. A Barcap veteran told me the most important justification for C++ in quant lib is speed/performance.

In 2018 I asked an Executive Director in MS CVA team why java is not used. He said performance is the main reason.

%%churn OK, accu bad] 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 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, partly because I didn’t try.

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!

## threading: a better specialization than algo,quant…

  • In summary — appears daunting and opaque but actually simple in practice
  • theoretical — like [[dougLea]].. my strength. Few coding tests and usually easy for me
  • fairly low-level — my strength. Not as low level as debugger, or template hacks …
  • GTD — no GTD challenges, since most projects use only simple threading designs. The code tracing, trouble-shooting expectation on me is relatively low.
  • opaque — for my peers. Even the basic condVar…
  • churn — low churn at the low level, but high churn at high level
  • ever-green — favorite topic of interviewers, esp. java
  • thin->thick->thin — I have achieved this for a long time.

Many of my halos are in this domain — ##halo across domains #specific=better

c#/c++/quant – accumulated focus

Update — such a discussion is a bit academic. I don’t always have a choice to focus on one area. I can’t afford to focus too much. Many domains are very niche and there are very few jobs.

If you choose the specialist route instead of the manager route, then you may find many of the successful role models need focus and accumulation. An individual’s laser energy is a scare resource. Most people can’t focus on multiple things, but look at Hu Kun!

eg: I think many but not all the traders I know focus for a few years on an asset class to develop insight, knowledge, … Some do switch to other asset classes though.
eg: I feel Sun L got to focus on trading strategies….
eg: my dad

All the examples I can think of fall into a few professions – medical, scientific, research, academic, quant, trading, risk management, technology.

By contrast, in the “non-specialist” domains focus and accumulation may not be important. Many role models in the non-specialist domains do not need focus. Because focus+accumulation requires discipline, most people would not accumulate. “Rolling stone gathers no moss” is not a problem in the non-specialist domains.

I have chosen the specialist route, but it takes discipline, energy, foresight … to achieve the focus. I’m not a natural. That’s why I chose to take on full time “engagements” in c#, c++ and UChicago program. Without these, I would probably self-teach these same subjects on the side line while holding a full time java job, and juggling the balls of parenting, exercise, family outings, property investment, retirement planning, home maintenance….[1] It would be tough to sustain the focus. I would end up with some half-baked understanding. I might lose it due to lack of use.

In my later career, I might choose a research/teaching domain. I think I’m reasonably good at accumulation.

–See also
[1]  home maintenance will take up a lot more time in the US context. See Also — spare time allocation


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 (not pure quant) — low demand; poor market depth; unable to find another job; least jobs and only in banks. CVA is not really quant dev, based on what I gathered. See also %% poor accu ] quantDev

algoTrading — perhaps I should try java and medium frequency?

bigData — no consolidation; questionable accumulation and value-creation

quant^HFT^WestCoast, again

After I felt fairly established on Wall St (around 2011), I looked for greener pastures:

  1. quant dev
  2. HFT
  3. high-end positions in the west coast. Not sure what positions exactly — mobile? machine learning? cloud?
  4. regular Wall St c++  job

In fact my java jobs on Wall St is not that inferior, and has the advantage of reachability. In contrast, those greener pastures still look rather distant. They look closer when I’m in a positive mood. But let’s put on the black hat and be critical and skeptical:

Quant dev is low-churn but demand is kinda shrinking.

HFT is rather niche skillset, possibly less relevant to west coast than java and regular c++.

1) 2) 3) are mostly FTE, not contracts. Regular c++ is contract-friendly and more reachable.

I used to feel the quant domain is hardest. Now I feel it’s shrinking. Now I feel I’m in much better shape. I made the decision to focus on quant early, assuming I could self-study and break into HFT later.

Data science? Math is much easier than quant finance, and I have some training in it.

C++? I now have more hands-on experience

quant developer requirements

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.

math tools used in option pricing vs risk mgmt – my take

In general, I feel statistics, as applied math, is a more widely used branch of math than probability. Both are used in finance. I feel their usage is different in the field of option pricing vs risk mgmt. Both efforts attempt to estimate the future movements of underlier prices. Both rely on complicated probability and statistics theories. Both try to estimate the “histogram” of a portfolio’s market value on a future date.

In option pricing, the future movement of the Underlyer is precisely modeled as a GBM (geometric Brownian motion). IMHO Stochastic is probability, not stats, and is used in option math. When I google “stochastic”, “volatility” always shows up. “Rocket science” in finance is usually about implied volatility — more probability less statistics.

In VaR, future is extrapolation from history. Risk manager doesn’t trust theoretical calculations but relies more [1] on historical data. “Statistical risk management” clearly shows the use of statistics in risk management.

In contrast, historical data is used much less in option pricing. Calibration uses current day’s market data.

[1] the “distribution” of past daily returns is used as a distribution of plant growth rate. There’s no reason to believe plant will grow any faster/slower in the future.

See other posts on probability vs stats. Risk management uses more stats than Option pricing.

Incidentally, If a portfolio include options,  then VaR would need both theoretical probability and statistics.

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.

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.

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?

STL/boost in quant lib

To a quant developer, I feel STL containers are more useful than STL algorithms. However, if you use STL containers, then some STL algorithms will be handy.

1-D and 2-D arrays are the bread-and-butter of quant lib. STL vector and vector-of-vector are good enough.

Sets and maps are widely used too in a few banks.

Daniel Duffy said STL isn’t enough for quant, but according to 2 friends (GS and an FX house) STL is the most important library for quant codebase; boost is clearly the 2nd (for quant library).
* The most important boost component is smart pointers.
* boost serialization

basic skills of a quant developer

trec – VBA, excel
trec – c++Excel integration using COM
trec – MSVC, “required” for COM (excel) integration
trec – visual studio — probably the #1 IDE on windows
trec – c++ debugger
trec – implemented pricing algos
trec – programmed matrix and vector
trec – back testing 
jargon – can describe popular pricing algo and related jargons
jargon – property sets

what can an ibank SELL besides financial products

As an investment bank, Clients most buy/sell financial instruments with us, but there are many value-add “services” we can sell to clients. Some of these services are packaged into a “value meal”.

– research information — selling “information”
* recommendations
– soft market data
– historical data
– indicative/evaluation prices for illiquid instruments
– quant lib? I doubt ibanks sell these, but it's possible in theory.

– trading strategy, algorithms
– trading signals

– low latency “connectivity” to trading venues
– smart order router

– security lending
– custody services
– book keeping service?
– settlement and clearing services

quants still maintaining the C++ quant libraries

According to a Morgan Stanley strategist, they use C++ plus some scripting languages. No java. The C++ quant lib consists of mostly C functions.

For some instruments, there's no formula based pricer. I was told most tailor-made structured equity derivative instruments are that way. Simulation path based pricer is the only choice. How to achieve real time pre-trade pricing? Run fewer (thousands of) paths, in parallel. How few in practice? Thousands.

Q: for a task assignment on quant code change, what's the choice between IT coder (including a quant developer) vs a quant coder?
A: IT is professional developer. More robust. Quant guy is faster time to market.

I guess the IT guy doesn't have the domain knowledge or the financial math training to fully understand the change. Real understanding is key to fast and safe change.

mkt-data is primarily collected for … quants in research dept

(background — there are many paper designs to process market data. The chosen designs on wall street reflect the intended use of this data.)

I won’t say “by traders” since it’s too much data for human consumption. It must be digested. Filtering is one of many (primitive) form of digestion.

I won’t say “by trading systems” as that’s vague. Which part of the trading system?

I won’t say “by algo trading engines”. What’s the algo? The abstract algo (before the implementation) is designed by quants based on models, not designed by IT. Traders may design too.

Q:Who has the knowledge to interpret/analyze such flood of market data?
A: not IT. We don’t have the product knowledge
A: not traders. In its raw form such market data is probably unusable.
A: quantitative researchers by definition are responsible for analyzing quantitative data.
A: data scientist also need to understand the domain and can use the data to extract insight.

portions@secDB – created by quants, for quants@@

I feel Quants and others around them don’t always point out the real difference between Traders, Coders and Quants aka strategists. In this context we have to.

Once secDB core is built, SecDB is “programmed” in each desk by regular software developers, not  secDB core team. Business end-users are risk managers and traders, majority of whom are probably not trained for or fascinated by Slang or python.

In terms of formal training, regular software developers are trained in engineering; quants in math; traders in investment. (Think of prop trading, to keep things simple.)

However, some quants qualify as software developers. (Actually, most c++ analytic libraries are owned by these part-time developers:-). Some sharp minds in the camp eventually realize 1) the inherent dependency graph in this world, and then rediscover 2) OODB. Put the customized quantitative dependency-graph-aware objects into an OODB and SecDB is born. Grossly oversimplified, but at this juncture we have to swallow that in order to wrap our mind around a monstrous concept, step back and see the big picture. (signal/noise ratio and focus badly needed.)

Another article said secDB “allows Goldman’s sales force and traders to model, value and book a transaction”, confirming that model and valuation are among the first goals of secDB.

Quants create this platform for themselves (ie for quantitative research, back testing, model tuning…), and then persuade developers to adopt. In such a world, quants are the law-makers. Power shifts from traders and IT to quants. In the traditional world, IT resembles the powerful equipment manufacturers of the dotcom era.

Now I feel the creators of SecDB may not be the typical desk quant, risk quant or strategist. He or she might be a quant developer

I guess Quants’ job is to analyze 1) financial instruments and 2) markets, and try to uncover the quantitative “invisible hands”. (In, I question the value of this endeavor.) They _numerically_ analyze real time market data, positions, recent market data (all fast changing), historical data, product data…. Too much data to be digestible by business, so they condense them into mathematical “models” that attempt to explain how these numbers change in relation to each other. Classic example is the term structure and the BS diffusion model. A proven model acquires a life of its own —

– become part of a trading strategy
– sell-side often offer these models as value-added services to hedge funds. I guess they can send trading signals or digested, derived data to hedge funds.
– risk mgr are often the #1 user of these models. Risk mgr and quants validate models by back testing.

high frequency ^ quant developer

I feel these are the 2 most advanced developer roles.

Low-latency (high frequency) doesn’t always pay higher than average. Not sure about quant dev.

Quant dev involves more math and more domain knowledge than other Wall St IT jobs, but I feel no CFA needed. However, I feel low latency offers very low exposure to domain knowledge.

Low latency is technically tougher than quant by a wide margin. Quant uses limited threading or efficient data structures.

What a trader/quant likes in a developer

clear, quick communications. software Developers tend to be less sociable.

Most developers don't sit side by side with traders, and aren't trained to present a problem or structure an answer.

More than taking a requirement and implementing it. Recognize the intent, propose better solutions, in terms of speed, scalability, and the most “logical construct” …

Quants – responsible for princing — where there's more math
developers – implementation

models: Optional or as Indispensible as trade capture@@

(A blog post. No need to reply)
Trade booking is the most essential component of any trading system. If a small trader has no computer system, he would make do with a poor man’s trade booking tool like Excel or physical paper to record the trades he did and the positions he holds.

Now compare quant models. I feel models are optional. It depends on the asset class spectrum. On one extreme end are listed equity options. The other extreme might be vanilla government bonds.

Vanilla Government bonds (not futures/options) involve no option-pricing, and are risk-free (notwithstanding the recent Greek/Irish defaults). I would assume there’s no need for quantitative model in pricing/risk systems.

Treasury futures is a different story. There are models to predict price distribution of underlying asset. Since the price is in the future, there are probabilities to work out — a branch of statistical mathematics.

Muni cash bonds need some model? not much. There’s perhaps some credit risk mathematics. The models generate a bid/offer price pair for each bond (based on the position held by the trader), but a trader offering the same bond can choose to use that price (plus a spread) or ignore it. It’s optional to a lot of muni traders.

On the extreme end of the spectrum, listed equity options are priced and quoted on exchanges using widely agreed models (lognormal stuff). Are models necessary to a trader in this market? Can an investor simply follow her instinct to decide for herself a bid/offer price?

what trading systems use quantitative pricing

In option, pricing system is one of the most important components of a trading system. A tiny advantage in your bid/offer price will beat the market.  I guess GS has higher trading volume than other firms because they trade at more competitive prices. Pricing and risk are the 2 sides of the same coin. GS has secDB and stronger risk system and better hedging so they can trade aggressively.

Pricing is less quantitative in illiquid markets such as Muni. Not many banks offer standardized interchangeable products.

Pricing is more quantitative in prop trading i.e. trading using bank’s own money.

Pricing is more quantitative in algo trading.

Pricing is less important in broker systems i.e. agency trading. Profit is the commission and the spread on the prices clients specify.

Prime brokerage is similarly reliant on valuation system, margin calculation determines how much money to lend out. The more the house lends, the more fee it can collect, but this must be calculated against the risk exposure.