highest leverage: work^c++4beatFronts

  1. delivery on projects
  2. local sys know-how
  3. pure algo
  4. QQ
  5. –LG2
  6. portable GTD and zbs not needed for IV
  7. ECT+syntax — big room for improvement for timed IDE tests only
  8. Best practices — room for improvement for weekend IDE tests only

## HFT c++knowhow is distinct like .. swing

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.

  1. [u] avoid “virtual” for latency
  2. CPU cache management
  3. translation lookaside buffer
  4. [P] kernel bypass
  5. [uP] socket tuning
  6. [P] memory and socket performance monitoring
  7. shared memory
  8. [u] placement new and custom allocator
  9. system calls
  10. [u] in-lining
  11. [u = used in my systems to some extent]
  12. [P = no programming, pure system knowledge]

–These topics are relevant to mainstream c++ but more relevant to HFT

  • setjmp
  • IPC mutex
  • reference counting

19obscure but recurr`c++QQ questions #halo

All QQ topics, not related to GTD or coding IV

  1. Throwing dtor
  2. how to avoid virtual functions (use enum?); CRTP
  3. IPC mutex; synchronization in shared mem
  4. 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
  5. casting “this” pointer. See https://bintanvictor.wordpress.com/2017/11/15/crtp-1st-lesson/
  6. memory: placement new and how to delete
  7. reinterpret_cast
  8. why division by zero is not an exception
  9. debug build modifying behavior
  10. memory: q(delete this)
  11. SFINAE — I was asked in … 2 MS teams?

–socket programming interviews

  1. ##tcp tuning params
  2. non-blocking socket calls
  3. buffer full

77 c++IV paperTigers

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.

  1. [s] what debuggers and memory leak detectors are you familiar with?
  2. [a] singleton, factory, pimpl and other design patterns
  3. [s] c++ regex
  4. [s] stream I/O and manipulators
  5. [A] CRPP, SFINAE — real tigers. I got asked about these around 5 times, sometimes in-depth
  6. —sockets # many more paper tigers to be listed
  7. udp, multicast, select()
  8. [s] socket buffers
  9. [a] byte alignment
  10. endianness
  11. non-blocking
  12. TCP flow control
  13. TCP handshake and disconnect
  14. ack numbers
  15. partial send
  16. close() vs shutdown()
  17. — STL # many more paper tigers to be listed
  18. [s] STL binders
  19. [s] STL allocators
  20. adapters for containers, iterators and functors
  21. [a] iterator invalidation rules
  22. [s] how is deque different from a vector
  23. RBtree
  24. —concurrency # many more paper tigers to be listed
  25. [A] atomic types
  26. pthread functions
  27. [A] IPC mutex
  28. mutex in shared memory
  29. recursive lock
  30. read-write lock
  31. what if a thread dies while holding a lock?
  32. [s] RAII scoped lock
  33. — multi-file build
  34. forward class declarations (as required in pimpl) and their limitations
  35. [s] C/C++ integration, extern-C — heavily quizzed, but no in-depth
  36. [s] what C features are not supported by c++ compiler
  37. circular dependency between libraries — confusing. real tigers
  38. [s] shared lib vs static lib
  39. —integration and data exchange
  40. [A] shared memory
  41. [A] CORBA, RPC
  42. [a] serialization in compact wire format — only primitive data types!
  43. [s] OS system calls vs std library (glibc) — sounds daunting to most developers
  44. —exception
  45. catch by ref or by value or by pointer?
  46. [s] exception guarantees
  47. [s] stack unwinding due to exception
  48. throwing destructors — various questions
  49. —memory
  50. which part of memory do static data members go? How about file scope static variables? How about global variables
  51. [s] preventing heap/stack allocation of my class
  52. [s] custom new/delete,  set_new_handler()
  53. [s] intrusive smart ptr, weak_ptr
  54. [s] ref counting
  55. custom deleter in shared_ptr
  56. [s] reinterpret_cast  # mostly on pointers
  57. custom allocators
  58. [A] free list in the free store
  59. what if you call delete on a pointer that’s created by array-new?
  60. placement new
  61. out-of-memory in operator-new
  62. —inheritance
  63. dynamic_cast
  64. [A] multiple inheritance
  65. [s] virtual inheritance… which base class ctor gets called first? See https://isocpp.org/wiki/faq/multiple-inheritance#mi-vi-ctor-order
  66. [a] slicing problem
  67. [a] private inheritance
  68. [s] pure virtual
  69. —other low level topics
  70. [s] setjmp, jmp_buf… See the dedicated blog post jmp_buf/setjmp() basics for IV #ANSI-C
  71. [s] cpu cache levels
  72. [s] translation lookaside buffer
  73. [s] what data structures are cache-friendly?
  74. [a] memcpy, memset
  75. [s] ++myItr vs myItr++ how are they implemented differently?
  76. —other language features
  77. [s] RAII
  78. [s] operator-overload
  79. [A] template specialization — part of the STL fabric but largely transparent
  80. [s] ptr to member (function) — seldom used outside library code. I tried the syntax in my binary tree serializer
  81. [A] std::forward() std::move(), rvalue-ref
  82. const and constexp
  83. [a] lambda with capture
  84. [a] double-pointer .. why do you need it?
  85. —-
  86. [s == shallow book knowledge is enough]
  87. [a == actually not that deep, IMHO]
  88. [A == actually deep topic]

c++4beatFronts: which1to LetGo if I must pick 1

What to let go, given I have limited O2/laser/bandwidth and mental capacity?

  1. give up BP — biggest room for improvement but least hope
  2. give up codility style — Just get other friends to help me. See codility: ignore overflow, bigO
  3. give up algo — already decent. diminishing return. Smaller room for improvement? But practice on some small algo questions can significantly improve my ECT.

##c++QQ topics I took up since Apr 2017

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”
  • [3] sfinae
  • [3] crtp
  • covariant return type and virtual ctor i.e. clone()
  • static_assert? Non-trivial for those uninitialized with TMP
  • [3] alternative to virtual functions
  • singleton thread-safety
  • [3] heap memory mgmt strategies
  • [3d] make_shared benefits and limitations (Scott Meyers)
  • [3] shared_ptr concurrency
  • [d] Common mistakes involving shared_ptr
  • weak_ptr
  • unique_ptr ownership transfer
  • factory returning smart pointers
  • [d] emplace employing perfect forwarding
  • [3] just when std::move() is needed
  • std::move usage (outside big4)
  • [d] rval objects vs rvr
  • [3] placement new
  • [3] MI using Abstract Base Classes
  • [3] TCP congestion control
  • TCP OOS control
  • reinterpret_cast
  • — topics to be conquered
  • [3] TCP resend
  • TCP buffer sizing
  • std::forward()

[3=top-33 favorite topics among ibank interviewers]
[d=reached some depth of understanding]

##11 c++academic topics that turned out2b popular

  • –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

##c++QQ topics discovered ONLY from IV

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
    • enable_shared_from_this
    • auto_ptr vs unique_ptr
  • multiple inheritance, casting
  • template techniques
  • std::forward
  • exception catching/re-throwing
  • q[ … ] variadic template params
  • inline: impact on performance
  • throwing dtor
  • details of pure virtual

20 C++territories for QnA 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  –

## IV favorites ] sockets

There are dozens of sub-topics but in my small sample of interviews, the following sub-topics have received disproportionate attention:

  1. blocking vs non-blocking
  2. tuning
  3. multicast
  4. add basic reliability over UDP (many blog posts); how is TCP transmission control implemented
  5. accept() + threading
  6. 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
  • vptr

t_ivTechnicality is the tag

concurrency complexity/learn`curve c++imt java

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.

##tough n high-leverage c++topics#IV QQ

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

  1. 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.
    1. including “coding questions” designed really for knowledge test, rather than algorithm thinking
    2. eg: HFT, Venkat…
  2. high impact on algo coding IV? No such topic. These coding IV are not about knowledge in tough topics!
  3. ZZ: high impact on GTD zbs — inevitably Low leverage during job hunt
  4. 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:

  • [00] template wizardry;
  • [00] template specialization
  • [00] MI;
  • [00] operator overloading;
  • [00] pthread
  • ————-
  • [QQ]
  • [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()
  • [QQ]
  • [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. ]

## c++topics seldom quizzed

(master -> pearl)
some low-level details I thought would be popular but seldom asked:
* L-value
* iterator types and implementations
* static variables outside classes
* implicit acts of magic by compiler
* array and cStr – syntax, memory, … the gory details beyond the basics
* template specialization
* ref/pointer typedef inside  templates
* non-dummy-type args in template
* MI
* enum
* exception spec
* C integration
* pimp
* fwd declaration
* namespace
* linker
* extern
* double pointers
* hiding rule
* swap – all the important usages and no-fail
* overloading and  method resolution
* casting and conversion
*** OOC and  conversion ctor
— “mid-level”
* boost Any vs Variant
* i/o stream
* regex
* file access (including random)
* serialization
* memory leak detection
* details of boost thread
* boost smart pointer beyond the shared_ptr
* std::string details

[17] %%c++IV(!!GTD) 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. 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 —
    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

##c++(GTD+)learning-aids to upgrade 6→7

Which yardstick? First must be IV. 2nd would be common (not the obscure) GTD skills
For IV, need to analyze how I was beaten in past interviews. For GTD zbs, a few major home projects has significantly increased my proficiency.
  • 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/]

##[15]where in c++am I growing: GTD^IV

Short and sharp answers preferred
–Q: where and how fast am I growing in c++ IV?
A: EPI300/Google style coding test, esp with STL, shared_ptr etc
A: the HFT interviews revealed my weaknesses in some QQ areas.
A: ##10 basic programm`constructs for timed c++ cod`IV  — focus, direction for IV preperation
–Q: where and how fast am I growing in c++ zbs
A: debugging using print or gdb. No longer afraid of funny errors
A: experience reading STL errors
A: [[safe c++]]
A: [[21st century C]]
A: Learned to question what low level details are more than academic
A: Learned the practical value of c++ integration with excel, python etc
A: Learned a bit more about instrumentation including debuggers, esp. on Windows
A: Learned a bit more about boost smart pointers. There are many of them, because there exists different needs.
A: Learned a bit more about IDE, make, cmake and friends

##c++interview topic "clusters"@Wall St


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