It's interesting, because I'd argue that the best companies in tech have have interviews that are very structured and predictable.
As far as I can tell, there's always a pre-defined pool of questions. Some of them are pretty 'open ended', but still targeted towards getting a good impression of a certain area of knowledge.
That being said, I had an interview with Google at some point in the past where one of the interviewers almost seemed appalled that I didn't know the exact list of items that can be found in a filesystem superblock. But at all other companies it seemed a bit more sane. I guess it's partially a function of the type of personalities a company is willing to hire :)
But even then, for such a process to be rigorously structured, the questions themselves need to be determined a priori and without reference to the candidates background or preferences. Otherwise:
* You're subject to the interviewers and judges (probably subconscious) biases about the merits of different questions.
* You're more exposed to the candidates own innate ability to interview well by navigating themselves to more easily-answered questions.
Do you mean characters to indicate a null child?
I think the Google hiring process is fucked up in a lot of ways, but I don't think reliance on whiteboarding or the selection of interview questions are two of them.
Well sure, but you only have so much time to study for these interviews.
So, you make sure you review your basic data structures, algorithms, and complexity analysis. The things that will most likely show up.
Then you have to consider the more advanced topics. Realistically, you're not going to have an expert-level understanding of all of them. None of them are extremely difficult concepts to understand necessarily, but you need the kind of mastery to understand such a problem quickly and under pressure (since it's a short, timed interview).
The most effective way to study, then, is to simply run through a battery of dynamic programming questions and hope you get lucky and the interviewer asks you a variation on one you studied.
I've had more than a few AmaGooFaceSoft interviews ask me slight variations on the change counting question. They're really testing my ability to recall the solution to that problem, not any sort of deep understanding of dynamic programming.
On the flip side, the interviews I've failed almost always involved some pet topic that I wouldn't dream of studying. I once (no joke, and not THAT long ago) had an interviewer at AmaGooFaceSoft ask me do a bunch of calculus questions involving power series (turn a function into a power series, determine the radius of convergence, etc.). Why would I study that for an interview?
Considering the payoff (potentially a $40,000 to $100,000 raise on a 40 hour work week), I think that the amount of time to study for these types of interviews is very trivial. Interviewing skills can be used for interviews at many well paying companies because this type of interview has been standardized, so it's not like you're only studying specific knowledge for one company.
MapReduce, Pregel, Bigtable, Flume, etc. are building blocks: they solve some of the distribution problems, but you still need to understand how the algorithms that run on top of them work, on a step-by-step level, to implement on top of them.
Let's say you work on some part of Android. Obviously you need to interact with things like Google's build system which are distributed, but are you really implementing some distributed computation in the course of your every week, or even every month?
I get that Google wants to test during the interview for suitability over a large space of possible specific roles, but I seriously doubt that "distributed systems stuff" would be in the list of top 10 programmer domain knowledges that are useful in those roles. Is it more useful than knowing how to work with version control well? Everyone at Google has to do that, but they don't test it during the interview. Is it more useful than being able to read and write idiomatic and readable Java? They don't really substantially test that during the interview either.
(On the other hand, the things that spawned this conversation were "dynamic programming, parallelism, and networking" and the latter two are much more obviously generally important things.)
There are a lot of other ways to screw up an interview.