3 ms·
> 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 o
by seanwilson 7y ago
> 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 7y ago> 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 7y agoIt 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.