##xp@career diversification #instead of stack-up/deepen

  • biz wing — in addition to my tech wing. I learned a bit but not enough. Not strategic
  • quant? The on-the-job learning was effective and helped me with subsequent interviews, but further push (UChicago) are not bearing fruits
  • data science?
  • —-diversify within the tech space, where I have proven strengths
  • swing? positive experience
  • unix -> web dev -> java? extremely successful
  • c++? slowly turning positive
  • dotnet? reasonable
Advertisements

mkt data tech skills: !portable !shared

Raw mkt data tech skill is better than soft mkt data even though it’s further away from “the money”:

  • standard — Exchange mkt data format won’t change a lot. Feels like an industry standard
  • the future — most OTC products are moving to electronic trading and will have market data to process
  • more necessary than many modules in a trading system. However ….. I guess only a few systems need to deal with raw market data. Most down stream systems only deal with the soft market data.

Q1: If you compare 5 typical market data gateway dev [1] jobs, can you identify a few key tech skills shared by at least half the jobs, but not a widely used “generic” skill like math, hash table, polymorphism etc?

Q2: if there is at least one, how important is it to a given job? One of the important required skills, or a make-or-break survival skill?

My view — I feel there is not a shared core skill set. I venture to say there’s not a single answer to Q1.

In contrast, look at quant developers. They all need skills in c++/excel, BlackScholes, bond math, swaps, …

In contrast, also look at dedicated database developers. They all need non-trivial SQL, schema design. Many need stored procs. Tuning is needed if large tables

Now look at market data gateway for OPRA. Two firms’ job requirements will share some common tech skills like throughput (TPS) optimization, fast storage.

If latency and TPS requirements aren’t stringent, then I feel the portable skill set is an empty set.

[1] There are also many positions whose primary duty is market data but not raw market data, not large volume, not latency sensitive. The skill set is even more different. Some don’t need development skill on market data — they only configure some components.

effi^instrumentation ] new project

I always prioritize instrumentation over effi/productivity/GTD.

A peer could be faster than me in the beginning but if she lacks instrumentation skill with the local code base there will be more and more tasks that she can’t solve without luck.

In reality, many tasks can be done with superficial “insight”, without instrumentation, with old-timer’s help, or with lucky search in the log.

What if developer had not added that logging? You are dependent on that developer.

I could be slow in the beginning, but once I build up (over x months) a real instrumentation insight I will be more powerful than my peers including some older timers. I think the Stirt-tech London team guru (John) was such a guy.

In reality, even though I prioritize instrumentation it’s rare to make visible progress building instrumentation insight.

in hind sight: Quartz ^ java job

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.

stress@jobHunt^GTD

Both mental stress and physical stress. Let’s take a step back and compare the stress intensity during job hunt vs GTD stress on the job.

Many people say it’s too stressful and tiring to keep interviewing compared to a long-term job in a big company. Well, I blogged many times that I need to keep interviewing…. The stress is so far manageable.

On a regular job, the GTD stress levels range from 5 to 7 on a scale of 10 (Donald Trump on women;). Often rise to 8.

Became 9 or 10 whenever (as FTE) boss gave a negative feedback. I know from several past experiences. In contrast, contract projects felt much better.

(To be fair, I did improve after the negative feedback.)

During my job hunt including the challenging Singapore lap, my stress level felt like 4 to 7, but often positive stress, perhaps due to positive progress and positive energy.

Conclusion — I always felt more confident on the open market than recovering from setback on a job.

## array+other topics]algo quiz

–coding IV topics ranked

  1. #1 array, string, list, queue
  2. qsort + other sort
  3. generate permutations etc (probability + very little discrete math)
  4. binary trees

— beyond top 5, within top 10

  1. hashmap? if we exclude QnA questions, then this topic is not in top 5
  2. primitive types
  3. non-tree graph traversal
  4. combining multiple data structures? needed for bigger problems
  5. 2D image

–beyond top 10

  1. DP
  2. concurrency

##a few projects technically too challeng` 4me

See also https://bintanvictor.wordpress.com/2017/05/29/transparentsemi-transparentopaque-languages/

I was technically very, very confident in my 20’s to early 30’s until I was 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, invincible but then a tough project was given to them that they struggled to get done. Later someone else got it done without much effort. (For a public domain example, look at the kernel project in GNU.)

It can be harmful to dive so deep into past personal limitations 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.

Eg: GS rule-engine re-architecture in 2007 — too early
eg: see the opacity issues in https://bintanvictor.wordpress.com/2017/06/12/xp-3typestech-zbs-challenges/
eg: the mysterious “tp” in the g++ command line when I run “make debug”

## X years C++experience without using virtual !

  • It’s possible to code C for years without using pointers (except string functions), or malloc
  • It’s possible to code C++ for years without using virtual, new/delete, STL, or even class.
  • It’s possible to code java/c# for years without any threading, or reflection
  • It’s possible to code perl for years without using interesting regex or hard/soft references.
  • It’s possible to code SQL for years without writing outer joins. I guess I wrote lots of mysql queries without any join.
  • It’s possible to code python for years without creating python classes.
  • eg quartz — the python experience didn’t make a strong python developer. The other tech knowledge gained has even lower market value.

WallSt survival KPI:how fast U figure things out, relative2coworkers

As stated in other posts, it’s all about local system knowledge + tools

Survival (and bonus, stress..) is always linked to benchmark against team peers, not external teams like another department, not the manager himself. If entire team is low-calibre, then it’s a problem for the manager, but rarely your own problem. (It might threaten your team’s survival…)

LG2: system performance. Most guys in the team probably aren’t so good at this kinda thing, unless the  team has a specific mandate to monitor and fix performance.
LG2: test coverage. May affect your reputation, but once I figure things out I can often relax and test
LG2: code smell. May affect your reputation but is clearly a LGlp compared to getting things to work.
LG2: code quality
LG2: readability by the team lead. OK team lead may complain, but if it works then it’s relatively easy to improve it.
LG2: extensibility. Yang is big on this. Many books are big on this, but it’s an art not a science. Many team members probably aren’t good at it.
LG2:  system stability such as occasional hangs. Often a non-show-stopper.
** eg: my VS2015 build tends to hang and I had to research on how to fix it — show-stopper.

All of the above are secondary to … “figuring things out” i.e. how to get something to work, at a minimum usability.

Design? See also posts on arch_job. Can be a real problem, because if your design gets shot down, you waste time on rework.

 

 

IV^GTD – grow as techie@WS

I want to grow stronger/broader/versatile as a survivor, not necessarily grow my value-add. Actually I don’t have to grow.
— IV skills – Compared to GTD skills, these skills give me more confidence, more protection, more stress-relief. It works in big job markets like Wall St.

Lots of theory, which is my sweet spot.
Selective on what IV topics to learn!
coding IV + algo — favored by SiV
— (portable) GTD skills
Lots of tools….
Selective on what GTD topics to learn!

Needed for a lead developer, but such a role is stressful. I guess some good lead developers are also good at IV, but I’m not sure and I assume I’ll not be good at both.

Warning – a lot of projects don’t provide real GTD enrichment. Eg: Quartz, tibrv wrappers, Gemfire wrappers, FIX wrappers
——-
Macquarie environment lets me learn lots of GTD skills.
OC gave me IV (c#) and GTD enrichment.
Stirt – none!

A java environment would give me some additional GTD enrichment but less IV enrichment

In SG, I continued my previous strategy, learning IV skills + GTD skills. Not effective so far. I feel my c# IV skills improved a lot but still not there. C++ IV skills didn’t improve much partly due to distractions.