Comment by nostrademons
11 years ago
All of infrastructure. You end up using LSM trees, Paxos, variations on binary search trees, checksums, Reed-Solomon, bloom filters, external sorts, and all sorts of other academic algorithms when you deal with distributed systems.
Docs/Drive does a lot with operational transforms and CRDTs, ever since Wave was merged into it (c. 2011). Remember that all Google Docs are collaborative.
All logs analysis & experimentation relies heavily on statistics, as well as online algorithms for reservoir sampling, quantiles, and a number of other statistical quantities.
Machine-learning is pervasive, throughout Shopping & News (it's all over these), GMail (spam, priority inbox, categories), Search, Ads, self-driving cars, Brain, and many other areas of the company.
Chrome and Android both do a lot of traditional OS & systems programming.
The main product area that didn't use algos heavily was Google+, although even this had some interesting stuff in stream ranking and search.
This is one thing people don't understand. In my current work I need to regularly design a new algorithm or modify existing ones. I've to keep books like CLRS and TACP always accessible, not for show but actually looking through pseudocode and analysis. I regularly sweep through dozens of research papers to find the state of art. These are not one-off events it's my and my teams day to day life. Lot of people often gets surprised when I tell this to them because most developers think they never need to use any CS stuff they had learned. If they ever need answer on any algo there is always framework or wikipedia. They just don't understand that most real world problems (or at least the ones we work on) require significant amount of customizations and mixing. These same people then insist that just because they have "shipped" some code or because they have showed "coding" capability via github profile, they should be eligible to be hired anywhere. Coding and development is "given" and that's considered as easiest part in our line of work. Shipping things is certainly art but that's hardly sufficient condition. The choice, analysis and design of algorithm makes ALL the difference in type of problems that we work on. If a guy showed up who wrote some package manager on Mac but couldn't work with binary trees, I would probably would pass too because in the kind of work we do his chances of success is fairly low. Frameworks and programming languages can be learned pretty fast but learning CS and building problem solving abilities using CS primitives takes years and years of intensive study.
There's totally a lot of crunchy CS in many things Google is into (and I do distributed systems stuff, so I can empathize heavily with your first paragraph). If you're doing it right, though, writing the crunchy CS bits of these should be exceedingly rare. Understanding is important, but I'm not sure you get a measure of working applied capability from writing this stuff in an interview. Discussing it, surely, but this is stuff that one--wait for it--Googles when dealing with implementations. And I strongly doubt that the overwhelming majority of Google developers are involved with the actual construction of this stuff.
The real reason, as near as I can tell, is because it allows management to not think as hard about allocating talent (the mythical "fungible engineer" nonsense), but whether it even works is another thing entirely.
Not everyone is constructing them, but everyone needs to be able to reason about they behave, determine what they need, and yes write it if a good option isn't available.