sticky%% imprints/reputation - java ^ c++

I feel my c++ interviews aren't so successful (http://tigertanbin2.blogspot.com/2014/03/weakness-revealed-by-interviews-c.html), but many traditional efforts may generate diminishing returns. (eg: Home coding project can be very time-consuming). Instead, perhaps we should look for special "imprints" – knowledge pearls that help us impress and stand out during competitive interviews. In a way, we must beat the interviewer on some front since on many questions we would be beaten.

Venkat can often stand out within a short conversation, due to his imprints.

My java interview experience – I managed to impress interviewers and stood out although my coding/design may not stand out. Am I a stronger java guy than my friends? I guess only if you quiz me on those special topics
- lock free
- wait/notify intricacies
- condition variable as replacement of wait/notify
- custom thread pool
- volatile keyword intricacies
- skip list (sorted set)
- concurrent hash map
- special singletons

Targets (memory/threading helps efficiency) --
* subvert the virtual mechanism P928[[primer]]
* dtrace
* placement new - real use cases
* replacement of RTTI
* data alignment in market data wire format
* memory page locking
* alloca()
* custom new() and free list in [[eff c++]]
* lock free - real code not concept
* template partial specialization but I don't know the use cases?
* various custom-made smart pointers with special features -- [[safe c++]]
* memory leak detectors - home made (eff c++?)
* comma operator

sticky~why re-enter c++ if salary could be lower and jobs fewer@@

If you really write down your J4, and “discount” [1] each, you realize at some point the J4 becomes “inadequate”.
[1] find some reason to critically weaken

* Mtv: To broaden my base, I have invested in php, py, javascript, swing, FIX, tibco, Sybase... many of them got me jobs but none has the power (#1), complexity (#1), value-add, entry barrier as c++ has.
* Mtv: doldrums -- if u sit still for 12 months, then no growth in java skill, but another guy will pick up c++, Some will acquire zbs and a real competitiveeedge. b_u_t c# is more popular than c++.
* mtv: initial orgradient is fastest -- my java (not c#) growth has slowed down. My C++ is still at the fast-learning phase
* Mtv: get in the door -- I will soon become expert* mtv: SG -- Relative to US, SG java talent is even more of a commidity. c++ talent is more rare and more highly valued than in US, b_u_t the positions seem to be limited.
* Mtv: entry barrier -- c++ is higher than java? b_u_t some jobs require just basic C programming
* Mtv: commodity vs differentiation -- the java skill on wall street is a commodity. You are no different from the next java guy. (B_u_t most outsiders simply don't know how to come in.) What differentiations? c#, swing, threading...
* Mtv: xp wasted -- i have many years of professional experience in c/c++. Why not build it up to a critical mass and get a real edge?
* Mtv: cross-pollination -- threading, data structure (among other core topics) benefit from cross-pollination.

* mtv: deepens my mastery of java/c#, more than what I could without c++. Some high-end java interviews require/appreciate it.

* mtv: critical link -- between the lineage of java and c#. There's hidden insight in evolutionary history. Some interviewers drill into rationale and tradeoff, among other academic questions.
* Mtv: latency insight -- latency sensitive eq often benefit from memory knowledge of c++. If you work on such a java system, c++ insight is an advantage.
* Mtv: performance trend -- as more asset classes follow Eq, as competition heats up, low-latency will become more important. c++ is for "demanding" systems -- Scott Meyers. I would think the white-hot fields are still dominated by c++. b_u_t java is encroaching
* Mtv: lead -- need to extend the lead over non-trading developers.
* Mtv: A+B years -- many guys have A years java + B years c++ ? b_u_t they may not earn more.
* Mtv: strongest developers -- often know c++ in-depth. b_u_t look at Piroz, Yang, Avichal Gupta, Sundip Jangi...
* Mtv: older developers -- c++ is better for older guys? b_u_t many older guys are learning java, probably due to shrinking demand
* mtv: cost-amortization -- In terms of investment, i already invested so many years on threading, containers, regex, OO, design patterns... Learning c++ or c# lets me amortize this huge cost. In 1 year i can reach a 3-year proficiency level. About 20% of my core java insight can double as my c++ insight.
* Mtv: outside financial -- a lot of infrastructure and core components are in c/c++, where java isn't fast enough. Many of the most important software's are in c/c++. Consider google, facebook... http://www.lextrait.com/vincent/implementations.html
* Mtv: foundation expanded -- like DBA, c#... I prefer to expand my foundation not by learning spring, gemfire, ION … b_u_t these latter category perhaps enjoy more demand
* Mtv: low-level -- than java/c#. Look at the standard books. Low-level is my comfort zone.
* Mtv: churn and volatile -- less rapid than java and c#. Best books were 90’s. b_u_t that's a sign of investment by major vendors.
* Mtv: crowded -- java is crowded talent pool? b_u_t there are also more jobs

sticky~how many years C experience...unimportant!

It's possible to code C for years without using pointers except string functions.

It's possible to code C++ for years without using virtual, new/delete, template, operator overloading or even class.

It's possible to code python for years without creating classes.

It's possible to code java/c# for years without any threading (beyond locking), or reflection

It's possible to code perl for years without using hash or regex.

It's possible to code SQL for years without writing outer joins. I guess I wrote lots of mysql queries without any join.

## which skill/field CAN be self-taught

Domain knowledge is easier to "fake" than c#/c++. It's hard to fake the mileage...

Q: which fields can be truly self-taught to in-depth? For example, mobile apps, desktop apps.

Goal #1: pass job interviews
Goal #2: reach the professional level of Theoretical expertise
Goal #3: reach the professional level of Practical expertise

* Quant? too dry. Too many doubts to be clarified only by professor. However the basic math part is standard and well-defined. Goal 3 is invalid.
* high-frequency, algo? Many books but none on real tricks. Compare swing books! Very few jobs.
* network/linux optimization? need machine to try. Extreme optimization techniques are top secrets.
* FIX? Many practical issues hard to imagine. No focus.

---
* swing, wpf? -- tricks can be self-taught through experiment. Practical books are available. But practical problems are unknown.
* c# and core libraries? Real obstacle is the IDE. Practical books abound.
risk-mgmt? impossible to experiment.
coherence? too many subtopics. no focus. Hard to experiment.
tibco? no book at all. Hard to experiment
threading? Can hit Goal 2, not 3

10 low-level tech skills - Aug 2012

For once, let's assume we are no architect, but a hands-on developer. Some tech skills are long-living, heavily quizzed at
interviews, entry-barriers --

threading, data structures, iterators
java/c++ syntax rooted in OO fundamental
C++ big3, exceptions, RAII, vptr
C++ smart pointers
SQL query
?Query plan
GC internals
design patterns

moving a bit up the pyramid in a trading desk

In each trading desk, there are very few decision-making roles and a large number of supporting roles, including IT[1]. Pyramid -- The closer to the top, the more valuable you become. For an IT guy, the route to those valuable roles is sometimes non-obvious. For this discussion, i will assume you don't want to become trader. If you also don't want to become an IT manager, then consider a quant role.

There are several factors ...

The field must have sufficient profit to fund large "valuation" systems (VaR, quote pricing, marking...). If it's a small desk, then system is less likely to be complex.

In terms of inherent complexity, option > IRS > futures and cash; FI > others.

Risk is more quantitative than pre-trade pricing. Risk includes marking and real-time risk, but the most complex is simulation-based VaR. Business allocate enough time and resources to prepare an elaborate risk risk analysis.

When you first enter a field that's 60% (on an arbitrary scale) quantitative compared to an earlier 40%, you may not notice you are slowly shifting up on the pyramid. But when you develop your quantitative track record over the years you might move further away from IT and closer to business i.e. profit center. Your value-add may increases slowly or signficantly. When you are still very much in IT, you may still feel you are a replaceable supporting staff but someday, without warning, you become part of the "inner circle".

[1] Decision-making roles including market-risk. If desk head has enough confidence in the market-risk analysis, then risk managers can significantly affect (intervene/curtail/rein-in) trader actions. In some buy-side/sell-side trading desks, the chief does pretty much nothing except watching risk numbers.

## lasting achievements as a techie?

Backdrop: Technological innovation is fast (less so in commercial banking, i was told) so "lasting" means ... maybe 5 to 10 years (rarely longer)?? Few achievements meet this criteria.

See also http://bigblog.tanbin.com/2010/09/accu-and-longevity-compare-with-civil.html, http://bigblog.tanbin.com/2011/02/classical-engineering-field.html

- open source -- software have real lasting values. I guess you can learn to Read their source code -- usually in C.
- [L] contributions to foundation modules such as VM/CLR, compilers, threading library, GC, STL -- real lasting values

What skills contribute to lasting value-add to an organization?

- tuning - DB -- needed in many big and small systems
- tuning - low latency systems -- more rare
- [L] instrumentation i.e. refactor/design a given (complex) system to make it easy to trace and follow
- [L] ? introspection - tend to be rather powerful in many new languages
- ? interpreting bytecode; decompilers
- ? system security; white hat hacker

[L = I feel most of these skills are low-level]

In theory almost everything can be learned by a young guy in a few years provided they get full (rare!) access to all source code and manage to make sense of it all. However, look at how many bright young people become kernel developers even though so much open source operations systems exist.

stay hands-on in financial IT

Better stay hands-on in financial IT, whether you come back to US or stay in S'pore long term. In Singapore, most hands-on developer jobs are less ideal (for older guys) than management jobs. Majority (above 70%) of my Singapore peers of my age group try to build a career path away from hands-on. Among the other 30%, some try to stay as hands-on architects or hands-on tech leads. If we were to stay in S'pore, such roles are ok till age 45. In the US, that age limit seems to be 55. Big question is whether you could become and survive as a hands-off manager. I think Yang tried but he still relies heavily on his tech skill. My competitive strengths (if any) in management roles are

* attention to detail
* reasonably good domain knowledge
* good rapport with some developers
* experience working overseas -- many finance projects are global in nature

am fast as Wall St developer

* I grew fast enough for GS. Compared to other banks, GS has 50% of the headcount for any given workload.
* I was fast enough for the Lab project lead. Their standard is even higher than GS. The Lab project lead didn't complain about my delivery speed though he pointed out Piroz was more experienced and faster.
* Citi senior mgr didn't complain about my delivery speed at all. Not even once. I was working at a comfortable pace.
* I worked alongside Lab49 consultants who are battle tested fast-coders over many years.
* in every job i managed to steal time for self-study - swing, python, secDB, rv, options, c++, non-blocking I/O, c++ debugger, bond math...
* many trading desk dev teams are elite teams with tiny headcounts. I survived some.
* I generally pay more attention to details than other developers. I could, if I want, switch off this attention.

I guess there are super-developers who are really faster in some specific contexts, but overall it's hard to be a fair judge considering quality, prod support capability, error checking, knowledge-transfer, automated-testing, help to other team members, client-orientation, maintenance cost, system flexibility, readability, architecture soundness...

front office developers for fx options trading desk

Question: Guess how many developers are needed in the fx option trading desk at one of world's biggest investment banks? Note this desk handles all fx option trading for the entire bank.
Answer: about 20 world wide including consultants.

The other trading desk in the FX space is the FX cash desk. Not sure how many developers.

If there are 20 similar trading desks in the bank, then total number of _desk_specific_ developer head count is going to be around 500, at most 1000. I think this is a very small percentage (5%?) of total IT head count.

In 2007 GS had about 6000 IT headcount. This bank is probably double. I'd say at least 10,000 IT head count. I would estimate less than 5% of them are directly funded by trading desks.

Now I know why front office trading is a rare opportunity.

Risk developers are classified into 2 types
- some are dedicated to a desk
- some are firm-wide

Asia strengthening, US waning?

For a job seeker, the real effect is in currency. Don’t be fooled by the mass media --

Growth? Asia is probably faster, but revenue and profit volume still is a fraction of the US.

In term of brank, Wall Street is still considered a market more mature more developed, and a (imperfect) role model.

Most trading systems are designed in US or Europe.

Profit margin per deal is higher in Asia (Indonesia...) than developed, efficient US/Europe market. A "deal" can be an issue, a block trade or a sale of a trading model.

A model is an intellectual property developed by a sell-side, useful to the sell-side and also the buy-side