## marketable syntax nlg: c++ > j/c#

Every language has poorly understood syntax rules, but only in c++ these became fashionable, and halos in job interviews !

  • ADL
  • CRTP
  • double pointers
  • hacks involving void pointers
  • operator overloading to make smart ptr look like original pointers
  • TMP hacks using typedef
  • TMP hacks using non-type template param
  • universal reference vs rvr
  • rval: naturally occurring vs moved
    • const ref to extend lifetime of a naturally occurring rval object

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, so Venkat can impress interviewers with his Wikipedia knowledge. In contrast, DQH would run complicated coding experiments to build insights.

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

7 clusters@HFT-c++IV questions

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.

  1. socket — lots of details as Shanyou and I agreed
  2. template meta-programming — deep topic but never quizzed in-depth beyond “tricks”
  3. move-semantics

— Themes are less visible in these clusters:

  1. pthreads and c++ threading but I seldom get c++11 question here
  2. STL container internals, mostly shared_ptr, raw array, vector, RBTree, and hashmap
  3. (back of tricks) memory optimization techniques using allocators, cache-optimization, malloc(), placement-new, object-pool, memset,
  4. miscellaneous core OO features like big4, virtual, MI, pbref/pbval

— other HFT topics are dispersed/scattered, not showing any strong central theme

  1. shared memory
  2. linux system calls
  3. compiler details
  4. selected boost libraries

## 9 short but deep c++IV Q

  • [0x] Q: exactly .. differences and similarities between auto_ptr and unique_ptr?
  • [0x] Q: exactly .. what’s the usage of weak_ptr?
  • [0x] Q: exactly when do you need to call std::move()
  • [0x] Q: what kind of things can be assigned to a rvr variable?
  • [0x] Q: give some examples of famous move-only types and explain why and how they are used
  • [0x] Q: give an exact example of exception safety enhancement provided by make_shared
  • [0x] Q: beside the big6, what kind of functions would accept a rvr param? push_back().. rather few outside the STL
  • — also-ran:
  • Q: why catch by reference?
  • Q: explain some consequences when a dtor throws?
  • [0x=c++0x]

## 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

##short-n-hard algo@simple data structures

90% of the hardest coding questions use simple data structures. Some of these algos are

  • very short but baffling
  • doesn’t use fancy data structures
  • requires prior study; no expectation to invent them during an interview

–Linked list

Brent — check for loop in linked list

–binary tree

Morris — Morris in-order walk]O(N) #O(1)space


  • regex
  • KMP string search
  • longest palindrome substr
  • edit distance



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. 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
  4. casting “this” pointer. See https://bintanvictor.wordpress.com/2017/11/15/crtp-1st-lesson/
  5. memory: q(delete this)
  6. memory: placement new and how to delete
  7. why division by zero is not an exception
  8. debug build modifying behavior
  9. IPC mutex; synchronization in shared mem
  10. memcpy
  11. ADL
  12. template template params

–socket programming interviews

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

c++4beatFronts: which2LetGo if I must pick1

Q: Which one 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

How about pure algo?

  • already decent? Can improve.
  • diminishing return? Smaller room for improvement? but I can learn a few key ideas about the G100 questions

##some c++QQ topics I took up since Apr17

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”
  • ADL
  • [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 vs raw ptr
  • unique_ptr ownership transfer, reset^release
  • factory returning smart pointers
  • [d] emplace employing perfect forwarding
  • [d] naturally occurring temp objects vs const ref and RVO
  • [3] just when std::move() is needed .. see email to CSY
  • 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
  • non-blocking socket functions
  • — 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

c++11,sockets,IPC in QnA IV #AshS

[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

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


some Technicalities for QnA IV

We often call these “obscure details”. At the same level, these 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
  • hash table theoretical details? too theoretical to be part of this discussion
  • select() syscall details
  • vptr, vtable


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.

##[17]tough n high-leverage c++topics #QQ[def]

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

  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 a subset of coding questions designed really for knowledge test, rather than algorithm thinking
    2. eg: HFT, Venkat…
  2. high impact on algo coding IV? rather few such topics. See t_algoQQ. Rather few coding interviews are about knowledge in tough topics!
  3. ZZ: high impact on GTD zbs — inevitably Low leverage during job search
  4. 00: no high impact on anything

Q: Is there a tough topic in both QQ and ZZ? I doubt it.

  • [00] template wizardry;
  • [00] operator overloading;
  • [00] pthreads
  • ————-
  • [QQ]
  • [QQ] template specialization
  • [QQ] MI;
  • [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 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. Overall, java is a slightly less specialist, less elitist, more commodity skill. 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++ low-level tech 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, …
    • [C] *alloc family of functions, memory leak detectors
    • shared lib, linker, compiler,
    • [C] other command line developer tools … mostly designed for the “system programmer”.
    • [C] sockets, IPC
  • –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

##[12] some c++(mostly IV)questions

Q: what if I declare but not implement my dtor?
A: private copy ctor is often left that way. Linker will break.
Q: how to access a c++ api across network
A: corba?
Q: default behavior of the q(less) class-template
A: I have at least 2 posts on this. Basically it calls operator< in the target type (say Trade class). If missing, then compiler fails.
Q: how do you detect memory leak?
A: valgrind
%%A: customize op-new and op-delete to maintain counters?
Q: in java, i can bind a template type param — bound params. c++?
%%A: no, but I have a blog post on the alternative solutions
Q891: are assignment op usually marked const?
%%A: no it must modify the content.
Q891a: what if i override the default one with a non-const op=? will the default one still exist?
A: I think both will co-exist
Q: do people pass std::strings by ref? See Absolute C++
%%A: yes they should
Q: unwrap a null ptr
A: undefined behavior. Often termination.
Q: delete a null ptr
A: C++ guarantees that operator delete checks its argument for null-ness. If the argument is 0, the delete expression has no effect.
Q: comparing null pointers?
A: In C and C++ programming, two null pointers are guaranteed to compare equal
Q: use a ref to a reclaimed address?
A: Rare IV… undefined. May crash.
Q: can i declare a Vector to hold both Integers and Floats?
A: slicing. To get polymorphism, use ptr or ref.
Q: what op must NOT be overloaded as member func?
A: rare IV…… qq(.) is one of five.
Q: Can i declare an Insect variable to hold an Ant object, without using pointers? “Ant a; Insect i = a;”?
A: see post on slicing
Q: Without STL or malloc (both using heap), how does C handle large data structures.
%%A: I used to deal with large amounts of data without malloc. Global var, linked data structure, arrays
%%A: I can have a large array in main() or as a static variable, then use it as a “heap”

## c++0x features I understand as significant

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>


#4 type traits

##[11]c++interview topic "clusters"@WallSt

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

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

##c++features used on WallSt, again

STL, boost
array-pointer integration (A major strength in C)
dynamic cast, but not RTTI or vptrcustomized operator-new and operator-delete

–These features are less used
tricky operator overload
template class development
Now we know that on Wall Street, C++ OO designs are primitive compared to Java OO designs