I don't know about google, but on my first proper job after graduating (the actual first lasted only two months) I was given a coding problem that involved writing a parser. After I got hired in the company I spent about seven months gluing APIs and adding one-liners etc, but in those seven months I once actually had to write a parser (for Tag-Length-Values). And in the seventh month, another engineer had a problem that was almost identical to my interview question- we were all gathered together around their monitor laughing about it.

So I'm guessing, it's not for the everyday stuff that google thinks you need to know how to invert binary trees etc, it's for that one time when you'll really need to do it.

... of course, at that point you can just look up the solution, but I guess they want to make sure you can understand it.

It’s called “proto to proto” in google slang, and yes, googlers definitely complain that their jobs consist mostly of proto to proto work.

There is something wrong with our general approach to programming. Majority of "real" work is writing total functions (in the sense, non-recursive). Yet, we very much insist on using Turing-complete languages everywhere.

I suspect we would be better off if we used total domain specific languages for the majority of the work (data transformations) and TC languages only sparsely, where we cannot avoid recursion.

This is somewhat what you do when you write SQL, but SQL is an OLD language and it doesn't compose well with other things.

This approach is exemplified by for example Facebook's Haxl, which is a functional domain specific language for filtering content. So you write the domain code in a specific language, which is easily transformed/compiled.

(Actually your TC and your DS language don't need to be different syntactically, they can be both based on a common functional language.)

Interestingly, the interviews are very much based on TC language notions.

Sounds lame.

TIL.