how to strengthen my c++ skills for IV (+GTD). cf the c++learnMisc category
Every language has poorly understood syntax rules, but only in c++ these became fashionable, and halos in job interviews !
Avoid spending too much time on this list…. These c++ topics appeared non-trivial (perhaps daunting, intimidating) for years, until I started cracking the QnA interviews. Then I realized in-depth expertise isn’t required, so Venkat can impress interviewers with his Wikipedia knowledge. In contrast, DQH would run complicated coding experiments to build insights.
Every single HFT interview question is about low-latency. Furthermore, the ibank algo-trading interviews revolve around the same clusters.
Even though I’m not aiming for HFT jobs, these topics are still very relevant to ibank and the “3rd type” of c++ shops.
— Themes are less visible in these clusters:
— other HFT topics are dispersed/scattered, not showing any strong central theme
See blogpost on paper tigers. Deepak asked me to compare the QQ questions in java vs c++.
I feel c++ QQ common IV topics outnumber java by 100%.
I feel someone like Qihao can rise to the challenge.
I figured out long ago that java swing is a distinct skill, distinct from mainstream java.
Now I feel HFT c++ is also such a skill — distinct from mainstream c++. Interviewers tend to ask questions (almost) irrelevant to mainstream c++. Shanyou said focus is on system-level not application-level. I feel superficial knowledge is often enough.
–These topics are relevant to mainstream c++ but more relevant to HFT
90% of the hardest coding questions use simple data structures. Some of these algos are
–Linked list
Brent — check for loop in linked list
–binary tree
Morris — Morris in-order walk]O(N) #O(1)space
–string
–array
All QQ topics, not related to GTD or coding IV
–socket programming interviews
Q: Which one to let go, given I have limited O2/laser/bandwidth and mental capacity?
How about pure algo?
Combine with https://bintanvictor.wordpress.com/wp-admin/post.php?post=24064&action=edit ? no need… Don’t spend too much time! I keep this list only as motivation and reward, but I don’t want a long list. I want heavy-hitters only, non-exhaustive.
Note “Take-up/Conquest” mean … I now feel as competent as my interviewers on that topic.
Note QQ means … hard topics unneeded in any project.
[3=top-33 favorite topics among ibank interviewers]
[d=reached some depth of understanding]
I didn’t know these were important when I was reading on my own.
[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.
For each topic, I want to classify it as core or ecosystem. Besides, I want to gauge its market value in terms of IV (not GTD), depth with moat.
[e=c++ecosystem topics]
[c=core c++topics]
— #AA [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 parallel processing presents zero risk and requires no design. No locking no CAS. Essentially single threaded mode.
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.
[e] threading library support? not so standardized as in java. pthreads is standard but not widely used in projects and not a common knowledge
[c] threading support in c++11? Not widely used or widely quizzed.
This domain does have depth with moat 🙂 but not as popular as rvr.
— #AAA [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.
This topic is an interview favorite, have market value, depth with moat.
— #A [c] templates including TMP —— 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)
This topic is popular, with real depth and moat.
— #C [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
This topic is not so popular, never quizzed in depth.
—#D+ [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.
Not so popular in IV. Not much depth with moat
—#B [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
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.
— #B+ [e] Memory Management ——- another specialized skill just like IPC.
Deeper bookish knowledge into malloc/new, custom allocator, buffer management (DeepakCM)…
Such code is 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.
I feel this topic is gaining popularity perhaps due to c++ competitive advantage. Had depth with moat.
— #D [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.
No depth no moat. Not so popular. 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.
— #F [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
NO coding interviews — The scope here is the QQ topics i.e. tough IV topics not needed in GTD.
[1] “+” means Interviewers ask tons of question in this domain, more than it deserves. Its weight in the total score is lower than the share of questions would indicate.
[2] “70%/core” means this IV topic is 70% theoretical; core c++. The more theoretical, the more you need to read and summarize, rather than “GTD by any means”
[O] means HFT style optimization-heavy interviews. Not needed in regular jobs
swap-related tricks? advanced and seldom quizzed
| unsorted topics | theoretical Q | weight | share of Q [1] | ||
| T1 | big 4 | 70% / core | 9% | + | |
| T1 | vptr-related: dynamic cast, interface classes, pure virtual |
100% / core | 9% | + | |
| T1 | virtual dtor | 100% / core | 2% | + | |
| T1 | inheritance: MI, PI, hiding, overload^override, casting, protection |
60% / core | 5% | ||
| T2 | ptr as field; return ptr | 20% / core | N.A. | ||
| no tier | OO low level design #swap tricks, class hierarchy.. |
60% / add-on | 5% | – hard to ask | |
| T1 | stack,heap,static …variables | 50% / core | 3% | ||
| T1 | pbclone, pbref, ref params | 50% / core | 4% | ||
| T1 | object allocation, life time vs variable declaration |
0 /core | N.A. | ||
| tier 2 | STL: containers, | 20% / add-on | 14% | – asked more in coding IV | |
| tier 2 | array | 0 / core | N.A. | ||
| T2 | malloc; heap prohibit; leak prevention/detection | 40% / core | 7% | – | |
| T1 | const | 90% / core | 2% | ||
| T3 [O] | DAM allocation efficiency | 100% / core | 1% | ||
| T2 | threads | 80% / add-on | 8% | – | |
| T1 | smart ptr and variations | 30% | 6% | ||
| no tier | c++11: move, rvr | 90% / core | 4% | ||
| T2[O] | sockets: a lot of c++jobs I applied happen to need it |
0 / add-on | 10% | ||
| T3[O] | cpu cache optimization | 100% / core | 1% | ||
| T2[O] | inline and code-size bloat | 100% / core | 1% | ||
| T2[O] | field layout | 90% | 1% | ||
| T2 | c^c++ | 90% / core | 2% | ||
| T2 | static/shared library | 50% / core | 2% | ||
| — minor topics — | 4% | ||||
| boost besides smart ptr | 10% / add-on | ||||
| container of polymorphic type #interface | 50% | ||||
| templates | 80% | ||||
| singleton, factory | 100% | ||||
| pimpl | 90% | ||||
| other design patterns | 100% | ||||
| tier 2 | exception safety | 90% / core | |||
| T1 | RAII | 50% / core | – | ||
There are many sub-topics but in my small sample of interviews, the following sub-topics have received disproportionate attention:
Did I blog about this before?
There are dozens of sub-topics but in my small sample of interviews, the following sub-topics have received disproportionate attention:
There are dozens of sub-topics but in my small sample of interviews, the following sub-topics have received disproportionate attention:
Background — The QQ/ZZ framework was first introduced in this post on c++ learning topics
Only c/c++ positions need socket knowledge. However, my perl/py/java experience with socket API is still relevant.
Socket is a low-level subject. Socket tough topics feel not as complex as concurrency, algorithms, probabilities, OO design, … Yet some QQ questions are so in-depth they remind me of java threading.
Interview is mostly knowledge test; but to do well in real projects, you probably need experience.
Coding practice? no need. Just read and blog.
Socket knowledge is seldom the #1 selection criteria for a given position, but could be #3. (In contrast, concurrency or algorithm skill could be #1.)
Other things they may not ask but I could demonstrate:
We often call these “obscure details”. These are a small subset of a large universe, the universe of many, many of details at the same level of importance. So we can’t possibly remember them all 😦
Surprisingly, interviewers show certain patterns when picking which technicality to ask. Perhaps these “quizzed” items are special and not at the same level as the thousands of other obscure details??
These topics are typical of QQ i.e. tough topics for IV only, not tough topics for GTD.
* STL data structures
* inheritance, overriding
* ctor/dtor
* virtual
* big 4
* pointers and references
* strings
* input/output
C++ concurrency learning curve has lower /leverage/ higher effort.
* well-established — Java is designed with concurrency at its core so its memory model is mature and sound. There are a few very well-respected books on java concurrency (and some secondary books). As a result, concurrency best practices are more established in java than arguably any other language as of 2017.
* templates — Many concurrency constructs use templates with possibly specializations.
* C — Java developers never need to deal with the system-level concurrency library (invariably in C), the c++ developer may need to descend to the C level.
* multiple libraries — See post on c++ concurrency libraries. https://bintanvictor.wordpress.com/2017/04/05/common-cconcurrency-libraries/
* Low-level — C++ is a lower-level language than java.
** The concurrency classes must deal with the big 4.
** Memory management also complicate concurrency.
** Not only heap objects, but primitives on the stack are also accessible from multiple threads thanks to pointers.
** The atomic class templates are also more low-level than java’s, and much harder to get right.
* There are many mutex constructs.
https://lumian2015.github.io/lockFreeProgramming/lock-free-vs-spin-lock.html
https://lumian2015.github.io/lockFreeProgramming/lock-free-stack.html
https://lumian2015.github.io/lockFreeProgramming/aba-problem.html
Not written by a foremost expert, but I like the simplicity.
I used to feel I have so much absorption capacity, but now I feel in my finite career I can’t really master and remember all the tough c++ topics.
Practical solution — Classify each difficult c++topic into one of
Q: Is there a tough topic in both QQ and ZZ? I doubt it.
[p=paper tiger. ]
Focus here is zbs not IV.
I told XR that a few coding interviews have brought my c++ GTD by half a point. I felt it was still at 5 as of 2015. The Mac job didn’t bring it higher, but the ICE job did. As of late 2017, it’s at 6. It’s feasible to bring it up to 7 —
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?
For coding quiz, we need to know quite a few details of these data types —
c-string
std::string
vector
shared_ptr
raw array
Here are the subset of C++11 features I understand as significant. Some significant c++11 features I don’t appreciate, such as lambda.
#1 move semantics
– std::move and forward
#2 Lib: smart pointers
– make_shared() etc
#3 Lib: thread library
– atomic<int>
http://solarianprogrammer.com/2011/12/16/cpp-11-thread-tutorial/
#4 type traits
Update — 7 clusters@HFT-c++IV questions has valuable insight. You cannot gain these insights without attending (and preparing/reviewing) a lot of real c++ interviews.
Hi Yang Bo
You probably have more experience programming c++. But to answer your question about interview topics, my c++ interviews tend to cluster around
To a lesser extent, these topics are also repeatedly quizzed —
STL, boost
threads
c-string
array-pointer integration (A major strength in C)
dynamic cast, but not RTTI or vptrcustomized operator-new and operator-delete
IPC
sockets
RAII?
const
–These features are less used
unioin
tricky operator overload
namespaces
conversions
template class development
—–
Now we know that on Wall Street, C++ OO designs are primitive compared to Java OO designs
keep learning 活到老学到老 