Remember QQ means ‘tough topics not needed for GTD’. A QQ quiz (to some extent, algo quiz too)
- measures your diligence, amount of learning effort you put in beyond your work projects.
- measures your dedication and commitment to self-learning a dry, tough topic. Learning is not only a drudgery, but also a major challenge on a typical job. 90% of the day-to-day challenges involve learning, re-learning, connecting the dots..
- checks for a self-starter vs a passive learner
- measures your self-reliance at learning
- measures how detail-oriented a candidate is
- checks for intellectually laziness
- measures soundness of fundamental concepts underlying your logical “framework”. In many large financial systems there are fundamental design principles and concepts that are .. fairly logical and consistent. Yang was good at grasping the logical, and questioning the illogical.
- measures depth of curiosity and learning
- measures technical communication bandwidth with another developer
I feel my HFT interviews are very picky on low-level kernel or compiler optimizations or network card engineering, but such QQ knowledge is not widely needed.
Don’t feel inferior to them.
- Q: what if a HFT programmer goes to a Facebook interview?
- Q: what if a coding contest champion from Facebook goes to an HFT interview?
- Q: what if these guys go to a tough logic or probability quiz?
Just like my early learning curve in sockets, Dynamic Programming and swing, I have yet to achieve a breakthrough in these topics, So there are too many topics and I don’t know what to focus on.
It’s important not to exaggerate your expertise in these areas. Once interviewers find out your exaggeration, subconscious they would discount other parts of your resume.
- c++ lock-free — “Used in my project but not written by me”
- Shared mem
- Multiple inheritance
- Pyton multiprocessing
I recently used multicast for a while and I see it as yet another example of the same pattern — technical interviewers care about deep theoretical knowledge not practical skills.
Many new developers don’t know multicast protocol uses special IP addresses. This is practical knowledge required on my job, but not asked by interviewers.
Unlike TCP, there’s not a “server” or a “client” in a multicast set-up. This is practical knowledge in my project but not asked by interviewers.
When I receive no data from a multicast channel, it’s not obvious whether nobody is sending or I have no connectivity. (In contrast, with TCP, you get connection error if there’s no connectivity. See tcp: detect wire unplugged.) This is practical knowledge, but never asked by interviewers.
I never receive a partial message by multicast, but I always receive partial message by TCP when the message is a huge file. This is reality in my project, but never asked by any interviewer.
So what do interviewers focus on?
- packet loss — UDP (including multicast) lacks delivery guarantee. This is a real issue for system design, but I seldom notice it.
- higher efficiency than TCP — I don’t notice it, though it’s a true.
- socket buffer overflow — should never happen in TCP but could happen in UDP including multiast. This knowledge is not needed in my project.
- flow control — TCP receiver can notify sender to reduce sending speed. This knowledge is not needed in many projects.
- non-blocking send/receive — not needed in any project.
So what can we do? Study beyond what’s needed in the project. (The practical skills used is only 10% of the interview requirements.) Otherwise, even after 2 years using multicast in very project, I would still look like as a novice to an interviewer.
Without the job interviews, it’s hard to know what theoretical details are required. I feel a multicast project is a valuable starting point to get me started. I can truthfully mention multicast in my resume. Then I need to attend interviews and study the theoretical topics.
In 2017 I interviewed with
- * Pimco
- * BGC partners
- * ICE
- * TradeWeb
- Thesys (A trading software vendor)
- —-investment banks:
- * BAML
- * MS
- Wells Fargo
I now have a bias against investment banks. Wells is the most recent and most typical ibank interview:
- 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.
- They demand relevant domain knowledge and domain experience as a prerequisite.
- They have a long list of topics and they hope to find someone who scores well in most of them.
- 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.
- 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.
I feel the probability and brain teaser questions are less strategic.
- 😦 They are less widely used
- 😦 lower accu
- 🙂 no churn
My blog has many probability question more challenging than those in tech interviews. I think I don’t need to spend too much time on these.
Am not targeting quant job interviews which require these more.
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
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
** 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
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.
GTD skill – debugging
GTD skill – tools
IV – performance profiling, tuning
IV – algo, data structure, threading
IV – prog. language details
IV – low-level or in-depth knowledge
IV – design skills including OO and agile best practices
(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
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
All of these jobs require more than 90% programming.
Barclays (Neresh) vol fitter
— less heavy focus
pimco bond position overnight risk
Citi Changi equity derivative
MS IRD trading desk team
Background – older developers often lament that generations of tech churn threaten our marketability/survival and devalues our expertise on an old generation of technology.
Key is the job interview. Think about the categories of tech questions. Some categories are immune to the churn… If you invest months (years? impractical) preparing for these questions, your investments may, counter-intuitively, endure. Here are some categories —
#1a) Algo + data structure? Yes. The primary focus of Top tech firm like FB, google, MS, Amazon. However, in coding tests they also need working code, therefore you need substantial coding experience with
** STL (or collections) +
** strings — non-trivial
#1b) algo quizzes — dense recursion/loops (eg quicksort). Think fast and make it work. Hardcore coding ability. I think you don’t even need STL for this.
#2) Threading (only c/c#/java)? Not really un-changing. They do ask java thread pools new features.
** threading algorithms using standard constructs? Yes. often among the toughest IV questions.
OO principles as implemented in a specific language? Yes
Socket? not sure
Design patterns? No. a fad.
As stated in https://bintanvictor.wordpress.com/2010/08/13/vague-vs-normal-vs-specific-answers-in-nontech-interviews/, during non-tech interviews, stories are a good way to organize your thoughts, and make yourself memorable.
Gayle McDowell pointed out that your story needs to
- explain why it was done that way
- reflect on you, not your team
- understandable and substantial
- Also be prepared to say how you would do it differently
–To prove a _team_player_ —
- These aren’t stories but … voted most helpful colleague in Zed;
- knowledge sharing;
- hands-on guidance over freshers. In ICE team, all four new hires come to me for help.
- one of the most gregarious guys on the floor, making friends across department boundaries.
–To prove “help those in need” —
rated substantially-exceed by all the freshers I helped, mostly Indian freshers; Never turned away a help seeker
–To prove constructiveness in conflict —
presenting alternative designs to senior managers
–To prove knowledge sharing —
–To prove “can work with difficult colleagues” —
Chih Hao who likes to criticize my code ..
–To prove under-pressure — biggest release of 2009
–To prove personal sacrifice —
My architect job interviews seldom ask me to describe design patterns. They don't seem interested in textbook knowledge. (I feel many people can describe a lot of patterns, but it tells me nothing about their competency at using them.)
Some asked me to describe my personal contribution to my projects, my design challenges — candidate is free to mention design patterns.
The more difficult technical questions are software problem solving + low-level component design, which requires more skills than a junior developer.
See also “halo”.
xp: These areas have received disproportional attention from interviewers. ranked.
Study iterator, comparator, hashCode()
Study load factor and capacity — asked by multiple financial giants
* outer join@@ not much depth
study join order, subquery
* interface, abstract@@ not much depth
* GC including finalize()
study generational GC, mem leak and jvm profilers
* servlet life cycle
* singleton, mvc, dao,
* vector ^ arraylist, or hashtable^hashmap
* list 1.5 features