Contract: unattractive to young developers

GregR convinced me that most of the young developers aren’t interested in Wall St contract jobs. I can’t remember the reasons but something like

In my experience the contractors I see are mostly above 40 or at least 35+. The younger guys (Nikhil..) tend to be part of a contract agency like Infosys.

The upshot — I have fewer strong competition. Most of the older guys are not so competitive in either IV or GTD on the job. In particular, their figure-things-out speed is slower.

GS-sg core IV with rare feedback

A Tech win by my own assessment.

–rare email feedback, with highlighting by me. It is clear o me the Hongkong OMS interviewer gave the most direct (negative) feedback. I feel grateful for that.

I feel this was a technical win. I think only the Hongkong OMS interviewer found some weakness in me.

I feel perm role selection/screening was more stringent than contractors because of leadership, communication, personality match, ownership… The new permanent hire is often seen as a potential manager to join the “race”.

In contrast, contractors are mostly assessed for technical + basic communication/attitude.

In SG, more than half the time I was assessed as a dev lead (or architect) but I don’t want to. U.S. contract market is better.

As he interviewed till the end, I’d like to share a bit of feedback.

The interviewers believed he had good industry experience (low latency, low-level coding, memory usage, CPU usage, MSA) and can implement/maintain systems, and appreciated his honesty e.g. not hiding the fact that he didn’t perform performance testing.

However, the interviewers wished to see more leadership and communication skills cognizant of 15+ years experience, and to conduct his own tests rather than easily take others’ assumptions at face value.

— Tokyo interviewer
Given a BST, how to do you insert, look-up by key?

Lastly, how do you remove an arbitrary branch node? Need a deterministic algorithm to reshuffle affected subtree and keep the BST property. Considering the python coding rounds, this is about the hardest pure-algo question throughout the interview process.

  • This level of difficulty is very different from tech shops
  • This level of difficulty is much lower than the coreJava QQ questions

— QQ interviewer Ming

Q: suppose you find your prod log file suddenly stops growing, what do you do?
%%A: check disk space; check DB query hung due to a pending transaction; check socket data input/output blocking
%%A: take thread dump, which is a nice JVM feature not available in c++ or other applications

Q: how did you tune your jvm?

Q2: how did you size the heap enough to ensure no jGC for entire day?
%%A: We estimated the high watermark (like 2GB) and configure my jvm with a heap bigger than that.

This technique is simple and crude but it usually works. I think interviewer may not be impressed but I was confident because … it works!

Q2b: but will that prevent GC? Do you know every GC must stop all application thread first?
%%A: at least the app thread can run after the snapshot, during the actual collection, right? I assume the snapshot is quick.

Q: in java, even without any protection, reading a 32-bit int will give you either the before-value or the after-value, right?
%%A: Not in c++. See c++11 atomic{int}^AtomicInteger.java #Bool can be half-written

Q: beside speed, what are other benefits/advantages of lock-free compared to lock-based designs?
%%A: the unsuccessful thread can do something else before retrying, rather than block indefinitely
%%A: a blocked thread (due to lock contention) is likely context-switched off the CPU. All the CPU data caches would soon be flushed.

Q: single-producer, single-consumer … can you design an efficient data structure to share data between them
Now I think we only have one shared mutable variable — the producer’s moving pointer. Interviewer hinted that all we need is for the producer to notify consumer where the new position of the moving pointer, in the data structure. Perhaps we don’t need lockfree. Volatile is probably sufficient.  Alternatively, mutex+condVar is a proven solution.

Aha — If the consumer thread needs to wait (not busy-wait), then notification is the key, so condVar is more suitable than lockfree.

I tend to think of that moving pointer as an integer.

I asked interviewer: are these concurrency knowledge and skills needed in your projects?
Interviewer: “Your CV mentioned these skills“. I believe interviewer implicitly answered NO. Standard practice of verifying/scrutinizing claims on CV !

–This OMS interviewer was trying to break the candidate…

Q: describe CAS. I recalled the details in https://bintanvictor.wordpress.com/2018/04/05/cas-cpu-instruction-takes-3-inputs/..
Q: how many clock cycles for a CAS instruction?

See further details in toy^surgeon

Q: what’s your actual CAS usage in your project, not a textbook use case?
%%A: At citi-muni, I had two threads putting quotes on a lockfree queue or stack. Queue is natural. In hindsight, the stack can be useful — when readers want to process the latest quote first, LIFO.

Q: how would you design an order book, if you ignore your current system?
Q: why did you say array-based is faster than AVL?
%%A: most likely cache efficiency

Q: what’s the performance level of your order book? “I (the interviewer) would use array-based order book .. can easily achieve 1M msg/sec”
Q: what’s the disadvantage of an order book based on AVL tree?

— coding^QQ^non-tech questions

I think I did well on non-tech (A-) and coding (A), OK on QQ (B). With the non-technical, again, I feel interviewers can’t reach conclusions.

I believe the tough questions listed above are classic QQ i.e. theoretical knowledge not needed in real projects. Interviewers may consider it zbs but I would call it QQ.

Consistency and stability in high-end coreJava QQ topics — No real change since 2007

Do I look like Deepak? I think with algos I seldom feel fake and broken. As to the QQ topics if I am armed with a tidbit of c++ low-level knowledge then I can often defend myself, because on those questions, c++ is invariably more low-level than java. There are still some “weakness topics” where I may come across as … superficial+academic, like Deepak.

I generally concede to the interviewer, but not today during the “CAS justification” discussion.

##[19]y WallSt_contract=my best Arena #Grandpa

Competition arenas … we all choose the arena to compete in. It’s a choice, either implicit choice or explicit choice. I would say better to conscious about this choice.

Not much new content in this blogpost. I feel very convinced to stick with WallSt contract market. Here is a ranking of the reasons why I consider it a rational decision, though our decisions are shaped by our deeply personal experiences and inherently irrational.

Beware of attachment !

  1. low stress, low expectation — my #1 reason as of 2019
  2. low-caliber competitors, mostly due to the “offputting
  3. age friendly
  4. I get to practice interviews and keep a precious burning-pleasure for a month each year on average.
    1. In contrast, If I were an ibank VP I would have multiple obstacles on that front.
  5. — other reasons to prefer Wall St contract
  6. higher probability of greenfield projects
  7. leverage on domain knowledge
  8. I can easily explain my job hopping profile
  9. a number of firms to hop around

Now the downside, off-putting factors. Many bright or young competitors are put off, reducing the competition

  • salary can drop; furlough
  • frequent job change required — often forced to change job.
  • no job security — Employers tend to cut contractors first.
  • no compensation package
  • no growth, no bonus
  • no chance to move off hands-on dev and become prj mgr etc
  • no medical benefits
  • restricted to mostly ibanks — many young bright people are interested in buy-side or non-finance.

old-timer paid below grads; unable2quit #Davis

My friend Davis revealed to me that many non-VPs earn below the $115k salary offered to a fresh Master’s grad.

  • Davis said employer won’t give you more than 3% annual increment, so quite often it can’t reach $115k.
  • Anthony also said the big hike happens only when you change job [1].
  • Jack Zhang said over 10 years the total increment could add up to below 20k.

Q3: what’s the market rate for your skill as an old timer?
A: probably higher than the grads.

Q3b: so why the old-timers don’t get a better job elsewhere?
A: they don’t feel they can.
A (Davis): these old timers have value-add only because of their localSys knowledge. In a sense, some new-age employers have a prejudice against people of loyalty. They probably associate Loyalty with stagnation and obsoleteness.

Therefore, one-long-job resume can be bad when you change career. I always felt my job-hopper resume is a liability, but some west coast shops don’t care.

I feel these old-timers are afraid of failure [1] at the new job, perhaps after a long, stressful adjustment. I think people do notice that adjustment to a new environment can be very tough and often unsuccessful.

Contractors keep adjusting.. stronger, more adaptable, more confident than those loyal old-timers.

Q6: why is employer willing to pay grads so much more?
A: Employers don’t want to but that’s the market rate set by supply-demand. Ibanks want to bring in fresh talents and must pay the market rate.

[1] A.Gambino discussion .

longer u stay,more localSys nlg⇒safer@@ #5%GS

As I said in this blog, FTE-dev is often worse off than contractors.

I think if you stay for many years without moving up while some of your colleagues move up, you may or may not get a stigma.  Some of the newer members may become your manager:) But this is not the main focus here.

The longer you stay, the more knowledgeable about local system. Hopefully more relaxed and less stress? Partly true but very dangerous slippery slope. You hope that you can make do with 80% of the earlier /intensity/, but I think it won’t happen in most ibanks [1].

In my observation, most VP-level old timers operate under /unrelenting/ pressure (“threat”) to maintain high productivity. They are expected to be more proficient and more productive than earlier, not allowed to slow down and take it easy … No retirement home here.

Otherwise, they would fail the peer benchmark

Another Part of the threat comes from hungrier, younger colleagues able to reach (then surpass) half your speed within a year or two, driven by /formidable/ brain-power (energy, intelligence, ..)

[1] There are exceptions but I only know a few so I don’t want to spend too much analyzing. Exception — if you were the original architect and you keep an eye on the evolution of your brainchild, and remain knowledgeable about it, but this scenario requires some brain-power.

That’s the harsh competitive reality even if you don’t seek increasing responsibilities. A small percentage of the people are ambitious ladder climbers. (Am clearly not, because at my current level I already feel the heavy workload.)

Many people I talk to want an “easy life”, not increasing responsibilities. However, If you don’t take up increasing responsibilities, you may become too expensive. You may get a token bonus. I think you may even get a humiliating bonus.

Overall, in “peacetime” long service without moving up can feel embarrassing and uncomfortable at times, for some individuals. (It’s more noticeable if most of the peers at your level are much younger, as in Macq and OC.) Some corporate cultures may tolerate but stigmatize that

Employer claim they prefer employees staying longer rather than shorter. That’s blatant marketing. In reality, some employers wish some old timers to leave on their own, to make way for younger, cheaper fresh blood. GS annual 5% cull in peacetime is widely-reported in WSJ, Independent... A few common motivations:

  1. Old timers are sometimes perceived as obstacles to change, to be removed.
  2. some employers believe younger, newer workers are cheaper and more motivated on average
  3. Whenever a new manager comes in he would bring in his old friends, otherwise he is weak.

Down turn? All hell breaks loose. Rather than protecting you, your long service track record may make you vulnerable. You may be seen as an opportunity to “replenish fresh blood”. In contrast, the less-productive but newer colleagues may show potential, and the hiring manager don’t want to look bad — hiring then firing new guys. In other words, it’s sometimes safer for the manager to sacrifice an old timer than a recent new hire. This is different from my Stirt experience.

My personal biased conclusions —

  • no such thing as long service recognition. No such thing as two-way commitment.
  • If you can be replaced cheaper, you are at risk. The more you earn, the more risky
  • If you are earning above the market rate then you need enough value-add, regardless how long you have served.

##gains{Stirt job loss

immediately after I joined Macq, I realized I have traded up for a better job, better in every way.

  • gain: self-confidence that I can comfortably handle the ensuing financial impact on family
  • gain: self-confidence that I have survived again, albeit with a scar
  • gain: a protective scar — as of 2019 I’m still traumatized but slowly I’m healing from inside
  • gain: lesson learned the hard way — avoid FTE
  • $gain: compensation package more than covered my bench time but still I prefer the … something else instead of the compensation

pureDev beats techLead: paycut is OK #CYW

My hypothesis based on discussions with CYW:

Bottom line –YW said if the pure tech salary is only 20k lower, then he may prefer the workload. The work-life balance, the freedom-from-care and simplicity .. are often highlighted by my tech-lead friends (like Su form GS?), though I suspect most of them still take tech lead roles (or higher).

A techLead has (usually difficult) deliverables for multiple business groups pushing for conflicting priorities. The techLead also need to enlist support from external teams. As such, he as nontrivial additional workload including supervising his own team members, managing users, liaising with other teams … all in addition to he development workload.

  • 😦 吃力不讨好
  • 😦 It’s not easy to mobilize other people to work for your deliverables.
  • 😦 The extra workload often requires overtime. RTS’s Venkat might be an example when he claimed he works 7 days a week.

The power dynamics is based on loyalty. Some big boss might value your loyalty more than your GTD capacity. Loyalty is tricky investment. If you invest in loyalty to big boss A, but A gets replaced by big boss B (as often happens), and B invariably brings in his own loyal lieutenants, then you have a problem. I think Jerry Zhang (Citi) faced this situation when Srini took over.

Unlikely the tech lead, the typical pure-tech contributor doesn’t need to demonstrate loyalty.

I think some senior developer roles are pure-tech-contributors.

mgr role risk: promotion=hazard #Alex@MS

My reflections after a discussion with Alex Vinokur. “mgr” in this context means any lead role.

When I feel left behind on the slow track, it’s usually in comparing to the manager peers.

Alex knows some Morgan Stanley developer. The guy rose to ED but after a while, he wanted hands-on development so he stopped managing teams and became a very senior developer. But his performance/value-add was bench-marked against those hands-off manager EDs. After a while, Presumably he was seen as too expensive as a developer and got the golden handshake in Mar 2019.

When Alex told me this story, I gave this illustration — Suppose with hard work I am competent at Level 5 (mid-level VP) and very comfortably at Level 4 (junior VP) but struggle a bit at Level 6 (ED) when benchmarked to Level 6 peers. In such a case, for job safety I may want to remain at Level 5 rather than moving up. For an easy life, I may even stay at Level 4. If I get promoted to Level 6 I face stiff peer competition, from guys competent at Level 6. The benchmark-risk can be real. 高处不胜寒

When you get promoted to Level 6, you can’t avoid the peer bench-marking. You will get bench-marked, like it or not. I find this peer bench-marking unhealthy and hazardous, but Alex is very explicit when describing the benchmark/calibration system in many firms.

Conclusion — Better remain at a level you can perform well relative to peers.

hands-on dev beats mgr @same pay

BA, project mgr, even mid-level managers in some companies can earn the same 160k salary of a typical “developer” role. For a manager in a finance IT, salary is often higher, but for a statistically meaningful comparison I will use a 160k benchmark. Note in finance IT or tech firms, 160k is not high but on main street many developer positions pay below 160k.

As stated in other blogposts, at the same salary, developers enjoy higher mobility, more choices, higher career security…

mgr role risk: age-unfriendly

Statistically, very few IT managers can maintain the income level beyond age 55.

I believe those managers in 30’s and 40’s are often more capable, more competitive and more ambitious.

Even if you are above average as a manager, the chance of rising up is statistically slim and you end up contending against the younger, hungrier, /up-and-coming/ rising stars.

##150k@light GTD-load: which FTE

Real deciding factor is coworker benchmark (not PIP/stigma). Are there managers tolerant of team members below the benchmark? Josh, Srini of Citi-muni..? Even in a less demanding company, pressure can be high.

  • — Here are some jobs paying 150k with light GTD-load. Usually don’t attract young bright guys.
  • employer:  slower ibanks like Citi, UBS
  • employer:  some commercial banks like OC, BONY
  • employer:  large traditional buy-side like AIG, Vanguard
  • employer:  3rd type financial firms like exchanges/ECNs, data vendors (Reuters?), financial product vendors,
  • employer:  non-finance like telcos
  • employer:  startups but they tend to use new technologies
  • less glamorous — like mkt data, back office
  • greenfield codebase with short history —  like OC, StirtRisk
  • smaller codebase — like RTS
  • older workforce — like RTS
  • older technologies — like SQL, C, socket

compare%%GTD to single-employer java veterans

Me vs a java guy having only a single long-term java project, who has more zbs (mostly nlg) and GTD power, including

  • performance tuning in thread pool, DB interface, serialization
  • hot-swap and remote debugging
  • JMX
  • tuning java+DB integration

When it comes to QQ and coding test scores, the difference is more visible than it is with GTD/zbs.

Conclusion — over 10 years, your portable GTD power grows too slow if you stick with one (or very few) system.

Am I advocating job hopping? Yes if you want to remain an individual contributor not aiming to move up.

 

##@55, Safer2b manager or hands-on dev@@

Hi Shanyou,

Based on your observations, when I reach 55, do you think it’s safer as a manager or a hands-on developer? “Safer” in the presence of

  1. competition from younger generation
  2. competition from same age group or older
  3. new, disruptive technologies
  4. technology obsolescence (what I call technology “churn”).
  5. outsourcing

Among these threats, my concern is primarily #1 but what about you?

mgr role stress: project delay #^FTE/contractor

contractor is most care-free. Even As an employee, the pressure to deliver is lower than the mgr.

As a junior VP (perhaps a system owner) you could still stay behind a shield (defend yourself) — “I did my best given the limitations and constraints”. However, As mgr, you are more expected to own the task and solve those problems at a higher level of effectiveness, including negotiations with other departments.

“Results or reasons?” … is the manager’s performance review.

Recall Yang, Stirt-risk …

  • —- past barometer due to project delivery pressure —-
  • GS – 10/10,  “if i quit GS I may have to quit this country; I must Not quit”
  • Stirt – 8
  • Mac – 7
  • OC – 5, largely due to fear of bonus stigma
  • 95G, Barc – 3, due to mgr pressurizing
  • Citi – 2

mgr role risk: smaller job pool

When not comfortable (under threat), or job lost … the prospect of finding a similar job is much worse than a hands-on developer, because the number of senior mgr jobs is much smaller.

Avichal basically said he would avoid hands-off manager roles.

As contractor, most of the time I feel very relaxed about moving in and out. The price to pay, of course, is lower salary.

contractor^citi-FTE #JackZ

Jack Zhang described the old AT&T’s laid-back culture – 4 managers for one foot soldier; short workday + basketball game; contractors working harder than FTE ..

Based on my first-hand observation, Citi also has a very laid-back culture, bureaucratic inefficiency, “wheel spinning” as Srini put it.. so workload is noticeably lighter than other i-banks. If I were to become FTE I would probably choose Citi. Probably low bonus, but I hate bonus.

However, consulting is still a better option for me because

  • Motivation to keep myself up to date and in-demand. The citi-FTE mode can easily decay
  • In each team learn something new … either major new domain, or minor new skill

mgr role obligation: relationships

A technical or contract role is less complicated, though relationships are also important and can make your life very stressful or relatively easy.

In ## 2 heaviest work stressors, I listed “figure-things-out” as a key stressor — if I’m reasonably fast on this front, then the relationships have limited impact on my stress level at work. Not true for a manager role — even if you get things done fast enough, relationships can still mess up your life.

  • the relationship with the immediate boss is most critical. I had many problems in the past.
  • relationship with other teams. Dependency means … stressful relationship
  • relationship with big bosses
  • relationship with subordinates can also become difficult. Shuo told me it was not for him, but I feel some managers depend on some key subordinates. Dependency means stress.
    • managing a non-performing subordinates … is not easy at all. I could see Kevin had headaches with me.
  • relationship with key business users. I feel Venkat (ICE) is under that pressure.

FTE^contractor: mgr choosing 1 guy to let go

There are individual differences, but I now feel majority of manager-decision-makers across U.S. and Singapore do feel a higher resistance to let go an FTE rather than a contractor. Deterrence:

  • expectation of affected employee that the job is long-term. Most managers won’t ignore your feeling. They are worried about your complaints
  • reflection on her own record as a manager
    • they often prefer an internal transfer
  • formal performance improvement process is not required for non-performing contractor
  • severance
  • official complaints
  • litigation (in the U.S.)

The deterrences are a form of protection for the FTE, but paradoxically, I hate these deterrences, as they lengthen the slow death.

 

mgr role limitation:没当上经理,但换工作/国家 更容易

我选择一直当程序员, 有个好处就是比较容易回新加坡工作,过几年再来美国也容易。

当经理的就没这么灵活。 他们不能太频繁换工作,因为简历会受影响。经理的空缺,数目也低得多。很多类型的经理职位,只在中国, 不可能在另一国家找到同类职位。比如鲁诺所任职的国营企业,比如某同学任职的外资企业中国分公司总裁。

公司招聘经理非常谨慎,招聘程序员则比较简洁迅速。 这对我找工作很有利。

mgr role risk: forced out

An engineer can be forced out, too, due to performance or attitude, but a mgr can be forced out for no fault of her own — change of upper management.

The “like” factor is more important in a manager than an engineer. In a sense, a mgr keeps her place by pleasing her superior, in addition to doing her job (of getting things done.)

Therefore, a mgr position can feel more /precarious/ than an engineer position.

mgr role risk: targeted hatred

“Hatred” is stronger word than “dislike”. Hatred demands actions.

Hatred can emerge among subordinate employees, superiors, downstream teams, or lateral colleagues.

If an employee feels unfairly treated, usually she puts up with it or quit, but a fair percentage (30%?) of them could decide to take action. I once reached out to HR at OC. Some lodge an official complaint.

Even if the employee doesn’t take action, the intense dislike is bound to spread and become infectious.

How easy is it to neutralize or contain hatred? Get real.

How easy is it to remain fair to every employee? Get real.

mgr role stress: inferiority,rivalry

At the senior mgr level, your position in the hierarchy is highly visible to everyone and also in your own mind. The higher, the more visible. You are more likely to feel inferior (+superior) to other people across the industry. In contrast, the regular employee and contractors are not in a position to feel that much inferiority — /blissful oblivion/ means happiness and carefree.

Some would say the inferiority is a /part and parcel/ of moving up, so most people would willingly accept it. I think each individual reacts different. Some may be more affected by it when they move up.

Rivalry is another side of the same coin. It can get ruthless. I remember Mark in PWM.

Demotions and promotions are more intense than the annual bonus situation.

 

 

senior mgr role risk: temptations

A risk underestimated at the senior mgr position — seduction, temptation. You will be a target. I guess the operators are sharp observers. They could possibly spot your weakness.  It’s really human to be attracted to the opposite sex. You can’t completely hide your vulnerability.

A friend ML told me it can be very hard to resist at the right time and right place.

Alcohol is a common “weakening” factor, or possibly a weapon used by the operator.

contractor^mgr^low-VP 3way-compare #XR

See also hands-on dev beats mgr @same pay and my discussion with Youwei in pureDev beats techLead: paycut=OK #CYW

In the U.S. context, I feel the FTE developer position is, on average, least appealing, though some do earn a lot, such as some quant developers. My very rough ranking of total income is

  1. senior mgr
  2. contractor
  3. FTE-dev including entry-level lead roles

Without bonus, the FTE-dev is often lowest. However, bonus is not guaranteed.

I exclude the pure quants (or medical doctors) as a different profession from IT.

 

managers(more than techies)need boss’s like

In a nutshell, compared to techies, managers depend heavily on boss relationship. Techies rely more on self-effort.

Grandpa pointed out that

  • A) as an aspiring manager (at least in China), your boss’s opinion is the overriding factor;
  • B) as a techie or a academic/researcher, you have the right to seek promotion based on merit and technical achievement. If you don’t get it you can try elsewhere.

I feel A) has 2 levels.

  • A1) at the mid-management level, I don’t have much insight, so I guess that unlike entrepreneurs, most managers are not more capable/intelligent then other managers, so I agree boss’s opinion is the #1 factor on your career progression.
  • A2) at the entry level, I actually observed many tech managers including tech leads (or architects), application owners, dev managers, support managers. I think competence level is visibly different. Some (example?) show very high technical capability. This is most relevant at the lowest level, but across the levels, technical capability is not always the #1 or #2 factor. Why?
    • High-level design, technical foresight, persuasion (on tech front) are not always “innate” to these guys.
    • Communication with users, team members, and manager could be equally important aspects. The Mdaq CTO singled out “listening to team members”. Not every leader is good at that.
    • The most technical guy may not be a suitable leader and may be best in another role in the same team.
  • Luck seems to have more impact on managerial than technical track

I think Yihai would have more to add.

Grandpa’s advice

  1. since you clearly know you are not good a management, don’t ever compare with the high-flyers (and invite the self-hate).
  2. know the many people who are less fortunate.

lower pressure to move up ] U.S.^sg

In U.S.,  the overall income differences between a hands-on developer vs a leadership role is smaller.

UE: U.S. engineers;
UM: U.S. managers;
SE: Sgp engineers;
SM: Sgp managers;
  • salary — UE much better than SE. The few high salaries in SE are too rare and unreachable
  • career longevity — UE clearly better than SE; UE probably better than SM too.
  • job security — UE much better than SE due to abundance of similar jobs; UE probably better than SM
  • fungible — UE can move into technical UM and back, more easily, thanks to abundance of jobs
  • tech lead, architect roles  — UE can move up in that direction more easily than SE, thanks to abundance of jobs. SM and UM may not have enough technical capabilities.

Economy — I feel hands-on specialists are more central to the U.S. economy and U.S. companies than in other countries. In Singapore, manager is by far the most instrumental and dominant role.

For a Chinese techie in the U.S. the prospect of managerial path is limited. Most of these managers won’t rise beyond the entry-level. And then consider your own background relative to the average Chinese here.

My tentative conclusion is

[17]FASTEST muscle-growth=b4/af job changes]U.S.

I now recall that my muscle-building and, to a lesser extent, zbs growth are clearly fastest in the 3 months around each job change. I get frequent interviews and positive feedback. This is a key (subconscious) reason why I prefer contracting even at a lower salary. I get the kick each time I change job.

My blogging activity shows the growth…

  • #1 factor … positive feedback from real offers from good companies.
  • #2 factor — I actually feel real zbs growth thought it tends to be less strategic in hindsight.
  • factor — on a new job, I am curious to learn things I have wanted to learn like Xaml, FIX, Tibco, kdb, SecDB, multicast, orderbook, curve building

Beside the months immediately b4/af job change, I also experienced significant growth in

No such environment in Singapore:(

stay long→move up to hands-off roles: hurts fitness

I think a few people I know said they deliberately avoided hands-off roles. Avichal, Nitin of Morgan Stanley, .. If I ever become a manager, I feel 100% sure I would adopt the same career strategy.

(How about German Cheung?)

In the US and in Singapore, I stayed away from hands-off manager or client-facing architect/pre-sales positions.  One of the top 3 justifications is to stay fit. Hands-on roles keep me fit to the job market.

In 80 to 90% of the financial IT job interviews I attended, there’s a non-trivial technical screening, usually a coding test. However, I am an biased statistician or there’s no science here — nothing but personal observations.

Backgrounder — (See also https://bintanvictor.wordpress.com/2016/03/03/long-term-system-expertcontractor/) I did hope to stay in a job for a few years and grow into a system expert. In a few places, it turned out that in one team (say up to 10 people), there are multiple system experts each with many years of experience in the local system. Even if you have 3 years experience in this local system, you may not be appointed the team lead. The chance is 50/50 … could be 30% or 70%. So do you want to remain here for 3 more years and hope for a leadership role?

When I couldn’t rise up in the team, I always decide to move “out” of the comfort zone into the “cold” — every job interview has a technical screening. I soon came to the conclusion that to stay relevant and marketable, I must maintain portable (non-local) tech skills. Many techies at my age wouldn’t choose this route partly because only a minority of techies can stay fit after 45.

Well, I see myself in that (lucky) minority. I don’t mean to say I’m as fit as at 30, but I am fit enough to pass the tech screening.

tech minds moving off management

Q: what’s your value-add in the global economy?

I have seen a bit of evidence that several ex-colleagues moved away from management to shift their career direction into hands-on value creation such as building new systems.

* German
* Avichal Gupta
* Yang (Xie)
* Eric at ICE RTS
* Anshul
* Benny Zhao

In the U.S. (Singapore?) the hands-on roles can pay on par with management. That’s good for me. *******************************************************
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. *******************************************************

%%tech leadership: a few pathways

Many friends feel I could consider how to move up. As an experienced (I didn’t say “strong”) hands-on developer, I saw a chance to move to lead developer, architect or project manager roles when moving to Asia. It didn’t happen, for several reasons.

Now I feel by default I will remain a senior developer at VP or AVP level, and surpassed by younger competitors. Already I feel many 30-something are stronger than I am at this age, technically.

With aging and family commitment, this default pathway is weighing more heavy.

Some people (like Ken Li) believe we will be fine. My parents also feel I worry too much. However, the world is not so kind and caring. Commenting on business (not individual) competition, Andy Grove said only the paranoid survive. The default pathway might get narrower and we might find it harder to find jobs. (In Singapore I already see the telltale signs.) I feel I need to think harder how to move up. I think there are some visible pathways. See also https://bintanvictor.wordpress.com/2015/12/27/app-architect-civil-engineer-or-a-salesman-sgus/

If I have good enough know-how about certain frameworks and base products (such as spring, or MOM, or DB with embedded business logic) I could lead a team in building a few types of solution: * database-centric web apps
* batch processing of data either, in java or scripts.

There are many other types I’m less familiar with but feel confident I can pick up and lead. * mobile front-end + server side
* javascript front-end + server side
* nosql to replace the RDBMS
* MOM-based

I worked harder as FTE than contractor@@

My experience – in terms of work attitude, professionalism, ownership, my contractor jobs were not really lower than FTE. However, longer hours were rare. When I work longer hours as contractors, manager often recognize more easily.

Personal sacrifice was lower.

Ownership of project is often with FTE.

Expectation of bonus is real as FTE.

All in all, the bitterness (and pain, blow to self-esteem…) of a poor appraisal and low bonus is deep, hard, pervasive. It last many months and is a bigger stress than marriage issues, kids poor studies, investment failures etc. I was “shaken to core” (Michelle Obama once said) by those events.

Generally I choose to work at slightly higher than the minimum level to get by.

  • as contractor — sometimes this hurts me (Citi) but often my standard is well above the manager’s
  • as FTE — I don’t like to work way harder than the minimum, because often (Stirt, GS) it’s still not good enough for various reasons, so I would feel “not worth it”.
  • I also have a conviction that managers decide which FTE they like based on non-technical reasons, so why bother to work so hard? If manager doesn’t like me then hard work won’t help a lot.

tech mgr^functional mgr

Most of my immediate managers are “technical managers”, aka
“specialist managers”, or “tech leads” or “development leads” — leading by doing.

The other major category of managers are “functional managers” or “generalist managers”. Examples — PM, senior managers. Lim Yanguang pointed out that the PM’s he has seen don’t have/need any specialist or product knowledge. Job duty is cost control including time-lines, resource management.

When I think about (or compare with) the “managers”, I need to distinguish these 2 types.

  • Key feature — Tech managers can, if needed, write a module by himself. That means the guy must remain hands-on “forever”.
  • Key feature — No one has a better grasp of the technical side of things.
  • Key feature — has to read a lot of code.
  • Quant team manager are always specialist managers.
  • I feel Google’s managers are tech managers.
  • German’s career path is a tech mgr.
  • Avichal’s career path is a tech mgr.

How about product managers? Could be a specialist manager, though Some minor ones don’t really lead any team.

##contract work Usually requires less struggle with existing localSys

contract work Usually requires less of a struggle with existing codebase. Look at

* 95 Green? all interfacing with existing system is via Ravi, so no struggle at all
* volfitter? the c# codebase was not so well established and not such a struggle. The FMD sheet was a struggle but … expectation was really low.
* reo? I was transferred to BAU projects but expectation was low. * nextgen circuit model bulider – some java code was already there before I joined so I had to understand it — a struggle

In general, high rate contract is usually funded by a development project. Not so much prod support, difficulty laser surgery on a overgrown legacy codebase which require lots of local system knowledge.

app owner^contractor#German6Y

Q: Look at my current per-hour value-add to the team. How many percent of that value-add is portable to next two jobs?
%%A: I feel it’s usually rather low. My value-add is mostly about local system knowledge.

Current value-add/hour to the current employer does increase over the years and grows with relationship.

According to German, in the big banks, many team managers badly need an owner-developer, a system expert to remain with the system for 3-6 years. However, on Wall St and London, there’s a long tradition of hiring (proven) high-caliber contractors as the “big guns” to get through a tough project. eg: Song Jun

eg: Rob in the Stirt tech team
eg: bloomberg

Also, from budgeting point of view, a system needs a long-term owner (like BAU), whereas a project needs temporary manpower. So that’s one difference between a lead developer vs a big-gun contractor.

The owner-developer often earns more than the regular contractor but not sure about “big guns”.

Promotion to owner-developer is not guaranteed simply by staying for x years because

  • there may be other old-timers
  • even after 4 years some parts of the system may still be unfamiliar to you
  • even after 10Y on the system, you have below 50/50 chance to build credibility and position to convince everyone to follow your suggestions. Look at Kevin’s influence after just a few years on the system.

For me, it doesn’t make sense to get very familiar with a local system and become efficient and a “powerful” local system expert. Yes the manager would appreciate my value but

  • it often takes 2+ years and a lot of learning effort (Does it cause aging? Only if excessive stress.)
  • Still, for many years the existing experts may remain more powerful than you, so manager may not appreciate your value as much as you expected.
  • the learning effort takes away from my “body-building”
  • Depending on context, it offers only 50% protection from job loss. Sadly, due to lack of body-building, you may become weaker on the new job market.
  • the appreciation seldom translate to meaningful compensation

social class]U.S. n%%chosen tech domain

I used to feel US is a less class-conscious society than China or Singapore. Anyone can make it in this “free”, meritocratic country. Then “insiders” tell me about the old boy’s circle, and the alumni circles on Wall St.

I feel in any unequal, hierarchical society, there are invisible walls between social strata. I was lucky to be an immigrant in technology. If I step out of tech into management, I am likely to face class, racial bias/affinity and … I would no longer be “in-demand” as in tech. Look at the number of Chinese managers in GS. Many make VP but few rise further.

Therefore the tech role is a sweet spot for an immigrant techie like me. Beside Tech, a few professions are perhaps less hierarchical – trading, medical, academic, research(?), teaching …

What could be the#1 task4a manager #Simplistic

Disclaimer – I’m no expert on management. Let me limit my perspective to the only subset I know i.e. IT management either in development, support, infra, delivery …

$ Some American author (P. Drucker?) said the #1 element of leadership is people motivation. Perhaps relevant in a start-up. I feel for a typical middle manager, even if half the team is non-productive her own performance would be unaffected.
$ Some (XXH) characterize manager’s role as managing relationships. (I guess you could say the same about a salesman, a PM, a BA, an architect or almost any role.) I feel in most cases the #1 relationship to manage is the guy who determines the manager’s own performance.  Typically it’s the boss, or perhaps the big customer being served if the manager is client-facing. As to the relationship with team members, actually not that important to him.
$ A senior manager (SCS) once told me “complete project on time within budget” is everything. Sounds like it requires the right people in the team. However, in that context I feel the more important relationship to manage might be the (internal) customer.
$ Many experienced managers jokingly say “my job is coordinator and dispatcher”, since all the real work is done by the people below.
$ Chunmei liked to emphasize judgement or pan-duan-li as the key to management (key to any success). I like this view.
$ Some management science researchers found planning and esp. Execution is the key challenge of management. Good theory. In IT and esp. software development there’s such a great deal of details to get right. Execution is about getting the important details right.
$ Managers are measured and ranked (by their superiors) according to their numbers. A self-preserving manager would be unwise to focus on anything else.
$ For a manager at a higher level, perhaps the really important job is to identify key individuals to run the sub-teams. But I feel it’s /farfetched/ to put it as #1 task

leadership – leverage on specialist knowledge

Some people make a good leader without specialized expertise. I feel many top level executives are this type.
Some people make a good leader after establishing a status as a subject matter expert. I guess they no longer need that expertise. Some may need it if a big part of leadership involves technical sales and technical vision.
My father has academic leadership, based on his domain expertise. More generally, I guess in quant domain, in research and academia, a leader must have a minimum level of specialist expertise.
Some specialists don’t take on leadership role at all. I know some in the US.
My parents and some close  friends (I won’t count the numerous comments by casual friends) point out that I show a “relative advantage” in research/academic areas relative to people management, but let’s not talk too much about myself.
Q: is your chosen field right for you?
A: I feel in theory financial app development isn’t really the best for a lot of guys, though it may be the best given my constraints now. For many, it’s much better than other IT sub-sectors.
First and foremost, it’s painful, depressing but unnecessary to compare with those “leadership” people. They aren’t even our peers.
If  you were to leverage your specialist knowledge to build leadership, then the next task is to identify a specialist field. C++, c#, java etc. aren’t that appealing so far. After this step, we would need to stick to a company. I chose GS but GS didn’t choose me:)

specialist^generalist(manager), SG^NY #le2Ed

To compete in a knowledge-intensive industry, an organization needs specialists + good managers (what I call generalists).

In labor-intensive industries, specialists or knowledge experts are less important. Important roles (below the C*O level) in such an organization are effective managers. Singapore has a reputation for producing effective managers.

Singapore is trying to move off labor-intensive into knowledge-intensive sectors such as life science, research, high-tech design, high-tech manufacturing (such as chip making, where I once worked), education/training… The sector I know best is the Info tech (IT) sector. IT is often cited as knowledge-intensive, but the large workforce required in a typical IT project makes it more and more like a blue-collar labor-intensive industry. You don’t need top experts in a typical IT project. You do need good managers. They make important decisions, shape the team culture, create the communication patterns, select team members for each task, motivate and lead….

Now let’s zoom into a special sub-sector within IT. In investment banking, IT is relatively labor-intensive, with large headcounts. In contrast, quant and true front office trading roles are specialist roles — very few head counts but very high financial impact.

What I found recently in Singapore vs Wall St job market is — Wall St pays big bucks for both specialists and generalists, whereas Singapore primarily rewards generalists. Certainly there are quant and trading roles in Singapore, but I can’t qualify for those so I only focused on tech roles. On Wall St, there are a good number of well-paid developer positions — specialist positions, paid on par with entry-level managers (Some architects are paid like mid-level managers). Very, very few such roles in Singapore. In Singapore, well-paid IT roles are exclusively managers and high-level architects (largely hands-off). These generalists are no doubt important — they are important on Wall St too, and also in traditional industries. It’s easy to recognize their importance so they are well-paid.

I’m not a manager, and without substantial management track record. I’m more of a knowledge specialist (aspiring to an expert). That’s why it’s so tough for me to get a suitable job in Singapore.

professional consultants — tone down personal taste

Respect your client’s preferences and personal tastes. They will inherit and live with the code you leave behind. If they don’t feel comfortable with some part (even if it works perfectly) they have a legitimate reason to change it to something more manageable.

You are not owner of that code. You are writing it for him/her to own.

Imagine you are a carpenter making a dressing table for a client. Is your personal taste or client’s taste more important?

In fast-paced finance IT, sometimes you can be forgiven to adopt your personal favorite choice (rather than client’s favorite) to help you get things done fast — since you are the coder. I feel in some contexts time-to-market is still the paramount consideration.

baptism of fire – get a team lead role

Given the weakness in empathy, protocol, etiquette… there’s a Contrarian suggestion to actively get into a leadership/coordinator/client-facing role in a big bank.

Will I become a bull in a china shop? Look at %%history.

Build track record, hard evidence — builds self-confidence and also credibility.

Get on the offensive rather than the defensive. I’m sick and tired of listening to wise (and caring) friends’ advice what I am not good at. The more I try to avoid mistakes, the more mistakes I see in myself, the lower my self-image. In fact, I left GS not just because of empathy, but more due to salary and productivity.

For example, I have more lunch meetings with all kinds of friends. So does Mithun, though we aren’t very empathetic people.

baptism of fire.

However, China and Singapore leadership roles might be too dangerous, where the magnitude of damage is probably too high.

My GS team lead isn’t good with etiquette and protocol but he gets things done. I think users appreciate him and one of his bosses adores him.

self-management: Part 1: managers’ negative xp

If you ask Wall St IT hiring managers for important personality traits, the most frequent answer is “can get things done on his own”, “less hand-holding”, “low maintenance”, “won’t get stuck”, “…. which is why we want senior, experienced developers”.

Maybe I’m wrong but i assume they are speaking from experience.

Q: what are the negative signs and examples managers have seen in their experience?
A: (see blog on know when to depend on others and when to master a subject) always asking for colleague’s help.
A: inability to summarize issues in writing.
A: inability to generate presentable reports for upper management.
A: can’t get to the point quickly
A: can’t take control of a crisis situation
A: some developers can’t effortlessly, confidently chair a meeting.
A: asking the wrong question, esp. in a mass email. Wrong Like wrong phrases, __indecent_exposure__,
A: problem interfacing with other teams, and esp. teams under rival managers.
A: some developers need manager to remind her over and again some details of the deployment/testing process
A: it could be a good habit to let your mgr proof read your important email to users, but that’s often a sign of hand-holding.

who to command a trading IT team

Among these 4 alternatives below, which one can best command a typical fast-paced, elite trading engine developer team?

Assumption – battle-tested trading system architects are rare, therefore in some cases, manager must select someone slightly less qualified. Needless to say, in reality one person often wears multiple hats.

– BA? Personally I feel No but not sure in practice. Good local domain knowledge, business communications … is half the story. However, some BA’s have recent development experience.
– PM? Often less technical and less hands-on. Perhaps insufficient. Many practical problems require implementation insight
– Architect-on-paper? Must become hands-on to command. Too many uncertainties on the ground. You must be ready to roll up your sleeves. Planning vs execution — The latter dominates.
– Lead developer without architect credentials? Usually good enough. Practical problem solving. I’m biased towards the hands-on developers.

Now for my long term survival to age 65, I feel the hands-on developer enjoys more flexibility and career choices. More geographical choices too.

hands-off manager@@ According to Lego of PWM

Q: most app teams have no _dedicated_ DB guy?? (though I know an ex-DBA in a trading floor RTB team) Database logic change is usually part of a BTB developer’s job. Database investigation is both RTB/BTB work
A: in a _data_service_ or reporting application team, there IS someone dedicated. But you also need some auxiliary skills like ETL or reporting _products_.

Q: many hands-on developers endeavor to move UP to a hands-off manager role?
A: if you manage a team of 5+ developers, then it’s hard to be hands-on.
A: if you are hands-off and just manage subordinates/users/upstream/downstream…, then you are vulnerable. Bottom line is “deliver results to business”. Example – system slowdown, users complaining. Hands-off manager must know how to command his troop to resolve the issue, quickly. If a manager has no system knowledge, he can’t command. It all depends on the expectation on the leadership role.

%%A: I’d say the hands-off manager (a “him” for example) needs to show off knowledge of his system internals, to gain credibility and user confidence. What if a subordinate (a “her”) openly exposes the manager’s lack of system knowledge? If the knowledge is expected of him, then she’s hated. If he can easily shrug it off as “low-level” details he doesn’t usually deal with, then he’s safe. In a production outage conference call, she should listen to his cue.

Q: so a hands-off manager just needs the BA’s skill – coordinate and clarify with users and other systems?
A: manager needs that skill but also need to do more than a BA.
%%A: a lot of GS vice presidents are really Biz Analysts. I feel in PWM Tech, technical is less valued than business or mgmt trec. More than once, senior managers openly say that if they retain a key manager, then the entire dev team can be rebuilt from 0.

Q: so to keep business users productive, every app manager (incl. hands-off ones) needs some high-level system knowledge? He needs no low-level knowledge as required of developers?
A: right

Management trec vs tech trec

(At least In theory) An experienced developer can do a basic job as PM, architect, BA … but not vice versa. I have seen some examples — Yang, Lance (Lab49), Jerry, Rob Westlaken (Citi), myself in NIE, in EOS+SIM, … Management skill and experience requires less serious training IMO. Many people are born managers. Some people even told me I have good management skill. In a trading system, managers’ competences include

* managing business users
* managing team
* managing the senior manager
* #2) delivering biz value. Finish projects on time, in budget. This is what a keen hiring manager would tell a reluctant candidate. In trading, time to market is a priority.
* #1) meeting senior manager’s expectations, and help him rise.

I feel an experienced developer can meet all these basic requirements.

Miao Weishan pointed out an elite class of managers actually manage very well. I  guess the evidence is that given an ordinary team of resources, such a manager could achieve well above the expectation.  Beside technical know-how, I guess such a manager would demonstrate exceptional judgment (判断力, including strategic insight) and inter-personal skills. Many books talk about the “top 5 fundamental qualities” of a manager, things like
* planning/execution,
* motivation,
* persuasion,
* loyalty of staff,
* energy,
* perseverance/endurance….

I guess many of these qualities are relevant to a parent like me, too. I feel these qualities are well above the basic requirements listed above, so a competent developer isn’t enough.

humor in a manager

Now I feel humor is a universal tool and often a first-aid kit for a development team leader, esp. in fast pace, high pressure environments…
The higher one climbs, the more important humor becomes. Look at Obama vs. Hilary…
People say Asian managers are less good at it…
I’m not good at it. As a young engineer I was a bit flamboyant, rather unconventional, and sometimes foolhardy, but as a saving grace I was honest, reliable, quick and helpful to colleagues. I broke lots of rules. was somewhat fun to work with, but unknowingly offended countless colleagues, esp. in large corporations. In fact this is a key reason why I always feel uncomfortable in large companies with structures and protocols
Within such constraints, I find it hard to exercise whatever little humor I have.
By contrast, in smaller companies I interact with CEO or top level managers. They know my personality and accept me. As a result, everyone else has to bear with me. In such a “freer” environment, I would relax and a tiny trickle of humor flows.  
Humorous people are usually smart and smart people are usually humorous. For me, a third thing to make a trio is cool confidence.  Smart and humorous people are usually relaxed and confident. Cool and smart people are usually humorous.…
My sister is humorous, everyone agrees. Also very confident, and a mid-level manger in a large MNC.

Can a bright rookie join the project you own@@

One GS interviewer (Mark deMunk?) asked me to imagine myself as a team lead. A bright C programmer wants to join a java project and learn java. What are the key factors beside timeframe, criticality, monetary cost/profit?

I mentioned “viability” ie Can he contribute at all? Even with quite a bit of time and non-mission-critical, sometimes a bright rookie just can’t. Maybe it’s too difficult. Maybe it’s not well-modularized so a newcomer must quickly absorb lots of things. Maybe …

Interviewer suggested “complexity”. I decided to defend myself.

* A Complex project may still be open to a rookie is it’s well-modularized and/or there’s someone to guide him so he can take a small bite and chew it slowly. I think usually complexity comes from business requirements.

* On the other hand, a ten-table DB design is perhaps low-complexity. Further assume it’s not critical. A rookie could try 5 times and still fail to get it right, if he doesn’t know the normalization/denorm practices and what key questions to ask the DB users. I think it takes a rookie a few hours of research and consultation to get it right. My point is, do you want to trust a rookie for that?

handling non-conforming programmers

How I handle non-conforming programmers was similiar to other small team managers. I am not a gifted leader or a fast learner in the area of leadership and motivation.

Top of my strategies — i tell myself to focus on understanding each person’s perceptions, habits, preferences.

I tell myself to try to be more flexible. A leader need to be less flexible with the key performance measurements — top priorities. Low priority issues like punctuality, coding style, dress code…. I can be flexible. I think these priorities affects my relationship with non-conforming programmers.

I avoid using pressure techniques. Some friends suggested that i learn to be faster at identifying stubborn, greedy and selfish programmers early and not waste time trying to preach and convert them into more cooperative team players.

Some small team leaders advise me to adopt a different style. I think they keep a bigger (and healthy) distance from the team members, which help them maintain some status of authority. I too consider status of authority important, but i don’t achieve that by being a bit “aloof”. I think these leadership styles can affect the relationships with non-conforming programmers.

Overall I now think i’m more influenced by Buddhism than Christianity or Sun Tze’s art of war. I actually followed the rule “assume everyone to be unselfish, fair, cooperative until proven otherwise”. I think Buddhists are often considered naive. How could I have a bit of Buddha’s wisdom?