Risk analytics dev, hopefully !! another broken dream#Ashish

Update: many developers seem to suggest that any risk analytics experience would not help me move into “front office”, though I’m not so hung up about front office.

Many people also point out budget is typically lower in back office.

Hi Ashish,

Thanks for your input. I feel bad about repeated failed attempts to break into a few quantitative domains (listed below) so I need to consider some negative what-ifs. What if the risk system is similarly “underwhelming” like:

* volatility surface fitter in Barclays
* curve building and real time “ticking” risk sensitivity in Baml
* quant library integration at Macquarie

* equity and FX volatility product pricing in OCBC
* (I guess your Barclays mortgage system could be another quant domain?)

Armed with my formal education and analytical competence, I have tried valiantly to find a foothold in a quant dev domain. I was unable to dig in my heels.

I will not go into details on these “broken dreams”. Suffice to say that I had enough of these … that recently I decided to walk away from a higher-paying ($120/hr) contract because it looks like another system with some complicated financial math.

I don’t want to give up completely on my (large) investment in quant study. This is the source of one of the biggest pains in my career. As I said, I am also cautious about throwing good money after bad money…

Thanks for pointing out the “infrastructure” part — I can imagine that like your friends, most tech guys in risk systems are only responsible for the infrastructure. In some banks, there’s an army of developers supporting the risk systems, so the infrastructure is presumably quite complex and large scale. Presumably, if a developer can understand a sizable infrastructure or the complex “plumbing” in a risk system, he would be considered competent, valuable, and strong even though he doesn’t understand the math.

Across domains, math is not the only domain knowledge — I believe 1) system architecture and 2) jargon are important domain knowledge too, esp. in risk systems.

Among the millions of java/c++ developers in risk systems, I guess 2% to 10% need some quant knowledge? In such a case, the market depth would be rather poor, because risk quant developer roles would be few and far between, just like the pricing quant developer market.


Q: your #1 domain xp.. pricing^mktData@@

See also marketable_domain_xp spreadsheet… Don’t spend too much time on this question. I may say AA is my #1 domain, but I may still choose BB domain.

AutoTrading or E-trading is too vague as a domain. Means different things to different people.

In terms of absolute length, pricing would be my #1 domain

  1. Citi pre-trade bond pricing
  2. Barcap
  3. Stirt risk bucketing
  4. MSFM + self-study

In terms of depth, I’m very comfortable with the (limited) math therein, which is an entry barrier to many.

  • 😦 However, this domain has relatively few jobs and poor accumulation
  • 😦 Mostly in ibanks
  • 🙂 has contract roles
  • 🙂 salary premium? occasionally
  • 🙂 entry barrier? reasonable

specialty jobs outpay commodity financial IT jobs@@

In 2007 I worked on the most common type of financial IT job — 1) java servlet applications with 2) a big database and stored-procedures  3) small amount of client-side javascript (possibly with ajax). 4) In my case, there was also some scheduled batch job.
It was in Private-Wealth-Management but no financial domain knowledge required.
(I have since moved on to “fancier” systems, not only pricing or market data.) I started to think the most common dev job like the PWM job doesn’t pay as well, but what’s the reality that you see throughout your career?
Q: does the most common type of financial IT job pay lower because it only needs commodity skills?
[Mithun] Not always. It depends on how critical the demands are and how much $ impact it has.
Trading as such they have money to spend, sometimes demanding & definitely impacts $ 
there is a short-term trend —  depends on demand & supply. 
I have lately seen lot of money thrown at angular even thought it might not be challenging as concurrency, but then u need many angular developers for a few server side developers. But then this skill fast retires.
Perhaps it pays just as well, or 5% lower than the specialty dev jobs in trading systems?
Commodity java dev will get around 145k while concurrency guy will get 175k…. 
Things have changed in that “most common type of financial IT job”, which I can only define in vague terms.
* once there was lots of spring/hibernate usage
* once there were lots of xml-related server-side libraries
* I guess there are more RESTful interface?
* more javascript code
* fewer stored procedures
* more noSQL systems, less SQL
* I guess there’s now more Hadoop??
yes Hadoop , spark, but I see a lot of demand for python, and they are coming with rich libraries.

churn !! bad ] mktData #socket,FIX,.. unexpected!

I feel the technology churn is remarkably low.

New low-level latency techniques are coming up frequently, but these topics are actually “shallow” and low complexity to the app developer.

  • epoll replacing select()? yes churn, but much less tragic than the stories with swing, perl, structs
  • most of the interview topics are unchanging
  • concurrency? not always needed. If needed, then often fairly simple.

#1 server-side language@WallSt: evolution

Don’t spend too much time.. Based on my limited observations,

  • As of 2007, the top dog was java.
  • The dominance is even stronger in 2018.
  • Q: how about in 10 years?
  • A: I feel java will remain #1

Look at the innovation leaders — West coast. For their (web) server side, they seem to have shifted slightly towards python, javascript, RoR

Q: Why do I consider buy-side, sell-side and other financial tech shops as a whole and why don’t I include google finance?
A: … because there’s mobility between sub-domains within, and entry barrier from outside.

Buy-side tend to use more c++; Banks usually favor java; Exchanges tend to use … both c++ and java. The latency advantage of c++ isn’t that significant to a major exchange like Nsdq.


c++ salaries: high-end^regular

I spoke with 5 to 10 fellow c++ developers in financial domain across a few countries. All of them seem to suggest c++ skill has higher market value than any other language like java, c# or python. One common reason they all gave is the high frequency trading jobs. My own observations also show that most HFT tech jobs use c++ and very few jobs are java or c#.

However, how many of us can ever pass the HFT interviews?

I have tried a few high-frequency or medium-frequency algo-trading jobs using c++. I didn’t pass any. Among my friends, only one person passed. He passed more than one such interviews and he’s clearly very strong.

So I feel the reality is, most of us won’t be able to get those jobs, or keep the jobs.

Q: how many percent of the c++ jobs in finance are HFT ?

I would guess 5 to 15%. So the vast majority of c++ salaries are ordinary. I think many of us can get those jobs:)

What’s your opinion?

Wall St tech projects/timelines #XR

I have heard several people complaining about the unhealthy work culture in NY investment bank IT teams.

  • · Timeline is artificially tight.
  • · A typical senior manager is motivated by trophy systems to win him promotions + bonuses, rather than really useful systems making a real impact to business
  • · Lots of systems are developed but not used or used for superficial purposes only. (This is common in many systems. Only 1% of the features are actually put to productive use.)
  • · Low quality code; low quality output data; poor quality control
  • · Constant and wide-spread pressure to retire old systems and rewrite, when the old system is still usable and sometimes rather stable.
  • · Senseless requirements, questionable value, thrown-away systems

I heard that West coast shops, Chicago buy-side and other companies don’t have exactly the same problems. I feel my current company is also different from NY banks — Older technology; Slight higher quality standard; More stable codebase; Users are mostly external paying customers…

I guess the Wall St culture is “good” for some, while other developers hate it and exit. I’m planning to stick to finance but not banks.

financial IT profession: !! so bad #DannielYu

See also a profession u Enjoy with good {income+barrier}

(A letter I didn’t send out) Hi Daniel,

I think the programmer profession, and financial software dev in particular, is not that bad:

  • · Entry barrier — formidable, comparable to doctors or lawyers. See ##行行出状元,但有几个行业不容易出头
  • market depth — see salary probabilities(distro): mgr^NBA#market depth 
  • · Job security — actually reasonable, despite the threat of globalization and threat from younger guys. I think the high entry barrier in financial IT is to our advantage
    • o I was told some managers have job security concerns too
    • o I was told U.S. university professors also face elimination (淘汰).
  • · Work Stress — Significant variation across firms and across teams, but generally more stress than other professions.
  • · Workload — much higher than other professions. Programming is a knowledge-intensive job.
  • · Job market demand — very high for IT skills. Therefore people from other professions are drawn here.
    • o Market depth is excellent. You can find plenty of jobs from $50k (easy to cope) to $300k
  • · Age discrimination — Some professions (like research) are even better.
  • · Career Longevity — (I will delay or skip retirement) Reasonable in the U.S. Some professions (like doctors) are even better.
  • · Income — well above average among all professions. Just look at national statistics and world-wide statistics.
  • not a sunset industry, not under threat like music, movie, journalism.
  • knowledge intensive, challenging complexity

##resilient WS tech: FIX,sh-script…

Background: the constant need to economize on my learning hours. Have to attempt to pick the “survivors”.

  • FIX as a tech skill is an example of unexpected resilience. (However, this is in a specialized domain, so competition is arguably lower.) FIX isn’t dominant. Exchange native API is faster. Many HFT shops don’t use FIX, but still FIX has good ROI.
  • SQL is not longer dominant but still standard
  • Tibco isn’t dominant. Many teams use competing products. Still it’s resilient
  • XML, in the face of light-weight serialization protocols – json, protobuf
  • Bourne shell, in the face of python, perl…
  • STL, invented in the 80’s (??) with many limitations, challenged repeatedly
  • tibrv, challenged by 29west, solace,

I have a bias towards older technologies. They have stood the test of time.

tiny team of elite developers

Upshot — value-creation per head and salary level would rival the high-flying manager roles.

Imagine a highly successful trading shop. Even though the trading profit (tens of millions) is comparable to a bank trading desk with hundreds of IT head count, this trading shop’s core dev team *probably* have a few (up to a few dozen) core developers + some support teams [1] such as QA team, data team, operations team. In contrast, the big bank probably have hundreds of “core” developers.

[1] Sometimes the core teams decide to take on such “peripheral” tasks as market data processing/storage, back testing, network/server set-up if these are deemed central to their value-add.

In the extreme case, I guess a trading shop with tens of millions of profit can make do with a handful of developers. They want just a few top geeks. The resultant efficiency is staggering. I can only imagine what personal qualities they want:

* code reading — my weakness
* tools – https://bintanvictor.wordpress.com/2012/11/08/2-kinds-of-essential-developer-tools-on-wall-st-elsewhere/ * manuals — reading tons of tech info (official or community) very quickly, when a “new” system invariably behave strangely
* local system knowledge
* trouble-shooting — and systematic problem-solving. I feel this largely depends on system knowledge.
* design — it right, and able to adjust it as requirements change * architecture?
* tuning?
* algorithms?

(soft skills:)
* clearly communicate design trade-offs in a difficult discussion * drive to get things done under pressure without cutting corners * teamwork — teamwork to back down when needed to implement a team decision