learn with the intent to become a better engineer, even if you don't hit the google mark (which is arbitrary anyway), you will become a better engineer. That is the philosophy most people should use when trying to aim for these companies. Don't cram, learn.
I disagree. Doing competitive-style programming and learning all sorts of weird algorithms has not made me a better engineer. I can count on one hand the number of times in my career that I have had to design or use an "interesting" algorithm - and no, not in the "not knowing what you don't know" sense where I could have used one if only I'd known about it.
I'm very critical of this approach to interviewing in general, but it also isn't the same as competitive programming and it isn't focused on "interesting" algorithms. It is far more focused on understanding how to use data structures and the trade offs between them. Chapter 3 of "The Algorithm Design Manual" (which is fittingly titled "Data Structures") is really the most useful reference for the majority of these interviews. I don't think this is the most useful thing for software developers to be good at, but it's definitely useful and worth learning. I was annoyed that I had to study for one of these interviews, but ended up being pleased that it forced me to review this material.
2) some sort of odd string / array manipulation that never comes up in real life
3) some sort of linked list manipulation where again there is an STL for that and/or wouldn’t come up in real life
4) some optimized algorithm that literally took the first person years to discover prims vs kruskals MST for example, but now is expected to “figure out” on the fly.
5) Expects you to solve all these tasks with an insane time pressure that again is not a simulation of real life, it just makes it stressful almost as a rite of passage
None of that rings true to me. Like I said, I really dislike the way we do interviews, but I find this to all be exaggerated to the point that it weakens your argument.
I think the point is that you don't need to understand the gory details of how e.g. your hashtable works - for most coders, it's sufficient to know that it exists in the standard library; it's O(n) on space; it's amortized O(1) on retrievals and updates, but can be O(n) on some inputs; and that there is a class of security issues related to using untrusted data as keys. They don't really need to know why all these things are true, or know how to implement it from scratch.
Right, and my point is that interview questions don't actually tend to be of the form, "write me a good hashtable implementation from scratch". They do tend to prod whether people can take advantage of the trade-offs between the properties of maps vs. lists.
My point is that there is plenty to complain about - unrealistic time pressure, writing on a whiteboard, only testing coding when that is the least interesting part of a senior developer's job, no opportunity to test and debug, etc. - that it isn't necessary to bring up these exaggerated boogeymen about how everyone is asking for novel algorithms on-the-spot.
I've seen plenty of interview questions that do boil down to "implement this algorithm" or "implement this data structure". There are similar examples in comments on this very discussion.
Exactly! The field is so large and growing rapidly that it’s unnecessary to memorize the inner workings (especially down to the node pointer level in c++ where you’re begging for trouble and it will be a nightmare to maintain unless you have a performance specific reason not to use the stl)
IMO being able to say “I don’t know the the specifics, but I would use dijkstra’s algorithm on this problem” shouldn’t disqualify you because you couldn't code it.
