That wasn't my experience at a FANG - the joke was that we spent most of our time moving protocol buffers around. Very rarely encountered anything as challenging algorithm wise as leetcode medium.

On the other hand working at FANG encourages developing soft skills (cross team wrangling etc) that no amount of leetcode would teach you.

That's why I don't work for FAANG any more.

What do you consider engineering problems? Many engineering problems aren't about algorithms but rather solving a real world problem.

Algorithms are just more tools to solve real world problems. Algorithm questions might be better if they were geared toward application rather than implementation.

This was a huge realization that I recently had. I didn't study CS in school, so the past couple months I've decided that I should learn the fundamentals in hopes of becoming a better developer. Learning about data structures and algorithms has definitely changed the way that I look at the world. It's nice to have knowledge of different types of problems and how to find solutions to them. Just a couple of hours ago I used a greedy algorithm to choose how to best structure my study time over the next week.

You usually don't need to re-implement an algorithm.

But very often you have to understand which algorithm to choose. Then you can pick an existing implementation.

In interviews I conduct I gladly allow to read the wikipedia page with a reference implementation (say, for the mentioned Dijkstra algorithm), or pick an implementation from a standard library of a language (say, for a priority queue). What I'm looking for is a conscious and reasonable choice of an approach, and understanding its trade-offs.

That's great! The interviews you conduct are atypical because allowing open book is most definitely not the norm for the format that forces candidates to Leetcode in order to practice.