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: I feel a disproportionate number of my c++ interviews come from high end teams, They go slightly more low-level than my java interviews. Imagine if I get more high end java interviews from the likes of Millennium, HSBC … I feel most (like 80%) of the java jobs in finance are “regular”; for c++, it’s more like 50%.
- –A #3: significantly simpler — java as a language, when we ignore the add-on packages.
- –A #2: a lot of the tough C++ IV questions are about
- [C] sockets,
- [C] *alloc function, memory leak detectors
- [C] IPC
- [C] other command line developer tools … mostly designed for the “system programmer”.
- 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.
- –A: 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.
- –A: halos — in my “java show” include threading, collections, GC tuning … which make up for my weaknesses. 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
- (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;
- 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 [[effectiveC++]] topics
I wanted to know more about boost lib to impress interviewers.
Some of the most useful boost data structures require a deeper understanding or work experience with STL than I have.
Some boost libraries require deeper understanding of other c++ features than I have:
So without a firm ground, I find myself reading but not remembering. The mud doesn’t stick on the wall.
My strengths – quick but more than superficial learning of (in random order):
- finmath, financial jargon,
- Comp Science practical topics:
- OO fundamentals
- algo, data structures,
- basic tuning of DB + others
- language fundamentals (more respected in the java, c++, c#, SQL than python communities)
- versatile in many important languages
- relative familiarity with scripting, unix, SQL, but not IDE, version control etc
- relatively quick whiteboard (not compiler) coding
This strength turned out to be extremely valuable on Wall St consulting market.
My key weakness identified in recent jobs (not counting the IV defeats):
- learning local system
- large existing codebase – AutoReo, GS
- superfast GTD
Relative to java/c#, c++ questions are more low-level (often using non-OO constructs). This is generally my strength.
I used to feel confident I can see patterns in tech interview questions and figure out what specific types of knowledge is required at a certain seniority. I was fairly successful with java/SQL/c#, but less so with c++. Based on the past questions i’m trying to make out the patterns.
=======weaknesses revealed by interviews. Probably need more GTD experience. Subset of these are both tough and high-leverage — mostly QQ category.
- couldn’t describe my vol fitter project as a c++ project
- couldn’t describe my B2bTrading engine as c++ project
- any threading code I wrote for coding tests I couldn’t implement in boost::thread
- STL useful tricks (like swing) — Shanghai, synechron, Jap, WQ
- specific threading constructs/techniques — sapient, jump, SCB
- boost common lib — jump, Jap NumericTech, synechron,
- firm grasp of language features (like rvalue ref) — 3Arrow, bbg
- how to handle heap (smart)pointer as a field
- essential class-based techniques/constructs (eg ref counting) — Miami, espeed, nQuant,
- c++11 features – DRW, 3arrow
- initializing common data structures like arrays, vectors, classes — needed in a lot of coding challenges
- implementation details of singleton, factory, pimpl, ref-counted string
- [lg] mem management/optimization (like heap-only classes) — barc-mtg, nQuant
- [lg] socket — nquant
- (No one tested me on MI, advanced template, etc)
- ====These are harder to self-study — too specialized and no pointers
- [lg] template beyond merely using existing libraries
- linux (instrumentation) tools like truss, LD_library_path — jump, Miami, nQuant
- [lg] essential/deeper know-how (signals, OOM, stack size) not expected of a junior developer …– jump, Japanese, nQuant, 3Arrow, barc-mtg
- [lg] extreme low-level optimization (CPU cache, custom-RTTI, byte alignment, placement new) ..– Miami, nquant, jump
- =========much-needed zbs not quizzed by IV
- headers …
- static object – one-definition rule
- pre-processor tricks
- makefiles, continuous build
- linker troubleshooting, nm commands etc
- memory leak detectors,
- debugging — harder than java
- random crashes
Continue reading “##c++weakness revealed by QnA IV#+projects”
I feel my c++ interviews aren’t so successful (https://nlgpearl.wordpress.com/2015/05/06/sticky-cweakness-revealed-by-interviewsprojects/), but many traditional efforts may generate diminishing returns. (eg: Home coding project can be very time-consuming). Instead, perhaps we should look for special “imprints” – knowledge pearls that help us impress and stand out during competitive interviews. In a way, we must beat the interviewer on some front since on many questions we would be beaten.
Venkat can often stand out within a short conversation, due to his imprints.
My java interview experience – I managed to impress interviewers and stood out although my coding/design may not stand out. Am I a stronger java guy than my friends? I guess only if you quiz me on those special topics
– lock free
– wait/notify intricacies
– condition variable as replacement of wait/notify
– custom thread pool
– volatile keyword intricacies
– skip list (sorted set)
– concurrent hash map
– special singletons
Targets (memory/threading helps efficiency) —
* subvert the virtual mechanism P928[[primer]]
* placement new – real use cases
* replacement of RTTI
* data alignment in market data wire format
* memory page locking
* custom new() and free list in [[eff c++]]
* lock free – real code not concept
* template partial specialization but I don’t know the use cases?
* various custom-made smart pointers with special features — [[safe c++]]
* memory leak detectors – home made (eff c++?)
* comma operator
Self-rating is subjective, against one’s personal yardsticks. My own yard stick doesn’t cover those numerous add-on packages (swing, spring, hibernate, JDBC, xml, web services, jms, gemfire, junit, jmock, cglib, design patterns …) but does include essential core jdk packages such as —
- – anything to do with java concurrency,
- – anything to do with java data structures,
- –  Garbage collection
- memory profiling (jvm tools)
- GC log analysis
- –  java.lang.instrument, mostly for memory
- – networking/socket, file/stream I/O
- [!2017] generics, esp. type erasure
- – RMI,
- – reflection, dynamic proxy, AOP
- – serialization,
- – class loaders
- – JNI, esp. related to memory
- – JMX, jconsole,
- – difference between different JDK vendors,
- – real time java
- – reading bytecode
(The highlighted areas are some of my obvious weaknesses.) Now I feel my self-rating should be 8/10, but i still feel no one in my circle knows really more about the areas outlined above. I guess that’s because we don’t need to. Many of these low-level implementation details are needed only for extreme latency, where c++ has a traditional advantage.
Another purpose of this list — answer to this
Q: what kind of java (theoretical) knowledge would give you the halos in a Wall St interview?