val@pattern_recognition imt reusable_technique

Reusable coding techniques include my classic generators, DP, augmented trees, array-element swap, bigO tricks like hash tables and medium-of-3 pivot partitioning.

  • One of the best examples of reusable technique — generate “paths/splits” without duplicates. Usually tough.

More useful than “reusable techniques” are pattern-recognition insight into the structure and constraints in a given coding problem. Without these insights, the problem is /impenetrable/intractable/.

Often we need a worst input to highlight the the hidden constraint. The worst input can sometimes quickly eliminate many wrong pathways through the forest and therefore help us see the right pathway.

However, in some context, a bigO trick could wipe out the competition, so much so that pattern recognition, however smart, doesn’t matter.

 

Advertisements

##high-level factors for dev-till-70

  • Jiang Ling said even at an old age, “easy to find paid, meaningful coding projects, perhaps at home”. Xia Rong agreed. I kinda prefer an office environment, but if the work location is far away, at least there exists an option to take it on remotely.
  • see j4 dev-till-70
  • — #1 factor is brain health. See my blog tag. I believe I’m in control of my destiny.
  • — #2 factor is demand
  • Wall St contract market is age-friendly — [19] y WallSt_contract=my best Arena #Grandpa
  • c++ is good skillset for older guys. Core java is also good.
  • churn
  • — #3 factor is my competitiveness among candidates. See Contract: unattractive to young developers

## stable base;fluid superstructure in G5 tech skills

My perspective in this post is mostly tech interview — accumulation, retention of knowledge, prevention of loss due to churn. As I age, I’m more selective what new technology to invest into.

In contrast to the interview perspective, the GTD perspective is dominated by localSys ! So churn doesn’t matter.

Many of these technologies are past their peak, though none is losing relevance. However, I tend to perceive these tech skills as robust and resilient, time-honored. Among them, I see a partial pattern — Many of them exhibit a stable base; some of them show a fluid superstructure of skillset.

  1. essential algorithms/data_structures and bigO — stable, possibly growing base + fluid superstructure
  2. java skillset — has a stable base i.e. coreJava + fluid ecosystem including jGC, jxee
  3. C/C++ — has a stable base skillset including TMP, STL… The superstructure is fluid mainly due to c++0x
  4. SQL and socket — each has a stable base
  5. pthread, unix internals ..– ditto
  6. unix (no QQ topics, but many GTD skills) — stable superstructure skillset including instrumentation, utils and scripting. Base? tiny.
  7. http stack — stable but tiny base including session/cookies + fluid superstructure

eg@traction[def2] in GTD^IV #Sunil

Sunil is not the only one who tried but failed to break into java. Sunil was motivated by the huge java job market. I believe he had opportunities to work on (probably small) java projects and gained confidence, but that’s really the easy part. That GTD experience was completely insufficient to crack java interviews. He needs IV traction.

  • Zhurong also tried java
  • [g] Venkat actually got a java job in SCB but didn’t like it. I feel he was lacking GTD traction
  • [g] XR and the Iranian java guy had some c# projects at work but didn’t gain traction.
  • CSY had a lot to tell me about breaking into java.
  • [gi] CSY and Deepak CM both had java projects at work but no traction
  • [i=IV traction]
  • [g=GTD traction]

IV/QQ traction — I experienced better IV traction in c# than c++. I think it’s because half my c++ interviews were HFT shops.

GTD traction — I had good GTD traction with javascript, php …, much better than c++. My C# GTD traction was also better than c++. C++ is probably the hardest language in terms of GTD. As explained to Kyle, my friend Ashish experienced tremendous GTD traction but can he crack the interviews? Hiring teams can’t access your GTD but they can ask tough QQ questions.

[17]predict 2-5Y job satisfaction #OC surprise

Q: did the learning actually help with my job interviews (am not salary-focused like Mithun)? This is a key feedback.
A: Yes to some extent

The “table” is subject to frequent change, so I keep it in recoll (was a google sheet). Here some notes:

  • stigma/appreciation/respect(zbs) — turns to be the #1 key to job satisfaction, but appreciation is tricky. Bonus can break it, performance review can break it, other things can break it too. I often felt like “damaged goods”.
    • In Mac and Stirt (and OC too), managers considered me good enough for transfer to other teams.
    • retrospective can be more negative than dissatisfaction then-n-there, for Macq, Stirt
  • salary + other income — turns out to be insignificant when I have inner confidence and self-esteem. It is still one of the most important factors. When it’s very high, it overrides almost everything else.
  • distractions — do hurt my O2 for GTD, zbs development and self-learning
  • traction — positive feedback, includes zbs growth, instrumentation, self confidence, IV, catching up or surpassing peers
  • strategic orgro/stagnation — turns out to be a white elephant.
  • Many of the top factors are “perceptions” rather than “hardships”
    • perceptions — self-esteem@comp; strategic tsn; engaging… #best eg@perception — peer comparison
    • hardships — mkt depth (job pool size); workload; family time; commute; salary

! OC job was actually not bad if there were some appreciation from boss. However, the new, strategic specialization didn’t bring enough satisfaction.

! Verizon job experience was rather positive. I was on the rise, in my prime. It all ended when I moved to GS. I should have quit GS earlier. Citi was the start of another prime period. Prime mostly in terms of self-confidence, self-esteem …

My prediction — to have a satisfying (not necessarily strategic) job next time,

  • I need the #1 factor — appreciation.
  • A well-paid java job will mostly likely make me feel good.
  • LearningSomethingNew and engagement will NOT be a deciding factor (Recall c#/py experiences). I will still make time to learn something, just like in 95G

 

## G3 uncertainties for 10Y: #Demand^otherCandd

Let’s be specific — on the competitive landscape over next 10Y, what specific factors are we trying to predict

  • G3: predicting my healthy, energy, motivation, absorbency, “retention” (MSFM…), coding drill visible-progress ..
    • I have 3x more insight on this factor than other factors
  • G5: predicting strength of competing candd (i.e. candidates), often younger
    • one note — my accumulated theoretical and low-level QQ strength will continue to be rare among the young competitors
  • G9: predicting market demand evolution, including churn. Coding IV is the prime example.
    • Note this evolution is not so fast. Read my analysis of MOM and RDBMS

Since 2017, I have tentatively started to shift more focus towards west coast. As a result, the Competition and Demand factors felt too fast-changing, which makes my painstaking analysis look naive and futile.

Critical thinking needed — Suppose I keep my focus on ibanks. In such a case, my analysis and prediction is actually relevant, even valuable. The Competition/Demand factors have not changed drastically.

I’m pretty good at this kind of competitive landscape analysis , but It’s truly tough to predict any of these 3 factors. However, as Warren Buffett (?) observed, those who decide to give up and submit to mindless investing is likely (not guaranteed) to lose out to those who try and analyze/predict.

 

##elusive^achievable gains{tsn

When I try-something-new, i aim at multiple target ‘gains’ as in a pyramid

  1. strategic value, long-term orgro is the most elusive, comparable to HuKun taking his brother as role model. Biggest success I can think of is c++ (thanks to lots of IV). More strategic is my rental property investment
  2. salary hike is one of the least likely [CVA]
  3. I hope to open up new job markets at similar pay. I enjoy a wider range of opportunities and being in-demand
    .. but what if the new “market” is unsuitable?
  4. I hope to broaden my capability-base incl dnlg.
  5. I don’t want all my eggs in one basket… hedging
    .. but the broad base may not be so relevant
  6. I hope to build my self-confidence about learning
    .. but sometimes not much self-confidence boost
  7. I hope to keep my mind young, active and engaged, rather than doing the same boring job over 5Y. i hope to avoid wasting my precious spare time – burn/rot
  8. (Not really about tsn) i also want to strengthen my position, extend my lead on the body-building race. This effort takes huge amount of energy

case study: swing — rare engagement + orgro, thick->thin but abandoned !

case study: c# — i made sacrifices for deep-dive, and in return experienced rare engagement + orgro + thick->thin. I have since given up the direction, as c# is not so relevant to my current direction.

skill: deepen^diversify^stack up

Since 2010, I have carefully evaluated and executed 3 broad strategies:

  1. deepen – for zbs + IV
  2. diversify or branch-out. Breaking into new markets
  3. stack-up – cautiously
  • eg: Deepened my java/SQL/c++/py knowledge for IV and GTD. See post on QQ vs ZZ.
  • eg: diversified to c++, c#, quant, swing…
  • eg: diversify? west coast.
  • eg: diversify? data science
  • eg: diversify? research + teach
  • eg: stack-up to learn spring, hibernate, noSQL, GWT.

Stack-up — These skills are unlikely to unlock new markets. Lower leverage.

GTD stress/survival on the job? None of these help directly, but based on my observation GTD skill seldom advance my career as a contractor. It could create a bit of spare time, but it’s a challenge to make use of the spare time.

I feel German’s strategy goes beyond tech skills. He treats tech skills as a tool, used to implement his business ideas to create business value. I feel his target role is a mix of architect/BA but more like “product visionary”. It’s somewhat like stack-up.

[11]traction[def1]^learning curve gradient

Context — learning a new software language, API, entire server (OS, DB..) or toolkit, with non-trivial concepts embedded therein.

The more common pattern is the learning curve. Initial gradient is often higher as pick up speed. After 6 months (or 1, or 12..) it flattens and tapers off and you experience diminishing returns.

A 2nd pattern is “gaining traction” . For the first 4 weeks (or 1 or 20..), you spend a lot of time reading and experimenting but without growing confidence…

  1. after a while, you start to connect the dots via thick->thin, often in a series of incremental breakthroughs.
  2. thick -> thin is not merely (superficial) accumulation of knowledge
  3. you often need perseverance and sustained focus. See focus+engagement2dive into a tech topic#Ashish
  4. knowledge gap build-up above the new entrants
  5. high ROTI
  6. high retention rate
  7. gaining-traction is opposite of wheel-spinning

I experienced and overcame this wheel-spinning process in ..

– swing
– C++, – java, c#
– python
– JMS, RV
– drv pricing
– options
– yield
– IRS

Solution?

A related pattern is engagement