Not needing to code Floyd–Warshall on the job is not equal to "high-level apis and glue code". You can totally recognize the opportunity for the correct data structure or algorithm despite not having them all in your head all the time. That's exactly what a good software engineer does.

But if you think you can code up any algorithm in any domain on the fly I'm sure I can find some good interview question for you. I mean there's only like 5 algorithms in the world, right? I'm sure you have at least all the volumes of Knuth memorized... And if not, you must just be writing glue code ;)

Because I've seen the algorithm more recently than "school" but perhaps not "last night while feverishly cramming so I can forget it in a week". Because I've probably solved the problem I'm looking at before, if not a neighbor close enough to get me in the ballpark, and I am never going to be without a search engine for the actual triviality that is the solution once that is identified. Because it is. It is triviality that has been turned into a measuring stick for one's technical coupling equipment by folks who have no better metric by which to evaluate. (And, to be fair, it's not the worst metric. It's also not a great one, though.)

The example that comes to mind first: I've written a topographical sort half a dozen times over the years. I recognize the problem set that it applies to on sight. And I do not have enough time in my ever-shrinking lifespan to bother to memorize how to write the thing optimally, though if I squint a little I'll probably get something that's okay if I sat down and spent half an hour with a REPL. (EDIT: went and looked up the last time I did it, and it's actually pretty good! Though bounded for `n` because I knew `n < 300` so I just used the call stack.)

So I'm not going to shed tears that I look it up when I run across a case where it's appropriate. Does that mean that on the movie set of a never-gonna-happen where I absolutely must create a satisfaction plan for a dependency tree that runs in absolutely minimal time, the bomb's gonna blow up and kill the President? Yeah, sure, but I live in the real world.

It doesn't happen a ton, because if we're being honest most jobs even at highly scaled companies are pretty Lego-y these days--but probably once or twice a year, yeah, I go "oh, that's an XYZ problem" and Google how to implement the optimal solution (or find that there's a package for it already).

Recognizing the shape of a problem is a skill. Calling to mind the exact algorithmic solution to that problem is a different skill. One of those two things is something that Google can do. (We are nearing a world where one of these two things, GPT-3 can do.)

This may probably be the worst logical analogy I've ever read on HN.

The suggestion is that when you need an algorithm (cancer) you will look it up (quit smoking); the initial problems that make the analogy rather clunky - the algorithm is something you want whereas cancer is something you don't, and looking up the algorithm is something you start to do whereas quitting smoking is something you stop (smoking)

But of course there are other things that make the analogy inelegant - the longer you smoke the worse the cancer gets, but not looking up the algorithm for years does not make the algorithm any harder (here there is some room to quibble since unfamiliarity with the algorithm for some years may make implementing it more difficult but that is a different level of surety than the smoking worsens cancer level of surety, and at any rate difficulty to implement is not exactly the same as harder)

Finally the extreme nature of the analogy seems more likely to cloud judgement than otherwise.

I'm not saying you're not good at what you do, just saying you are not getting a job in this philosophy department with that level of argumentation buster!