IKM, boost, c++11, templates, sockets] QQ IV #Ashish

Hi Ashish,

How is your new job? What technologies? What technical challenges?

(I just turned down a windows c++ dev role, partly because I’m more interested in linux. I feel there are fewer online resources to help with vc++ developers.)

I now have a little theory on the relative importance of some c++ tech skills in a job candidate. I feel all of the skills below are considered “secondary importance” to most of the (10 – 20) interviewers I have met.

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 app developers.

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.

Q: Are there job candidates who are strong with some boost feature (beside shared_ptr) but weak on STL and 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

sockets —— is relevant to some low-latency, network teams. 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.

(Actually socket api is not a c/c++ language feature, but a system library. Unlike STL, socket library has narrower usage.)

templates —— 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.

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.

Advertisements

## 10 special technicalities for QQ IV

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?
  • $LD_LIBRARY_PATH
  • iterator categories? Seldom quizzed
  • hash table theoretical details? too theoretical to be part of this discussion
  • select() syscall
  • vptr

t_ivTechnicality is the tag

##minimum py know-how for (compiler)coding test #XR

Hi XR,

My friend Ashish Singh (in cc) said “For any coding tests with a free choice of language, I would always choose python”. I agree that perl and python are equally convenient, but python is the easiest languages to learn, perhaps even easier than javascript and php in my opinion. If you don’t already have a general-purpose scripting language as a handy tool, then consider python as a duct tape or Swiss army knife

(Actually linux automation still requires shell scripting. Perl and python are both useful additions.)

You can easily install py on windows. Linux has it pre-installed. You can then write a script in any text editor and test-run, without compilation. On windows the bundled IDLE tool is optional but even easier – see https://stackoverflow.com/questions/6513967/running-python-script-from-idle-on-windows-7-64-bit

(Ashish please feel free to add to this list) For coding tests, a beginner would need to learn

  • · String common operations. Regex not needed
  • · list and dict data structures and common operations. A “Set” may be useful occasionally. Tuple not needed.
  • · “in” operator on string, list, dict
  • · if/elif/else; while loop with beak and next
  • · for-each loop is more useful in coding test, esp. iterating list, dict, string, range()
  • · range() function – frequently needed in coding test
  • · Define simple functions. Recursion is frequently coding-tested.
  • · No need to handle exceptions
  • · No need to create classes
    • I think “struct-type” classes with nothing but data fields are useful in coding tests, but not yet needed in my experience.
  • · No need to learn OO features
  • · No need to use list comprehension and generator expressions, though very useful features of python
  • · No need to use lambda, map()/reduce()/filter()/zip(), though essential for functional programming
  • · No need to use import os and sys modules or open files, which are essential for practical automation scripts

some low level QQ questions will beat me, but remain confident during IV

See https://bintanvictor.wordpress.com/2017/02/02/c-and-java-iv-tend-to-beat-us-in-2-ways-high-end/. Inevitably, some questions will beat us, perhaps in terms of algo challenge, but many recent questions beat us in terms of in-depth knowledge. So how do you react in an interview after you are beaten on some questions?

Look at this linked-in endorsement — … has an solid attention to detail. He relentlessly pursues the most efficient and sensible means to developing software applications. He can lead a team of developers locally and globally, be a team advocate, a problem-solver, and a top-notch software designer. I often relied on him to explain and help detail some of the most complex logical components.

Such a person may very well fail some of those interview questions. He needs to be self-confident about his GTD skills like design, delivery…

## array+other topics]algo quiz

–coding IV topics ranked

  1. #1 array, string, list, queue
  2. qsort + other sort
  3. generate permutations etc (probability + very little discrete math)
  4. binary trees

— beyond top 5, within top 10

  1. hashmap? if we exclude QnA questions, then this topic is not in top 5
  2. primitive types
  3. non-tree graph traversal
  4. combining multiple data structures? needed for bigger problems
  5. 2D image

–beyond top 10

  1. DP
  2. concurrency

coding IV – favored by the smartest companies

XR,

I see a few categories of IV questions:

1a) fundamentals — Some Wall St (also in Asia) tough interviews like deep, low-level (not obscure) topics like threading, memory, vtbl, RB-tree ..

1b) lang — Some (IMO mediocre) interviewers (like programming language lawyers) focus on language details unrelated to 1a)
2) Some (IMO mediocre) interviewers like architecture or high level design questions (excluding algo designs) like OO rules and patterns but I feel these are not so tough.

3) algo — Some tough interviews focus on algo problem solving in pseudo-code. See http://bigblog.tanbin.com/2007/09/google-interviews-apply-comp-science.html. I got these at Google and Facebook. Some quants get these too.

4) compiler coding question — is another tough interview type, be it take-home, onsite or webex.
With some exceptions (like easy coding questions), each of these skills is somewhat “ivory tower” i.e. removed from everyday reality, often unneeded in commercial projects. However these skills (including coding) are heavily tested by the smartest employers, the most respected companies including Google, Facebook, Microsoft… You and I may feel like the little boy in “emperor’s new dress”, but these smart guys can’t all be wrong.
I will again predict that coding questions would grow more popular as the logistic cost is driven down progressively.
Candidate screening is tough, time consuming and, to some extent, hit-and-miss. With all of these screening strategies, the new hire still can fail on TECHNICAL ground. Perhaps she/he lacks some practical skills — Code reading; debugging using logs; automation scripts; tool knowledge (like version control, text search/replace tools, build tools, and many linux commands)
Needless to say, new hire more often fail on non-technical ground like communication and attitude — another topic altogether.

In terms of real difficulty, toughest comp science problems revolve around algorithm and data structures, often without optimal solutions. Algo interview questions are the mainstay at big tech firms, but not on Wall St. Some say “Practice 6 months”. Second toughest would be coding questions —
* Often there’s too little time given
* Sometimes interviewer didn’t like our style but onsite coding tends to focus on substance rather than style.

Tan bin

P.S. I had webex style coding interviews with 1) ICE Feb 2011, 2) Barclays (swing), 3) Thomson Reuters, 4) Bloomberg

P.S. I tend to have more success with algo interviews and onsite coding than take-home coding. See blog posts.. (
http://tigertanbin2.blogspot.com/2015/05/sticky-weakness-revealed-by-interviews-c.html
http://tigertanbinpripri.blogspot.com/2015/03/high-end-developer-interviews-tend-to.html
)

probability quizzes for tech IV

I think it pays to invest in this domain.

Q: Why the hell do interviewers ask those (mostly discrete) probability questions?

I get these questions all the time. Similar to brain teasers and abstract aptitude test:

  • Well-defined, easy to understand
  • Completely unrelated to the tech job
  • somewhat crack-proof, so (as interviewers would think) more useful as an objective aptitude test

A: I can only guess it’s related to IQ. See post on Facebook regex interview

hackrank tips for coding IV

  • chrome (not Opera) supports Alt-R
  • chrome F11 to toggle full screen
  • chrome can zoom out 80% to show more lines in editor, if you can’t find a bigger monitor.
  • I guess we need to parse stdin, so get familiar with getline() and “cin<<“
  • How (fast) you type and erase …. is all recorded, so better use the scratchpad
  • add comments to show your thinking

Here’s some code we can copy-paste:

#include <iostream>
#include <string>
#include <vector>
using namespace std;
int i1, i2, i3; 
double f1, f2, f3; 
string s1, s2, s3;
int main(){
}

Most tough algo interviews don’t care about efficiency

Most challenging algo interviews (onsite) are really about “solve it by hook or by crook” regardless of efficiency. (Usually there isn't, but if there's an obvious brute-force solution it gives you no credit anyway.)

In the toughest algo questions, usually there's no memory capacity issue to worry about.
Occasionally, interviewer stipulates O(N logN) or O(1)
Once we solve it we can improve efficiency. It's a second phase. Can be easier than first phase.
In that case threading, sorting … are unimportant. Instead we need judicious use of trees, recursions, pattern recognition… and very clear thinking.
See [[EPI300]] and the green book by Zhou Xinfeng

reach next level ] tech IV performance

See also the similar pripri post about “beat us”.

I really don’t care that much about zbs needed in a project:
* the so-called architecture expertise is overrated and overhyped. See my post on
** GTD
** software architect vs enterprise architect
* the optimization expertise is … similar

Next level requires .. more knowledge. See post on “Yaakov”
Next level requires .. more practice with Facebook algo questions.
Next level requires .. IDE coding against simple problems like codility.
Next level requires .. more mileage with hands-on dev.
Next level requires .. more “best practices” like google style guide