I disagree with the author's explanation as to why all questions are algorithmic. I suspect the real reason is due to the US dominance in tech and the popularity of algorithmics in US academia. Indeed the parts of computer science to do with logic, formal methods, semantics, mathematics of program construction etc are, I am told, often described in the US as "Eurotheory". This is a great shame. A new graduate arrives at Google fully trained in algorithms as mandated, but is unlikely to need to implement any of them during their career. It is far more likely that they will need to glue existing systems together, consume APIs, author APIs etc. "Eurotheory" would much better prepare them for this.
As an example, consider that we could be asking questions on API design: get candidates to work through their semantics/axioms (introductory forms to create objects, methods to transform and eliminate them). Get them to write out high-level testable properties such as the way objects compose, associate, commute etc. Using types to enforce invariants etc
Yes, and the algorithmic tests are highly biased towards those who've focused on that (either through academics or by self training afterwards) - and a miss on these questions still doesn't tell which is the correct story. Then again, this might not matter. Firstly, everybody knows these types of questions are to be expected so everybody cab prepare. Secondly, the problem (from an employers perspective) might not be the false negatives, but the false positives.
This in turn points to that we might try to generalize this a little bit too much, with assuming there're generally applicable ways for software developers but rather we need to adjust the process depending on the type of software development context. If you're developing a web service of minor scale, then algorithmic questions might be stupid (because the knowledge needed is rather one of network, async, web and structure rather than solving math problems), but they might be relevant for Google (where they are might be relevant because they search for developers with that mindset and who can use that mindset to come up with and solve big problems in a certain way - I don't know because I lack insight into the developer strategy at Google).
As engineers and developers my experience is we tend to love to generalize, even when it's not wise to do so.
As an example, consider that we could be asking questions on API design: get candidates to work through their semantics/axioms (introductory forms to create objects, methods to transform and eliminate them). Get them to write out high-level testable properties such as the way objects compose, associate, commute etc. Using types to enforce invariants etc