In most cases(in my experience), i can always lookup details of some algorithm when i need it. Admittedly, my job doesn't require me to design algorithms, but implement some not so readily available ones sometimes.
But also I'm not sure how common it is to have interview questions such as "delete a node from a balanced tree" where they actually expect you to get that right vs just see if you get the basic idea. I've never run into it. Perhaps many people on hackernews work in silicon valley and that is more common there.
Intuition isn't understanding and ignorance isn't expedience. I think your choice of the word craft really homes in on what we are supposed to be doing. Building things well with craft. There is a place for duct tape and wire, but the craft of software matters.
I have done some optimizations in the past, and I think what the author is getting at, is that it's not too late to learn about the specific niche algorithm you're dealing with when you have it in front of you.
My favorite rule about optimization is one I learned from a former colleague. First you measure, then you find where you should look, then you optimize. Without measurements you're maybe doing more harm than good. And if you look up different solutions when you know what you're trying to optimize it's usually not that hard to find a better replacement. But you don't need to have the exact solution in your head for this.
What you do need is the rough cursory knowledge of algorithms that grants you the ability to see more quickly where you're losing precious cycles. E.g. knowing the tradeoffs between linked lists and vectors.
I've seen way to many tools that could be sped up by a factor of 30-100 in an afternoon, that I really have to agree with you that a lot of people don't know their craft. I just don't think rote memorization of algorithms Q&A is solving any of this. Take home exams IMHO are a much better measure. I can ask people why they chose a certain data structure, why they didn't do it another way (if I have an idea of what could be better). That gives me much more of an insight in how people think. Not how well they memorize things.
Time is hard. I don't like to deal with localizing time, formatting time, or converting time. Instead I use a library [0] to solve that problem for me. Because while I may need to localize time - localizing time is not the problem I am trying to solve. It's just a roadblock in the process of solving my actual problem.
Present a candidate with a simple system with three levels of middleware API and have them plumb a newly exposed low-level value up through all three levels to the high-level API. This is unfortunately 75% of professional software development.
This is often the case, but not always. When you know things about the input data you may be able to get better performance than the generic sorts built into a language. Or, when you know more about sorting algorithms you may be better able to choose among the available sorts/sort options provided by a language or library.
I don't understand the attitude of people willfully choosing not to understand their craft better. Yes we can all be mediocre by just using libraries that other people made, but
1. Someone has to make the libraries 2. The average quality of software is not very good, its very often slow (which is astounding given how fast the hardware is) and buggy, often with disastrous consequences, so we should all be striving to do better than average.