##minimum py know-how4(compiler)cod`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

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