No, but I get to write real code at my job.

They're not the same. I've never used Dijkstra pathfinding at my work, but I and yet, I seem to asked questions about it in interviews pretty consistently.

The goal isn’t to make sure you have memorized a graph algorithm. The goal is to identity people who can convert a scoped problem definition to code and to identify people who can convert a vague problem definition to a scoped one.

This can be beaten by brute force by memorizing a huge amount of material, but that isn’t the goal. It isn’t like the interviewers think you’ll need to implement their question in your day job.

Half the leetcode becomes obvious when you actually solve engineering problems as a part of the job.

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.