fellow experts siz`up each other≈ QQ IV

  • Scenario — Female engineer at an electronics exhibition booth, in the 70’s.
  • Scenario — a passenger falls sick on a flight and two doctors (different countries) came to the rescue. They size up each other to decide who to take the lead.
  • Scenario — two musicians across genres play together impromptu for the first time. Musicians usually are cooperative not competitive though.
  • Scenario — a comp science student visits another campus and logs in on the local network and start exploring (not “hacking”) and encounters local students on the network.
  • Scenario — provincial basketball player coming to a new town and plays a first one-on-one game with a top local player.
  • Scenario — an interesting algo challenge is openly discussed, among programmers from different countries and across industries. A problem to be solved in any language without external tools.

These scenarios are similar to QQ interviews. (Algo interviews are subtly different but mostly similar.) Venkat of OC impressed me with his c++ and c# QQ knowledge.

When fellow experts size up each other … what acid tests can they use? Algo, QQ topics or ZZ topics (I tend to read in my spare time)?

To really size up each other, we need to discuss common topics, not Your or My localsys.

.. but many people only talk about, in vague or high-level terms, how some localSystems were supposed to work, often based on hearsay. They leave out the important details. It’s impossible to verify any of those claims.

When we watch a movie from Europe, India, Korea … we can tell whether it has any international appeal or only limited local audience.  Similarly localSys knowledge has value only within a single company. The expertise I demonstrate in job interviews are relevant across many sites.

If I were a 5Y VP (or ED) I would have self-doubt — am I just a localSys expert or an accredited expert as proven on benchmarks/interviews? Look at Shubin/Steve, the Sprite expert in London, Richard of Quoine ..
Their expertise and value-add can be marginalized in the context of the current mainstream technologies.

[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

 

engaging[def1] #marketableDomainXp.xls

Let’s keep this in blog , not spreadsheets.

“Engaged/engaging” means level of mental engagement, including traction, level of interest and positive feedback loop. This depends on many things such as trySomethingNewStrategic. In retrospect engagement may not mean much, but it does affect my satisfaction then and there, which is important according to Theodore Rubin.

Engagement is a major determinant of medium-term job satisfaction. Because of it I walked away from CVA, Barx and other higher, easier java jobs.

This factor is notoriously n inherently elusive, unstable (strategic). Engagement is impermanent, then-and-there, like joy and sadness. I once found wafer fab spacesuit fashionable! Big data, wpf, quant, swing, FIX, kdb, … were once attractive to me. What’s engaging used to be stategic trySomethingNew, but look at other blog posts… It’s hard to identify an endeavor as long-term engaging.

When I was into option math, I didn’t want any low latency or connectivity projects.

I think soon I could lose interest in mkt data or latency.

However, even in a 5Y java/c#/python job, I believe i can find engaging challenges.

Q: On marketable-tech-xp.xlsx, which factors on row 2 help keep my mind engaged?
– Some form of complexity is always helpful. There are some on Row 2.
– Poor “market value” always decimates my “engagement”. There are some protective factors on Row 2.

The job_satisfaction_predictor spreadsheet compares past jobs in terms of engagement.

 

 

## past vindicative specializations

see also — For the “domains nlg” (first 5 rows), marketable_domain_xp spreadsheet is more comprehensive but not necessarily more updated.

Quant and other Unsuccessful diversifications aren’t the focus here, but are listed below the table.

 scales 0-5 mkt value given my direction robust
demand
entry barrier accu achieved %%expertise
among peers@WS
tsn: determination
+sacrifice
I was delighted wage ROI val4IV
mktData #socket  4 growing not everyone has xp  2~3 2 #few worked@socket-level 2  5 some 2
bondMath  2 robust math is not natural
to most dev
 2  3 1 #spare time++  3 some 2
orderBook, OMS, FIX #Eq/FX  3-4 robust medium 1 #cod`IV 1 3 #CVA sacrificed  3 none
forex #sg 2 robust medium 1 1 0 #spare time 1 none
c++  5 ok not
growing
higher than I thought  5 #critical mass  3 5 #huge sacrifice  2 minimal
coding drill  5 Growing high 4 #XR disagrees  3 2 #spare time  5 none 4
python  4~3 growing low  2  3 #unknown 1  4 none
bash scripting + unix #devops  2 robust medium  4  3 0  3 none 1
threading xLang 5 growing high  4 #critical mass  5 0 4 some 5
(abstract?) xLang collection internals 5 unexpected strength the deeper the harder  4 #critical mass  4 0 4 some 5
RDBMS 3 shrinking low  4 #critical mass  4 0 #spare time 1 #under-whelming none
[00-06] web dev 1 sustained high growth low  5 #critical mass  3 0 3 none

–algo practice for IV
^ good amount of accumulation
^ my confidence is boosted esp. in c++
^ I’m rising to the challenge of coding test growing popular

–Python
^ boosts my IV confidence
▼no critical mass yet
▼low traction
▼don’t know my expertise relative to peers

–option domain knowledge including BS:
▼ much lower demand than bond math

— C# and XAML
^ Microsoft is a major force
▼not aligned to my current direction

–MSVS:
^ was my Achilles heel, now slowly gaining confidence

–C++ GTD and IV
^ I made real progress in 1) GTD and 2) IV but not during Mac days — wrong job nature
^ deepens my java understanding
▼ those high paying domains (HFT, quant) are too hard to break into

–MOM architecture, products…
▼falling out of favor
▼ not as widespread as I perceived. Probably used in finance and legacy systems

–javascript, php, mysql
▼not aligned to my direction

–gemfire
▼ market too fragmented

–EJB, Spring, Hibernate
▼falling out of favor

##failed cod`IV

Here I only list the failed ones. There are many successful ones in ##some@the significant coding IV experiences

 

QQ BP ECT speed syntax algo where
 ? 😦 NA NA ? home c GS tick-engine
NA 😦 NA NA ? home c Tetris
 ? 😦 NA NA ? home c Macq
😦 😦 NA NA NA home j MS-commodity
? ? NA NA 😦 home j Amazon
😦 ? NA NA NA home j MS itr
😦 ? NA NA NA home j MS FIX
? NA good good 😦 codility c/j Mako
NA NA 😦 ? ? codility j FXoption
NA NA 😦 ? ? codility c Jump #3
NA NA 😦 slow good IDE c Bbg 2017
 NA ? 😦 slow good webex c Citadel array-shrink
none ? 😦 good simple IDE j UBS Suntec
😦 NA NA NA ? paper c Nsdq array 0-N
NA NA NA NA 😦 paper c Nsdq day-trading
😦 NA NA NA 😦 paper c FB regex
😦 NA NA NA 😦 paper c Goog
😦 NA NA NA ? paper j Barc SmartOrderRouter
😦 ? ? NA NA NA paper j UBS YACC
😦 NA NA NA NA paper c Bbg London
😦 ? NA NA NA paper c Imagine Software

See C++(n java)IV tend to beat us]4fronts.

Q: where is my biggest coding IV weakness? crack the algo? complete in pseudo code? or get the damn thing to compile and work?

  1. take-home tests usually beat me in terms of Best Practice
    • possibly give up if I must give up something 😦
  2. speed coding tests usually beat me in terms of ECT speed
  3. white-board tests usually beat me in algoQQ

a profession with Enjoyment+income+barrier

Update — Enjoyment is often short-lived and affected by too many factors like

  • respect by mgr #bonus
  • “strategic” learning #Barclays
  • commute
  • income cf to peers

Instead of Enjoyment, I often prefer “engagement”.

However, for both enjoyment and engagement, the signal-to-noise ratio is below 0.2 i.e. those “noise factors” above are at least 5 times stronger.

——–

Background — discussion with an older fellow developer about helping our high-school kids select a major.

Example — Look at Aunt Gennifer. She changed her profession around age 40 to find a better paying and less boring job.

Example — grandpa has an ever-green interest in his research field, but most researchers in this field are not well-paid (it’s the least commercial field of research). In terms of income, I think grandpa’s medical and pension benefits are in the the top 1%.

Example — me. I entered trading-engine-dev circa 2007.

  • It pays well above the average professional salary across all professions. (I was told U.S. family doctors earn about 150k only.)
  • Market depth is excellent — look at my post on NBA salary.
  • The constant pressure to upgrade and learn is perfectly acceptable to me. In fact, I seek opportunities to maintain my learning pace
  • I don’t find it tiring or boring. For a few years before 2007, I told myself “I don’t want to remain a developer for life” but had a U-turn.

For most people, it’s hard to find a profession that’s not boring, not too tiring, and pays well, a field you could keep plowing till retirement, if you ever retire.

In fact, such a field is likely to be /oversubscribed/ — too many hopeful new entrants but few would get in and fewer would survive 😦

Example — Lianzhong’s daughter Borong loves writing, but she realized it wouldn’t be an easy way to make a living. Similarly, a large number of individuals have a meaningful and rewarding “hobby” but can’t make a decent income from it

  • tweaking with computers and gadgets
  • visual arts # including photography
  • literary arts
  • performing arts #including music
  • sports, games #including board and electronic
  • cooking

c++11,sockets,IPC in QnA IV #Ashish

[18] Update — This has become one of the more  valuable posts in my c++ blog. It cuts down the amount of info overload and learning curve steepness by half then again by half.

Hi Ashish,

I now have a little theory on the relative importance of several c++ tech skills in a job candidate. I feel all of the skills below are considered “secondary importance” to most of the (15 – 30) interviewers I have met. These skill are widely used in projects, but if we say “no experience” in them, BUT demonstrate strength in core c++ then we win respect.

[e=c++ecosystem topics]
[c=core c++topics]

—#2 [e] c++threading —— many job descriptions say they use threading but it’s probably very simple threading. Threading is such complex topic that only the well-reviewed proven designs are safe to use. If a project team decides to invent their concurrency design ( I invented once ) , and have any non-trivial deviation from the proven designs, they may unknowingly introduce bugs that may not surface for years. So the actual threading usage in any project is always minimal, simple and isolated to a very small number of files.

The fastest systems tend to have nothing shared-mutable, so multi-threading presents zero risk and requires no design. No locking no CAS. Essentially single-threaded.

However, we don’t have the luxury to say “limited experience” in threading. I have a fair amount of concurrency design experience across languages and thread libraries (pthreads, ObjectSpace, c#), using locks+conditional variables+CAS as building blocks, but the c++ thread library used in another team is probably different. I used to say I used boost::thread a lot but it back-fired.

—#99 [c] OO design patterns ——- never required in coding tests. In fact, basically no OO features show up in short coding tests. 90% of short coding tests are about GettingThingsDone, using algorithms and data structures.

Design patterns do show up in QnA interviews but usually not difficult. I usually stick to a few familiar ones — Singleton, Factory, TemplateMethod, ProducerConsumer. I’m no expert with any of these but I feel very few candidates are. I feel most interviewers have a reasonable expectation. I stay away from complex patterns like Visitor and Bridge.

—#1 [c] c++11 —— is not yet widely used. Many financial jobs I applied have old codebases they don’t want to upgrade. Most of the c++11 features we use as developers are optional convenience features, Some features are fundamental (decltype, constexpr …) yet treated as simple convenience features. I feel move semantics and r-value references are fairly deep but these are really advanced features for library writers, not application developers. Beside shared_ptr, C++11 features seldom affect system design. I have “limited project experience using c++11“.

Interviewers often drill into move semantics. If I admit ignorance I could lose. Therefore, I’m actively pursuing the thin->thick->thin learning path.

—#5 [e] Boost —— is not really widely used. 70% of the financial companies I tried don’t use anything beyond shared_ptr. Most of the boost features are considered optional and high-level, rather than fundamental. If I tell them I only used shared_ptr and no other boost library, they will usually judge me on other fronts, without deducting points. I used many boost libraries but only understand shared_ptr better.

Q: Are there job candidates who are strong with some boost feature (beside shared_ptr) but weak on core c++?
A: I have not seen any.

Q: Are there programmers strong on core c++ but unfamiliar with boost?
A: I have seen many

—#4 [c] templates —— another advanced feature primarily for library developers. Really deep and complex. App developers don’t really need this level of wizardry. A few experienced c++ guys told me their teams each has a team member using fancy template meta-programing techniques that no one could understand or maintain. None of my interviewers went very deep on this topic. I have only limited meta-programming experience, but I will focus on 2 common template techniques — CRTP and SFINAE and try to build a good understanding (thin->thick->thin)

—#6 [c] IKM —— is far less important than we thought. I know many people who score very high but fail the tech interview badly. On the other hand, I believe some candidates score mediocre but impress the interviewers when they come on-site.

—#3 [e] linux system programming like sockets —— is relevant to low-latency firms. I think half the c++ finance firms are. Call them infrastructure team, or engineering team, or back-end team. I just happened to apply for too many of this kind. To them, socket knowledge is essential, but to the “mainstream” c++ teams, socket is non-essential. I have “modest socket experience” but could impress some interviewers.

(Actually socket api is not a c/c++ language feature, but a system library. Compared to STL, socket library has narrower usage.)

Messaging is a similar skill like sockets. There are many specific products so we don’t need to be familiar with each one.

InterProcessCommunication  (Shared memory, pipes… ) is a similar “C” skill to sockets but less widely required. I usually say my system uses sockets, database or flat files for IPC, though shared memory is probably faster. I hope interviewers don’t mind that. If there’s some IPC code in their system, it’s likely isolated and encapsulated (even more encapsulated than threading code), so hopefully most developers don’t need to touch it

Memory Manager is another specialized skill just like IPC. Always isolated in some low-level module in a library, and seldom touched. A job spec may require that but actually few people have experience and never a real show stopper.

If a role requires heavy network programming (heavy IPC or messaging development is less common) but we have limited experience, then it can be a show-stopper.

— #99[c] A) instrumentation and B) advanced build tools for memory, dependency etc … are big paper tigers. Can be open-source or commercial. Often useful to GTD but some interviewers ask about these tools to check your real-world experience. 99% of c++programmers have superficial knowledge only because we don’t need to understand the internals of GPS to use it in a car.

Note basic build-chain knowledge is necessary for GTD but relevant “basic” and seldom quizzed.

—————–
These topics are never tested in short coding questions, and seldom in longer coding questions.

What c++ knowledge is valued more highly? See ##20 C++territories for QQ IV

%%GTD xp: 2types@technical impasse#难题

See also post on alpha geeks…
See also post on how fast you figure things out relative to peers
See also ##a few projects technically too challeng` 4me
See also https://bintanvictor.wordpress.com/2017/03/26/google-searchable-softwares/
see also https://bintanvictor.wordpress.com/2017/05/29/transparentsemi-transparentopaque-languages/

tuning? never experienced this challenge in my projects.
NPE? Never really difficult in my perience.

#1 complexity/opacity/lack of google help

eg: understanding a hugely complex system like the Quartz dag and layers
eg: replaying raw data, why multicast works consistently but tcp fails consistently
eg: adding ssl to Guardian. Followed the standard steps but didn’t work. Debugger was not able to reveal anything.
Eg: Quartz dag layers
Eg: Quartz cancelled trade

#2 Intermittent, hard to reproduce
eg: Memory leak is one example, in theory but not in my experience

eg: crashes in GMDS? Not really my problem.

eg: Quartz preferences screen frequently but intermittently fails to remember the setting. Unable to debug into it i.e. opaque.

[17] %%c++IV weaker cf java

https://bintanvictor.wordpress.com/2017/04/02/c-and-java-iv-tend-to-beat-us-in-2-ways-high-end/ shows my self-rating in job interviews for c++ vs java. (For real projects, I think the gap between my c++ and java is slightly smaller.)

I did spend lots of time reading and blogging about c++, not less than java, so

Q: why the persistent gap in my QQ IV performance?

  • –A #1: biggest reason — I feel a disproportionate number of my c++ interviews come from high end teams such as HFT shops. They go slightly lower-level than my java interviews. Overall, java is a slightly less specialist, less elitist, more commodity skill. Imagine if I get lower-level java interviews from the likes of Millennium, HSBC … I feel most (like 80%) of the java jobs in finance are “regular”; for Singapore c++, the percentage is below 50%. See the post on the c++ job offers I received.
    • my c++ interviews have slightly more IDE coding tests than my java interviews
    • If I avoid the high-end jobs, then my batting average will probably increase significantly.
  • –A #2: [QQ] Some of these interviewers basically treat c++ as a wrapper over C. In contrast, Java insulates you in a pure-java world on the Virtual Machine, so you don’t need to deal with the messy “borders” as c# and c++ developers do. If I could avoid these topics, then my c++ low-level tech IV performance is closer to Java performance. A lot of the tough C++ IV questions are about
    • linux, kernel tuning, system calls, OS performance monitoring, …
    • [C] *alloc family of functions, memory leak detectors
    • shared lib, linker, compiler,
    • [C] other command line developer tools … mostly designed for the “system programmer”.
    • [C] sockets, IPC
  • –A: [QQ] significantly simpler in terms of QQ — java as a language, when we ignore the add-on packages.
  • –A #4: cod`IV java^c++: threading is one reason my java coding IV is stronger than c++
  • –A: [QQ] STL containers — is much more complicated than java containers in job interviews, even if we ignore iterators, stl algorithms.
    • I spent more time studying STL than java collections but always failed to impress interviewers.
    • eg: in java container of T is always implicitly container of well-managed pointer  to T
  • –A: [QQ] halos — halos in my “java show”:  threading, collections, GC tuning … which make up for my java weaknesses elsewhere. No such halo in my “c++ show” I guess some people have a halo in templates, memory mgmt, shared_ptr, threading…
  • –A: unable to describe c++ projects.
  • Suggestion: Start from this blog and my books. Focus on a small subset of core topics in c++, /burn through/ the essential literature and develop a first halo —
    1. smart pointers (beyond shared_ptr)
      1. usage in big5
      2. usage in containers
    2. data structures in STL and boost, including c-str life-cycle management excluding the str* functions
    3. traditional big 3(dtor,op=, copier) but not rvr and move-semantic
    4. pbclone^pbref but not return-value-optimization
    5. const
    6. vptr, slicing, dynamic_cast
  • (Note this is all about QQ book knowledge, not coding skill!)
  • suggestion: secondary focus topics —
    1. c++11 threading
    2. heap memory management;
    3. socket tweaking;
    4. interface classes, pure virtual;
    5. design patterns
    6. shared memory
  • suggestion: continue to ignore some of the high complexity low leverage topics such as move semantics; iterators; const-correctedness; singleton; design patterns; operator overload … and many [[effC++]] topics

top geeks – 5 categories

Let’s try to be critical, incisive… It’s also good but not critical to widen the perspective.
–5) instrumentation for GTD. This is the #1 most valuable skill for GTD, not necessarily to move up to leadership.
–7) Some (not “top top”) geeks can quickly pick up enough details of a new “tool” and use it to get things done (often not perfectly). I had this advantage in my youth. I might have it still.
eg: git, IDE, tibrv,
eg: Venkat, Avichal
–8) Some (not top top) geeks have rare knowledge of advanced/obscure topics like concurrency, memory mgmt, templates, elegant SQL joins, arcane language rules…, but the difference here is — the knowledge is needed only for interviews.
eg: IV questions at many HFT
eg: most threading questions
eg: Venkat
eg: [[effC++]]

–9) Some successful geeks have good local system knowledge. See post on Helicopter view.
Prime eg: Yang.

–1) Some top geeks (+ open source heroes) can quickly create a complete non-trivial software, often single-handedly.
* probably the hardest achievement. These are the doers not just thinkers and dreamers.
* productivity is often 100X a regular developer
–2) [G] Some top geeks are experts on google-style algorithm challenges.
* This domain takes at least a few months (possibly years) of practice. Without this mileage, you won’t be there.
* similar to mathematical talent — somewhat innate
–3) [G] Some top geeks can optimize performance in a demanding system. A specialist knowledge.
eg: the Russian Sybase guru in PWM CT
eg: facebook memory allocator?
I feel this skill is overrated. Not much business value and impact in most cases.
–4) Some top geeks are experts at system (including compiler) internals i.e. under the hood + debugging, but not obscure low level details
* can uncover the “why” no one else can. Widely valuable.
** the very deep “why” is sometimes not that critical. In many real projects we don’t need to uncover the why if we can circumvent (find a workaround), including a rewrite
** in rare cases, we have no choice but find the “why”, but if the team doesn’t have expertise, they still would find some inferior solution or just live with the problem.
—-
[G=needed only at largest websites like Google, but many other employers pose these questions too.]