CFM quant devops job in hind sight

  • #1 wanted: c++ tooling — including MSVS, which was one of my key weaknesses
    • ROI? more than I could without this job but not a lot
  • #2 wanted: quant dev
    • ROI? zero
  • wanted: python extension dev
    • ROI? zero
  • wanted: excel add-in dev
    • ROI? zero
  • wanted: cloud experience including EC2 and S3
    • ROI? low
  • unexpected gain: devops experience, but market value is low
  • unexpected gain: python GTD esp. importation feature
  • unexpected gain: c++11 and tool-chain and features
  • unexpected gain: git GTD.  Never asked in IV though

Overall, I stayed too long. 6M might be enough. In the skill list above,

  • quant and cloud are high-value targets (but zero realized gain)
  • most of the items have low value in my upcoming interviews.
  • as to GTD, c++ tooling, python, git have values

Q: would a java job give more ROI?
A: I don’t think so.

resilient tech skills: 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.)

Other examples:

  • SQL, in the face of noSQL challengers.
  • XML, in the face of light-weight serialization protocols – json, protobuf
  • Bourne shell, in the face of python, perl…
  • php, mysql, in the face of newer challengers
  • STL, invented in the 80’s (??) with many limitations, challenged repeatedly
  • tibrv, challenged by 29west, solace,
  • excel

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

QQ^ZZ mutual exclusion: c++/java..

Background — The QQ/ZZ framework was first introduced in this post on c++ learning topics

Focus on tough not ordinary topics in c++ or java.

QQ: By and large, tough topics in job interviews are never needed in projects.
ZZ: By and large, tough topics in work projects (zbs) are never tested in job interviews.

Mutually exclusive =>

  • effort (laser energy) I spent on textbook knowledge during job hunt basically hurts my work,
  • effort I spent on tough zbs topics for a project very seldom help with job interviews.

Therefore, some optimizing candidate would make the minimum effort to get by on projects, and channel the energy to QQ knowledge or algo challenges.

##3projects technically too challenging4me

I was technically very, very confident in my 20’s to early 30’s until I get bogged down in some tough projects.

I think many successful and competent techies experience the same at least once in their career. They though they were powerful but then a tough project was given to them and they struggled to get it done. Later someone else got it done. For a public domain example, look at the kernel project in GNU.

Eg: GS rule-engine re-architecture in 2007
Eg: Quartz dag layers
Eg: Quartz cancelled trade

It can be harmful to dive so deep into past personal difficulties but then a hard, honest review could be life-enhancing. I see myself as a tough grown-up guy so I can take the pain.

West Coast^Wall St techies #per HenryWu

Henry Wu felt

* west coast techies have clearly higher calibre.

* Wall St is more busy. I guess he means higher workload, faster pace, more quick-n-dirty and lower quality.

* Very few older guys on the west coast. There’s probably implicit age discrimination that’s hard to prove.

* Perm roles pay higher on the West coast. However, his sample may be different from David Leak’s

Quartz ^ java job in hindsight

See also https://bintanvictor.wordpress.com/2017/04/11/quant-devops-job-in-hind-sight/
When taking up Quartz, I decided to avoid the diminishing return of java.

I  believed (and still believe) the initial learning in any technology is fastest. But was the enrichment worthwhile? Now I think yes and no.

– yes more java probably wouldn’t have improved my technical capabilities.
– no I didn’t become a “grown-up” python veteran or deepen my domain knowledge in curve fitting, real time risk, risk attribution, risk bucketting..

(Below is Adapted from a letter  to Hu)

Most of my developer friends (mostly senior developers) in Goldman and Baml shun the in-house frameworks (SecDB or Quartz). Key reason cited is skill mobility and market value. There are other reasons unmentioned. Indeed, we have to spend many late hours learning the idiosyncrasies of the framework, but that value…

(Quartz position is predominantly programming) Someone said if you stay outside mainstream programming technology like java/c#/c++ for a few years (like 3Y)  then you will forget most of the details and have a hard time on the job market — 1) getting shortlisted or 2) passing the tech screening.
I thought I could learn some serious python programming but left disappointed. I didn’t use a lot of python constructs, python hacks, python best practices, python modules (there were so many). I don’t have a good explanation — I feel most of the technical issues we faced were Quartz-specific issues like DAG, Sandra …. For an analogy, I can give you a 3Y job to develop c++ instrument drivers but restrict  you to my framework “CVI” so you are shielded from basic pointers, smart pointers, STL, threading, virtual functions, Boost, the big 3 (copy ctor, assignment operator, dtor) or any of the c++11 features. Over 3 years you would learn close to nothing about c++, though you would learn a great deal about CVI (C for Virtual Instrumentation, used in my early jobs.) So over 9 months I didn’t go up a rewarding learning curve in Python and emerge a “grown-up” developer in python.
Besides, I hoped to learn some financial analytics, pricing, risk, stress test, back test, linear algebra, matrix operation, curve fitting, etc. Not much. Would a longer stay help? Maybe, but I doubt it.
It’s true that many Quartz projects give you more direct exposure to “domain knowledge”, since most of the low-level nuts and bolts are taken care of by the Quartz framework. In my projects we worked directly with trades, live rates, accounts, PnL, PV, risk sensitivity numbers, curves, risk buckets, carry costs, and (a large variety of) real securities,  …
However, there was no chance to work on the quant library as those modules belong to other teams in a well-organized dev organization like Quartz.
Resolving technical problems is always frustrating (until you have 3 years experience in Quartz) because the knowledge is kept in people’s heads, so you can’t google it. The documentation appears extensive, but actually very very limited compared to the technical resources on Python or any popular language.
Quartz has good dev practices like automated build/release, test coverage, code reviews, so you might benefit by learning these best practices.
Database technology is an essential skill. If you like object-oriented DB, then Quartz gives you the exposure, though the valuable skill of developing an OODB is reserved by the early pioneers of Quartz. In my opinion, relation db RDBMS) is more widely used then OODB, so it’s more valuable to learn how to write complex SQL queries and tune them.
Quartz offers elaborate event subscription, so changes (on market prices or positions or user input or configuration) propagate throughout the OODB fabric in real time. I think this is one of the sexy (and powerful, valuable, enabling) features so I was excited initially. But it’s too complex too big. I used this feature extensively but didn’t learn enough to benefit. Analogy — you can learn many Korean words but still not enough to converse, let alone using it effectively to communicate.