[seanwilson]

> On the rare occasion that these coders need to worry about algorithmic scaling, they will re-use an implementation from their fine standard library or adapt one from another source, without turning it into a brain exercise of reasoning about and building the whole algorithm on scratch on whiteboard while a bunch of strangers are sitting there judging you and prompting you to explain your thought process as you go).

> It's nothing to do with whether you have the fundamentals of basic algorithms down or whether you can select an appropriate algorithm for a real world problem.

I never said they should be able e.g. code the algorithm from scratch on a whiteboard.

I'm saying you should be able to explain the basic principles of e.g. an array, a linked list, a hash table and a binary tree, and where each would be appropriate to use.

If you don't know these basic principles, I find it very unlikely you would know how to select library components or adapt algorithms that scaled to modest datasets.

[clarry]

> I'm saying you should be able to explain the basic principles of e.g. an array, a linked list, a hash table and a binary tree, and where each would be appropriate to use.

I think most of us agree with that. But that's beside the point, because that's not the algorithm-heavy interview people are complaining about big time.

[seanwilson]

It depends what you're describing as algorithm heavy. Do you have any examples?

I've seen people arguing you shouldn't have to know how a linked list, hash table or binary tree work. I think every programmer should know these ones. I think having to describe how quicksort works is getting too much, but knowing e.g. some search tree and graph algorithms might be appropriate depending on your domain.