I disagree with article's conclusion that they are selecting for "backend" engineers. They are selecting for people that think over-engineering every little data structure is the way to build good programs. The skill software companies need is the ability to get a hundred subsystems tested and working together, which is totally different.
I know someone who recently interviewed with Google and he told me about the algorithms question he "got wrong." After he came up with a simple solution to a simple problem, the interviewer told him the better, googley-er algorithm, which was: a) far more complex and difficult to implement, b) had far more corner cases that would need unit tests, c) had more overhead in the expected case, but d) technically had a better big-O in the (extreme) worst case.
In other words, the interview was screening for people who have been to school but haven't ever built anything.
That was the impression I walked away with too: much CS ivory tower thinking, little real-world relevance. But they're only interviews, everyday life at Google is probably (hopefully!) different.
As a counterpoint to the HR horror stories: my recruiter was a friendly woman who always responded quickly and politely. No complaints here.
I know someone who recently interviewed with Google and he told me about the algorithms question he "got wrong." After he came up with a simple solution to a simple problem, the interviewer told him the better, googley-er algorithm, which was: a) far more complex and difficult to implement, b) had far more corner cases that would need unit tests, c) had more overhead in the expected case, but d) technically had a better big-O in the (extreme) worst case.
In other words, the interview was screening for people who have been to school but haven't ever built anything.