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.

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/

 

c#/c++/quant – accumulated focus

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
https://1330152open.wordpress.com/2015/08/22/stickyspare-time-allocation-history/ — spare time allocation
https://1330152open.wordpress.com/2016/04/15/set-measurable-target-with-definite-time-frame-or-waste-your-spare-time/
https://1330152open.wordpress.com/2016/04/26/spare-time-usage-luke-su-open/

## 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.

zbs+nlg insight accumu due to X years@a job: !by default

Many interviewers assume the length of using something on a full time job indicates accumulation… Other interviewers test the depth of your insight.
You know you have insight, mileage, accumulation if/when ..
  • ..when  you know most of the important and relevant [1] terms in the lingo. Interviewers often go deeper about a new “construct”[2], and question its motivation/history and limitations.
    • ….if you know the __connections__ between the concepts. Without a mental map, there would be way too many unconnected lingo terms leading to info overload
    • ….if you know what new developments are only marginally important to your field, so you can focus on the really important
  •   ..if you can /separate the wheat from the chaff/滥竽充数/. I think often the real veterans would exchange a secret handshake and acknowledge each other very quickly. Eg: Dad (Tan Jiajian) knows his peers in the domain.
    • …. If you can’t quickly separate the wheat from the chaff, then probably you aren’t experienced enough.
  • ..when  you know you have grown much stronger than a junior person new to the field. How soon this happens is poorly correlated to # years
  • ..when your mental “book” has grown thin -> thick -> thin. Eg: math..
  • ..when you know you can master a “local” system quickly, thanks to the accumulation /under your belt/. Eg: Avichal Gupta…
As you can see, many of the indications/evidence of insight are related to evaluative discussions (including interviews). I’m not being narrow-minded and focus exclusively on job interviews. No. In any team,  very quickly person A would size up person B (and vice versa), and often have a rough number in his head about “how much B knows our shared domain”.
[1] it’s subjective but I feel 90% of what consider irrelevant is clearly irrelevant.
[2] this includes new choice, technique, best practice
German said one needs to be in a project for 6Y, but I disagree. I feel a wide range of non-trivial challenges is more important, and I feel we are unlikely to get that by staying in one project.
eg Perl — I used Perl for 3 to 5 years..
eg SQL — I used SQL for many years before GS, but my accumulation was solely in GS!
eg Threading — not much used. Mostly accumulation by reading…
eg option math –
eg C++ — see post on c++IV: knowledge more important than coding experience

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.