Other than Wonderlic everything you listed is directly related to athletic ability and are things athletes do on a regular basis. You're supporting my point. I'm saying testing should be directly related to the position.

If someone doesn't need to do binary math or write complex sorting algos from scratch you don't test those, just like how you wouldn't ask an athlete the mundane questions I posted above. You might ask high level questions to demonstrate knowledge of sorting, but not ask someone to implement that algo from scratch.

If someone is trying out for the NFL they're not going to have to demonstrate baseball skills, how their shoes are made, engineering questions about how the stadium is built, what software should be used for the ticketing system, or any other questions unrelated to the position. You have them to demonstrate skills directly related to the talents they need to fill their role, like standard field drills.

But the engineers at FB do need to be able to write sorting algorithms from scratch rather than just have knowledge of sorting. The reason is that the engineers have to be reasonably fungible so that they can be easily moved between projects as projects are started and stopped. So they could easily be tomorrow thrown into an environment where a sorting algorithm is needed, they are the ones responsible (so they'll need to build it, not just have a high-level idea of how to do it), and at FB scale every bit of squandered efficiency is very expensive (if their photo search algorithm, let's say, takes 5% more memory than it needs to, that will end up costing the company much more than their salary).

Yes, if you aren't dealing with CS fundamentals directly in your work, you aren't working on the kinds of challenging engineering problems we face on a day-to-day basis. For example, a coworker applied some arcane number theory to one of our hashing algorithms, saving the company millions and was just recently awarded a patent for it. You can find many other, more specific examples in our Engineering blog. We're a mature product operating at scale so small, but meaningful statistically-significant % metrics gains are actually quite large when it comes to real business impact, and so chasing these gains actually requires a serious academic toolbox.

FB has thousands of employees who write code. I highly doubt many of them are writing sorting algos from scratch. They should know which sorting solves the problem and use an appropriate library.

The same applies to most other low level problems. They should understand the problem and the best practice to solve it. In most cases writing low level solutions from scratch is not the best practice.

FB is a mature company now with a slowed growth rate. They've been dealing with scale and performance for long enough now that it shouldn't be necessary to write all of these things from scratch.

Facebook has pioneered multiple languages and programming API packages. I'm certain they have had to implement library functions "from scratch" multiple times.

I can assure you that the growth rate has not slowed. Do not use the USA as a proxy for global behaviors.

I don't see a correlation between product growth and engineering complexity.

So what would you do instead? Being able to write some code on a simpler problem vs real-life code is an equivalent of a 40 yard dash vs rushing for a touchdown (or whatever). Being able to find special cases, or design, or figure out a simple algorithmic puzzle is the equivalent of the same for larger problems. The alternative is letting the candidate talk about their projects or to have some hand-wavy design exercise, something too easy to BS.