Saturday 26th October 2013 6.49pm
Sat, Oct 26, 2013
"That book (Effective C++ by Scott Meyers) is well worth reading, but in fact wouldn't have helped with the questions I was asked at each of Amazon, Bloomberg, Google or Microsoft.
For Amazon they basically expect you to rote learn the answers to the standard list (i.e. the book Cracking the Coding Interview: 150 Programming Questions and Solutions). If you're not perfect, goodbye, because most candidates applying there do rote learn the list.
For Bloomberg expect to know an insane amount of detail about the C++ STL like every time and space and operation complexity for every member function of every STL container, plus you'll see a lot of math from basic Pure Math Analysis especially infinite limiting processes on sequences etc. The STL stuff can be rote learned, and the pure math analysis can be practiced for speed which you will need. Practice on a small bit of paper, because no whiteboards are used, just paper and pencil.
For Google, well it's all graph algorithms really. Three of your five will be pure graph analysis and algorithms, one will be complexity analysis and not the typical O(N^2) either. The last, which most people who passed the previous four fail at (but I knocked the ball out of the park) is systems design where you will design a large, scalable, distributed, resilient, secure solution to a real world problem. If you miss any of scalable, distributed, resilient or secure, you will be rejected. You can rote learn and practice for speed the graph analysis and complexity analysis which is why 90% of candidates do well on these, but the systems design is pure experience and cannot be rote learned. Tip: rent a dedicated server, install a virtualisation solution onto it and then configure and secure your own web services mash up. After you have the practice on this, you'll do well in systems design.
For Microsoft, expect one on implementing a part of the STL according to the ISO C++ specification with strong maximum time and space complexity guarantees according to iterator specialisation (traits); one on implementing a data compression routine such as Huffman (and you'll need to know that off the top of your head); one on complexity analysis, including when massively parallelised where you will need to find a method of pruning the analysis tree; one on graph colouring, including traditional Knuth and parallel complexity analysis; one on real world code examination and debugging of a large bit of production code; and one on interpersonal skills, ability to communicate to specialists, ability to understand political imperatives and deal with them positively. Of all the interviews I had, this one is the hardest to rote learn for, because really they all came down to experience more than anything else, and much more so than the previous interviews. If you have implemented a STL component before, written a compression algorithm, written algorithms for Hadoop, debugged one million line legacy codebases, and worked across divisions inside a large corporation, then you'll do very well. I, unfortunately, had never done two of those before (Hadoop and the compression algorithm, hey I just imported someone else's compression library instead!).
That was my experience anyway. Others applying to different departments may experience differently, though Google and Amazon have a unified interview process for all roles at the beginning. Only once past what I describe above do you get further interviews with specific divisions and teams (and yes, you can fail those too, some candidates get past everything but no specific team is interested in them, so they get passed over).
Hope this helps anyone interested. I should caveat that I have failed all my interviews so far (still waiting to hear from Microsoft though), so my descriptions may be missing something vital to passing such interviews that I don't recognise."