I agree with the basic sentiment of the article, but the question that always pops in my mind is, based on your real life work experience, what kind of (simplified) question would you ask in a 60 minute interview to gauge someone's ability to write, say, a distributed service?
It goes without saying that 60 minutes is too short a time to ask someone to solve a real life business problem, but real life business problems tend to be broken up into many small problems, which can in turn be simplified and presented to the interviewee.
The discussion I've been having with colleagues is how to do precisely this - eschewing the typical leet code/hacker rank problem, what problem can we come up with that has high fidelity to real life work, without being too complex for the 60 minute interview? I definitely think this is possible, and normally you get to that kind of question by working backwards - what is a real life feature I'd implement, and how can I ask a version of that during an interview. One example would be a graph of similar categories. Categorization is a common issue, and graphs are a common data structure.
Side rant - I've seen a lot of hate for things like data structure questions and algorithms associated with data structures. It's definitely possible to have an entire career of programming where all you do is build CRUD endpoints and design relationships between objects, but sitting down and learning about these amazing data structures that have been refined over decades of work can seriously improve a lot of code. A common problem I've seen is people building rigid object hierarchies (by composition, not inheritance) where a tree would have been way more flexible and easier to understand.