- delivery on projects
- local sys know-how
- pure algo
- portable GTD and zbs not needed for IV
- ECT+syntax — big room for improvement for timed IDE tests only
- Best practices — room for improvement for weekend IDE tests only
- final, override
- delete — overloaded
- –functions, not keywords
- is_base_of, is_pointer
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.
- [u] avoid “virtual” for latency
- CPU cache management
- translation lookaside buffer
- [P] kernel bypass
- [uP] socket tuning
- [P] memory and socket performance monitoring
- shared memory
- [u] placement new and custom allocator
- system calls
- [u] in-lining
- [u = used in my systems to some extent]
- [P = no programming, pure system knowledge]
–These topics are relevant to mainstream c++ but more relevant to HFT
- IPC mutex
- reference counting
All QQ topics, not related to GTD or coding IV
- Throwing dtor
- how to avoid virtual functions (use enum?); CRTP
- IPC mutex; synchronization in shared mem
- Delete a pointer to base, but the actual object is a derived without virtual dtor. See my post https://bintanvictor.wordpress.com/2015/04/21/deleting-base-class-ptr-non-virt-dtor
- casting “this” pointer. See https://bintanvictor.wordpress.com/2017/11/15/crtp-1st-lesson/
- memory: placement new and how to delete
- why division by zero is not an exception
- debug build modifying behavior
- memory: q(delete this)
- SFINAE — I was asked in … 2 MS teams?
–socket programming interviews
- ##tcp tuning params
- non-blocking socket calls
- buffer full
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.
- [s] what debuggers and memory leak detectors are you familiar with?
- [a] singleton, factory, pimpl and other design patterns
- [s] c++ regex
- [s] stream I/O and manipulators
- [A] CRPP, SFINAE — real tigers. I got asked about these around 5 times, sometimes in-depth
- —sockets # many more paper tigers to be listed
- udp, multicast, select()
- [s] socket buffers
- [a] byte alignment
- TCP flow control
- TCP handshake and disconnect
- ack numbers
- partial send
- close() vs shutdown()
- — STL # many more paper tigers to be listed
- [s] STL binders
- [s] STL allocators
- adapters for containers, iterators and functors
- [a] iterator invalidation rules
- [s] how is deque different from a vector
- —concurrency # many more paper tigers to be listed
- [A] atomic types
- pthread functions
- [A] IPC mutex
- mutex in shared memory
- recursive lock
- read-write lock
- what if a thread dies while holding a lock?
- [s] RAII scoped lock
- — multi-file build
- forward class declarations (as required in pimpl) and their limitations
- [s] C/C++ integration, extern-C — heavily quizzed, but no in-depth
- [s] what C features are not supported by c++ compiler
- circular dependency between libraries — confusing. real tigers
- [s] shared lib vs static lib
- —integration and data exchange
- [A] shared memory
- [A] CORBA, RPC
- [a] serialization in compact wire format — only primitive data types!
- [s] OS system calls vs std library (glibc) — sounds daunting to most developers
- catch by ref or by value or by pointer?
- [s] exception guarantees
- [s] stack unwinding due to exception
- throwing destructors — various questions
- which part of memory do static data members go? How about file scope static variables? How about global variables
- [s] preventing heap/stack allocation of my class
- [s] custom new/delete, set_new_handler()
- [s] intrusive smart ptr, weak_ptr
- [s] ref counting
- custom deleter in shared_ptr
- [s] reinterpret_cast # mostly on pointers
- custom allocators
- [A] free list in the free store
- what if you call delete on a pointer that’s created by array-new?
- placement new
- out-of-memory in operator-new
- [A] multiple inheritance
- [s] virtual inheritance… which base class ctor gets called first? See https://isocpp.org/wiki/faq/multiple-inheritance#mi-vi-ctor-order
- [a] slicing problem
- [a] private inheritance
- [s] pure virtual
- —other low level topics
- [s] setjmp, jmp_buf… See the dedicated blog post jmp_buf/setjmp() basics for IV #ANSI-C
- [s] cpu cache levels
- [s] translation lookaside buffer
- [s] what data structures are cache-friendly?
- [a] memcpy, memset
- [s] ++myItr vs myItr++ how are they implemented differently?
- —other language features
- [s] RAII
- [s] operator-overload
- [A] template specialization — part of the STL fabric but largely transparent
- [s] ptr to member (function) — seldom used outside library code. I tried the syntax in my binary tree serializer
- [A] std::forward() std::move(), rvalue-ref
- const and constexp
- [a] lambda with capture
- [a] double-pointer .. why do you need it?
- [s == shallow book knowledge is enough]
- [a == actually not that deep, IMHO]
- [A == actually deep topic]
What to let go, given I have limited O2/laser/bandwidth and mental capacity?
- give up BP — biggest room for improvement but least hope
- give up codility style — Just get other friends to help me. See codility: ignore overflow, bigO
- give up algo — already decent. diminishing return. Smaller room for improvement? But practice on some small algo questions can significantly improve my ECT.
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.
- RAII+swap(), the killer combination, in the sports sense of “kill”
-  sfinae
-  crtp
- covariant return type and virtual ctor i.e. clone()
- static_assert? Non-trivial for those uninitialized with TMP
-  alternative to virtual functions
- singleton thread-safety
-  heap memory mgmt strategies
- [3d] make_shared benefits and limitations (Scott Meyers)
-  shared_ptr concurrency
- [d] Common mistakes involving shared_ptr
- unique_ptr ownership transfer
- factory returning smart pointers
- [d] emplace employing perfect forwarding
-  just when std::move() is needed
- std::move usage (outside big4)
- [d] rval objects vs rvr
-  placement new
-  MI using Abstract Base Classes
-  TCP congestion control
- TCP OOS control
- — topics to be conquered
-  TCP resend
- TCP buffer sizing
[3=top-33 favorite topics among ibank interviewers]
[d=reached some depth of understanding]
- –ranked by .. surprise and value to my learning
- lvr/rvr references vs pointers
- *_cast operators, conversions including std::move
- TMP – CRTP, SFINAE, type traits
- multiple inheritance
- placement new
- c/c++ integration
- weak_ptr? small halo
- ctor/dtor sequence esp. in virtual inheritance
- public api of any smart ptr class
- — Now the rarely-quizzed topics:
- 😦 boost threading and other boost
- 😦 STL iterators and algorithms
- 😦 pthreads
- 😦 exception guarantees
- 😦 allocators
I didn’t know these were important when I was reading on my own.
- socket details
- tcp handling of OOS
- tcp flow control, AWS
- smart ptr api and control-block manipulation
- make_shared details
- auto_ptr vs unique_ptr
- multiple inheritance, casting
- template techniques
- exception catching/re-throwing
- q[ … ] variadic template params
- inline: impact on performance
- throwing dtor
- details of pure virtual
- shared ptr in container
- unique ptr
- how is ref count maintained
- thread safety
- skeleton of a smart ptr
Other things they may not ask but I could demonstrate:
- weak ptr
- pitfalls like “starting a new club”
- use as field, esp in a RAII host class
- const ptr to const object?
- factory always returns (smart?) pointers
NO coding interviews — The scope here is the QQ topics i.e. tough IV topics not needed in GTD.
 “+” 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.
 “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 |
|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,
|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
|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||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%|
|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:
- MI and virtual inheritance
- pure virtual
- –other items
- private inheritance? no
- slicing? no
- hiding? no
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:
- vector sizing, resizing
- shared_ptr usage in STL
- iterator invalidation
- std::find(), std::sort()
- pair and make_pair
There are dozens of sub-topics but in my small sample of interviews, the following sub-topics have received disproportionate attention:
- blocking vs non-blocking
- add basic reliability over UDP (many blog posts); how is TCP transmission control implemented
- accept() + threading
- select (or epoll) on multiple sockets
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.)
- [ZZ] tweaking
- [ZZ] exception handling in practice
- —-Above topics are still worth studying to some extent—–
- [QQ] tuning
- [QQ] buffer management
We often call these “obscure details”. At the same level they are a small subset of a large amount of details, so we can’t possibly remember them all. Surprisingly, interviewers show certain patterns when picking which technicality to ask. Perhaps these “special” items aren’t 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.
- archetypical: which socket syscalls are blocking and when
- some of the hundreds of g++ options?
- hash table theoretical details? too theoretical to be part of this discussion
- select() syscall
t_ivTechnicality is the tag
* STL data structures
* inheritance, overriding
* big 4
* pointers and references
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.
I used to feel I have so much learning(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
- QQ: high impact on QnA interview, probably the only type of high-leverage tough topic. Largely textbook knowledge. As such I’m basically confident I can learn all the basics on my own (perhaps slower than Venkat), provided I know the topics.
- including “coding questions” designed really for knowledge test, rather than algorithm thinking
- eg: HFT, Venkat…
- high impact on algo coding IV? No such topic. These coding IV are not about knowledge in tough topics!
- ZZ: high impact on GTD zbs — inevitably Low leverage during job hunt
- 00: no high impact on anything
Q: Is there a tough topic in both QQ and ZZ? I don’t know any.
I think 00 will be the biggest category:
-  template wizardry;
-  template specialization
-  MI;
-  operator overloading;
-  pthread
- [QQ] move semantics
- [QQ] [p] boost common lib
- [QQ] optimization tricks. Remember MIAX and SCB IV by Dmitry
- [QQ] [p] singleton implementation — not really tough
- [QQ] pimpl — not really tough
- [QQ] op-new/malloc (interacting with ctor)
- [QQ] memory layout
- [QQ] [p] struct alignment
- [QQ] specific threading constructs
- [QQ] smart ptr details
- [QQ] ptr as a field
- [QQ] implement auto_ptr or ref-counting string
- [QQ] [p] UDP —
- [QQ] [p] multicast
- [QQ] select()
- [ZZ] IDE set-up
- [ZZ] compiler/linker/makefile details
- [ZZ] debuggers
- [ZZ] crash analysis, like segmentation fault
- [ZZ] c^c++:SAME debugging/tracing/instrumentation skills #ZZ
[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 —
- reading code
- linker, compiler
- basic threading
- basic templates? LG2
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. 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++ 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, …
- shared lib, linker, …
- [C] sockets,
- [C] IPC
- [C] *alloc function, memory leak detectors
- [C] other command line developer tools … mostly designed for the “system programmer”.
- –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 —
- smart pointers (beyond shared_ptr)
- usage in big5
- usage in containers
- data structures in STL and boost, including c-str life-cycle management excluding the str* functions
- traditional big 3(dtor,op=, copier) but not rvr and move-semantic
- pbclone^pbref but not return-value-optimization
- vptr, slicing, dynamic_cast
- smart pointers (beyond shared_ptr)
- (Note this is all about QQ book knowledge, not coding skill!)
- suggestion: secondary focus topics —
- c++11 threading
- heap memory management;
- socket tweaking;
- interface classes, pure virtual;
- design patterns
- 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
- see recoll -> c++Q&A.txt
- [ZZ] try out debug tools in the gdb book? LG
- [ZZ] experiment with sample code in [[fin instrument pricing using c++]]
- [ZZ] proj: valgrind (linux) – get hands-on experience. Might take too much time to get it working
- problem – test if a linked list has cycles
- problem: all permutations of 0 or more of abcde
- problem: write skeleton c++ code for ref counted string or auto_ptr
- problem: test if a given container is in ascending order
- [ZZ means … see https://bintanvictor.wordpress.com/2017/02/14/low-leverage-ctopics/]
A: ##10 basic programm`constructs for timed c++ cod`IV — focus, direction for IV preperation
A: experience reading STL errors
A: [[safe c++]]
For coding quiz, we need to know quite a few details of these data types —
You probably have more experience programming c++. But to answer your question about interview topics, my c++ interviews tend to cluster around
- * big 3 — dtor, assignment, copy ctor, “virtual ctor”
- * vtbl, vptr, dynamic_cast, (pure) virtual functions
- * smart pointers including auto and shared ptr
- * pass by value vs pass by reference
- * string — only in coding tests. Essential knowledge and internal implementation of strings. (In my java interviews, the most scrutinized data structures are hashmap and arrayList.)
- ** conversion to/from c string
- ** standard str functions in C
- ** when to allocate/deallocate the array of char, esp. in the big3
- ** functions passing/returning strings in and out;
- * thread
- ** creation, mutex, scoped lock, RAII,
- ** implementation of read/write lock and recursive lock
- ** popular implementations of thread libraries, their differences, idiosyncrasies… — practical experience with win32, posix and linux thread libraries.
- * data structures
- ** stl containers, algorithms, big O
- ** functors, binary functors, comparison functors
- ** internals of linked lists
- ** sorting, redblack tree
- ** (non-STL) hash containers
- ** home-grown simple containers
- * memory management
- ** new/delete, malloc/free. c-string is a favorite example among interviewers.
- ** exception handling during allocation
- ** array-new, placement-new
- ** memory leak detection
To a lesser extent, these topics are also repeatedly quizzed —
- * operator overloading — pre/postfix, operator <<
- * initializer list
- * const field
- * slicing problem
- * reference counting — used in string and smart pointers etc
- * double pointers
- * private/protected inheritance
- * abstract classes
- * exception class hierarchy
- * exception catch by reference/value
- * efficiency
- ** C-style string and string functions
- ** enums (Miami, Tower…)
- ** avoid overhead of virtual functions