Not every day, but my experience is at least every month-quarter. And since you're not primed like in an interview context these ideas need to be inside your wheelhouse to spot them within a business context. I would not describe myself as particularly technical for my org and in the past year I've made use of the following at work:

-Depth first search

-Binary Search

-Topological Sort

-Dynamic programming in a graph context

-Union Find

-Merkle Trees

-Fenwick (binary indexed) trees

Maybe I'm in an unusually technical area but it doesn't feel that way talking to my colleagues.

Yes, and there's plenty of times in my work where I've put algorithms to good use.

But out of all those algorithms how many could you regurgitate onto a whiteboard given 5 minutes to do so?

Knowing the use of each algorithm is good enough. You don't need to know the implementation until you want to use it. And nowhere in your day to day work is this going to be with no internet access or reference.

So why do interviewers suggest this is the case? Why aren't they just happy with you describing how a Merkle Tree can solve a particular issue. Why do you need to write that down?

Should companies set their hiring bar to match the average difficulty of problems they encounter, or should they try to find people who can solve their difficult challenges?

Is your view of programming that good programmers spend the majority of their time writing boilerplate code or doing grunt work?

Your average software developer isn't going to be solving the most difficult problems.

My view isn't that good programmers spend the majority of their time writing boilerplate code. But my view also isn't that the average programmer _isn't_ doing that.

I'd expect way more demonstrated knowledge for an interview in a higher level role than an mid level developer role. But the higher you go the less you actually need to demonstrate that. Why?

> Because the most common say to day issue is needing to think of an algorithm on the spot...

Are you trolling? Everything that you do as an engineer is coming up with an algorithm.

Algorithm is how you solve a problem, how you think about constraints and requirements.

You're being pedantic. You know what I mean.

There's plenty of algorithms I know and I can see relevant business contexts to use them in. Do I know all of their implementations off the top of my head to regurgitate onto a whiteboard? No, because I don't need to. When the time comes I will just look that up. The easy part is the implementation. This isn't a school exam testing your memory.

When was the last time somebody asked you to implement some text book algorithm?

All the FAANG interviews I had were about some leetcode problem where you had to be familiar and use some algorithm, not write it from scratch.