I used to feel US is a less class-conscious society than China or Singapore. Anyone can make it in this “free”, meritocratic country. Then “insiders” tell me about the old boy’s circle, and the alumni circles on Wall St.
I feel in any unequal, hierarchical society, there are invisible walls between social strata. I was lucky to be an immigrant in technology. If I step out of tech into management, I am likely to face class, racial bias/affinity and … I would no longer be “in-demand” as in tech. Look at the number of Chinese managers in GS. Many make VP but few rise further.
Therefore the tech role is a sweet spot for an immigrant techie like me. Beside Tech, a few professions are perhaps less hierarchical – trading, medical, academic, research(?), teaching …
Many quant developers (in our department) program in c# (for excel
plugin) or build infrastructure code modules around quant lib, but
they don't touch c++ quant business logic classes. C++ quant lib
(model) programming is reserved for the mathematicians, typically
Many of these non-C++ quant developers have good product knowledge and
can sometimes move into business side of trading.
I was told these quant developers don't need advanced math knowledge.
Mostly C++ questions. Most candidates are filtered out here.
2nd group – probability, (different from statistics)
Some finance intuitions (eg — each item in the BS formula)
Some brain teasers
— some typical C++ questions (everything can be found from the Scott
exceptions during ctor/dtor
Given a codebase, how do you detect memory leak
multiple inheritance (fairly common in practice)
[[heard on the street]] and [[A Practical Guide To Quantitative
Another book by Shreve.
1) After learning c++, i am fairly confident I could if I must pick up
c# in a few (4?) months and start passing interviews. C++ is
inherently tougher than java and C#. Java and C# both have large
libraries, but the core languages are significantly simpler/cleaner
2) After learning C++, i have found python and perl easier to
understand and master since both are written in C/C++. I now believe
some people who claim they could pick up a new language in a few
months. Those languages have their roots in C/C++.
– The basic challenges of scope+namespace, object lifetime,
heap/stack, pointers, memory allocation, object construction,
pass-by-ref/value, arrays, function pointer, exceptions, nested
struct+array+pointer… are faced by every language designer. Many of
these challenges depend on basic library, which is invariably C.
– The common OO challenges of inheritance, virtual, static/non-static,
HAS-A/IS-A, constructor, downcast, … are faced by every OO language
designer. Many of them borrow from java, which borrows from C++ and
3) c++ gave me insight into java, esp. GC, JVM, overriding,
references, heap/stack, sizeof, …
* exposure to pricing decisions — the most important decisions
* closer to traders and their decision support
* closer to profit center
I find this book rather practical. Many small programs are fully tested and demonstrated.
This 2015 Book covers cpp14.
–#1) RVR(rval ref) and move semantic:
This book offers just enough detail (over 5-10 pages) to show how move ctor reduces waste. Example class has a large non-ref field.
P49 shows move(), but P48 shows even without a move() call the compiler is able to *select* the move ctor not copy-ctor when passing an instance into a non-ref parameter. The copy ctor is present but skipped!
P49 shows an effective mv-ctor can be “=default; “
–custom new/delete to trace memory operations
Sample code showing how the delete() can show where in source code the new() happened. This shows a common technique — allocating an additional custom memory header when allocating memory.
This is more practical than the [[effC++]] recipe.
There’s also a version for array-new. The class-specific-new doesn’t need the memory header.
A simple example code of weak_ptr.
a custom small block allocator to reduce memory fragmentation
Using promise/future to transfer data between a worker thread and a boss thread
The rules in the standard and in the implementations are not straightforward. Let’s try to have some simple guidelines:
The && parameter (in the function) — So far, the evidence is inconclusive so I will assume we always need a RVR parameter.
The call to move() — like on P47 [[c++ recipes]], sometimes without move() the move still happens, but I don’t understand the rules so I will assume I should always call move() explicitly.
I feel all the tutorials seem to miss some important details and selling a propaganda. Maybe [[c++ recipes]] is better?
[s = I believe std::string is a good illustration of this keyword]
 readonly – Without mv-semantic, we need to treat the original instance as readonly.
 allocation – mv-semantic efficiently avoids memory allocation on heap or on stack
 pointer field – every tutorial shows a class with a pointer field. Note a reference field is much less common.
 deep-copy – is traditional. Mv-semantics uses some special form of shallow-copy. Has to be carefully managed.
[s] temp – the RHS of mv-semantic must strictly be a temp object. I believe by using the move() function and the r-val reference (RVR) we promise to the compiler not to access the temp object afterwards. If we access it, i guess bad things could happen. Similar to UndefBehv? See [[c++standard library]]
promise – see above
containers – All standard STL container classes provide mv-semantics. Here, the entire container instance is the payload! Inserting a float into a container won’t need mv-semantics.
 including std::string
expensive — allocation and copying assumed expensive. If not expensive, then the move is not worthwhile.
cripple — the source object of the move is crippled and should not be used afterwards. Its resource is already stolen, so the pointer field should be set to NULL.
http://www.boost.org/doc/libs/1_59_0/doc/html/move/implementing_movable_classes.html says “Many aspects of move semantics can be emulated for compilers not supporting rvalue references and Boost.Move offers tools for that purpose.” I think this sheds light…
I think the use case for mv-constructs is tricky. In many simple contexts mv-constructs actually don’t work.
Justification for introducing mv-semantic is clearest in one scenario — a short-lived but complex stack object is passed by value into a function. The argument object is a temp copy — unnecessary.
Note the data type should be a complex type like containers (including string), not an int. In fact, as explained in the post on “keywords”, there’s usually a pointer field and allocation.
Other use cases are slightly more complex, and the justification is weaker.
Q: [[c++standard library]] P21 says ANY nontrivial class should provide a mv ctor AND a mv-assignment. Why? (We assume there’s pointer field and allocation involved if no mv-semantics.)
%%A: To avoid making temp copies when inserting into container. I think vector relocation also benefits from mv-ctor
[[c++forTheImpatient]] P640 shows that sorting a vector of strings can benefit from mv-semantic. Swapping 2 elements in the vector requires a pointer swap rather than a copying strings
[[the c++Standard library]] P23 explains the rules about returning rval ref. It’s obscure and hard to remember. My rule of thumb is to avoid returning RVR. I don’t see any good use case.
In cpp, java and c#, The worst part of lambda is the integration with (parametrized) templates.
In each case, We need to understand the base technology and how that integrates with templates, otherwise you will be lost. The base technologies are (see post on “lambda – replicable”)
– anon nested class
Syntax is bad but not the worst. Don’t get bogged down there.