ibank tech IV: naive,arrogant..

In 2017 I interviewed with

  • * Pimco
  • Blomberg
  • * BGC partners
  • * ICE
  • * TradeWeb
  • Thesys (A trading software vendor)
  • Citadel
  • —-investment banks:
  • * BAML
  • * MS
  • Wells Fargo
  • GS
  • UBS

I now have a bias against investment banks. Wells is the most recent and most typical ibank interview:

  1. wishful thinking that if they are lucky to find a candidate who has used (for example) non-blocking-IO or shared-memory, he will be able to create such a system and make it WORK. I think in reality, many senior developers who have used such a technology professionally for a few years won’t be able to overcome the many technical challenges. I know from experience that we all struggle with a technology before we understand its limitations and pitfalls and figure out how to navigate around them. If you use an existing codebase that was fine-tuned years ago, then you have missed the “struggle” phase. You have to find opportunities to struggle with it (am trying now) to learn it. No pain no gain.
  2. They demand relevant domain knowledge and domain experience as a prerequisite.
  3. They have a long list of topics and they hope to find someone who scores well in most of them.
  4. Focus on in-depth, precise understanding of a few “cornerstone” topics such as threading memory model, and data structures. Such knowledge is very seldom needed in projects. We gain that knowledge by reading and interviewing and use it for interview only.
  5. For all other topics, they have a focus on textbook knowledge, slightly beyond skin-deep. These investment banks seem to believe if a candidate has such a knowledge, then he has experienced using it (or can learn it fast). Naïve thinking.

The non-banks (particularly Pimco, Bloomberg, BGC) are not “smarter interviewers”, but their focus is slightly different. They don’t need domain knowledge or a super long list of topics to rate a candidate. They don’t look for skin-deep “insight”. Many use coding tests, more often on a compiler than on paper.

Many non-banks (BGC, TradeWeb) also have the same high requirement on the same cornerstone topics above. Others focus on C++/java language details including low-level and tricky topics, more than the ibank interviews. My GS interview is like this.

Advertisements

some low level QQ questions will beat me, but remain confident during IV

See https://bintanvictor.wordpress.com/2017/02/02/c-and-java-iv-tend-to-beat-us-in-2-ways-high-end/. Inevitably, some questions will beat us, perhaps in terms of algo challenge, but many recent questions beat us in terms of in-depth knowledge. So how do you react in an interview after you are beaten on some questions?

Look at this linked-in endorsement — … has an solid attention to detail. He relentlessly pursues the most efficient and sensible means to developing software applications. He can lead a team of developers locally and globally, be a team advocate, a problem-solver, and a top-notch software designer. I often relied on him to explain and help detail some of the most complex logical components.

Such a person may very well fail some of those interview questions. He needs to be self-confident about his GTD skills like design, delivery…

coding IV – favored by the smartest companies

XR,

I see a few categories of IV questions:

1a) fundamentals — Some Wall St (also in Asia) tough interviews like deep, low-level (not obscure) topics like threading, memory, vtbl, RB-tree ..

1b) lang — Some (IMO mediocre) interviewers (like programming language lawyers) focus on language details unrelated to 1a)
2) Some (IMO mediocre) interviewers like architecture or high level design questions (excluding algo designs) like OO rules and patterns but I feel these are not so tough.

3) algo — Some tough interviews focus on algo problem solving in pseudo-code. See http://bigblog.tanbin.com/2007/09/google-interviews-apply-comp-science.html. I got these at Google and Facebook. Some quants get these too.

4) compiler coding question — is another tough interview type, be it take-home, onsite or webex.
With some exceptions (like easy coding questions), each of these skills is somewhat “ivory tower” i.e. removed from everyday reality, often unneeded in commercial projects. However these skills (including coding) are heavily tested by the smartest employers, the most respected companies including Google, Facebook, Microsoft… You and I may feel like the little boy in “emperor’s new dress”, but these smart guys can’t all be wrong.
I will again predict that coding questions would grow more popular as the logistic cost is driven down progressively.
Candidate screening is tough, time consuming and, to some extent, hit-and-miss. With all of these screening strategies, the new hire still can fail on TECHNICAL ground. Perhaps she/he lacks some practical skills — Code reading; debugging using logs; automation scripts; tool knowledge (like version control, text search/replace tools, build tools, and many linux commands)
Needless to say, new hire more often fail on non-technical ground like communication and attitude — another topic altogether.

In terms of real difficulty, toughest comp science problems revolve around algorithm and data structures, often without optimal solutions. Algo interview questions are the mainstay at big tech firms, but not on Wall St. Some say “Practice 6 months”. Second toughest would be coding questions —
* Often there’s too little time given
* Sometimes interviewer didn’t like our style but onsite coding tends to focus on substance rather than style.

Tan bin

P.S. I had webex style coding interviews with 1) ICE Feb 2011, 2) Barclays (swing), 3) Thomson Reuters, 4) Bloomberg

P.S. I tend to have more success with algo interviews and onsite coding than take-home coding. See blog posts.. (
http://tigertanbin2.blogspot.com/2015/05/sticky-weakness-revealed-by-interviews-c.html
http://tigertanbinpripri.blogspot.com/2015/03/high-end-developer-interviews-tend-to.html
)

probability quizzes for tech IV

I think it pays to invest in this domain.

Q: Why the hell do interviewers ask those (mostly discrete) probability questions?

I get these questions all the time. Similar to brain teasers and abstract aptitude test:

  • Well-defined, easy to understand
  • Completely unrelated to the tech job
  • somewhat crack-proof, so (as interviewers would think) more useful as an objective aptitude test

A: I can only guess it’s related to IQ. See post on Facebook regex interview

reach next level ] tech IV performance

See also the similar pripri post about “beat us”.

I really don’t care that much about zbs needed in a project:
* the so-called architecture expertise is overrated and overhyped. See my post on
** GTD
** software architect vs enterprise architect
* the optimization expertise is … similar

Next level requires .. more knowledge. See post on “Yaakov”
Next level requires .. more practice with Facebook algo questions.
Next level requires .. IDE coding against simple problems like codility.
Next level requires .. more mileage with hands-on dev.
Next level requires .. more “best practices” like google style guide

overvalue ^ undervalued in tech IV – random picks

–overvalued – 10 items unranked:
problem solving with comp science constructs — mostly algos
fast coding
code quality – in those take-home coding tests
corner cases
arch
OO design theories, principles
–undervalued practical skills:
stackoverflow type of know-how, including syntax details. These aren’t quizzed in high-end interviews.
tools including IDEs
[T] bug hunting
[T] large code base reading
[T] reading lots of documentation of various quality to figure out why things not working
[T = hard to test in IV]

c++IV: importance: knowledge imt coding xp

1) Many hard-core tech interviewers (Yaakov, Jump, 3Arrows, Bbg, nQuants …) often asked me to explain a language feature, then drill in to see if I really do understand the key ideas, including the rationale, motivation and history. This knowledge is believe to … /separate the wheat from the chaff/

This knowledge can’t be acquired simply by coding. In fact, a productive coder often lacks such knowledge since it’s usually unnecessary theoretical knowledge.

2) West Coast always drills in on algo (+ data structure). No way to pick up this skill in projects…

1+2 —> many interviewers truly believe a deep thinker will always learn faster and design better.

low-hanging? perishable? niche? (after 2nd slow job search)

(See also blog post http://bigblog.tanbin.com/2013/12/strategic5y-investment-in-tech-xx-again.html, )

Evaluation in terms of long term job security, demand, job search, job interview, salary level

^^ core c#
^ python? growing demand; low-hanging fruit; might open many golden gates at baml and jpm
^ FIX? low churn. Hard to self-learn
– socket? frequently quizzed, low churn
– wcf
v wpf? not my chosen direction at the moment. Too big a domain.
– linux/c++ optimization? too niche
^ option math, stoch? often asked in-depth, but few roles in SG
– fixed income math? not used on the buy-side
– risk mgmt math? stable demand
v quant strategy? vague, dubious domain, apparently zero role in SG