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 ;)

EDIT: I have made it through those interviews. That's not really the point. The way you make it through is by preparing, just like you'd prepare for the test in school. Doesn't show anything.

cool? then that majority doesn't generate the same value as those that do and so they shouldn't get paid as such? i already asserted that?

>Including people working on the most cutting edge software.

ctrl+f to doubt that you know what people working on cutting edge software do. i, on the other hand, do have some experience on cutting edge compiler tech and it is absolutely what i've described. sorry not sorry.

>can regurgitate this is because they just re-read their course book yesterday and they expect algorithmic problems.

great. i'm glad. they're prepared for tasks being assigned to them that exercise those skills and by the end of the half they'll have a deep understanding rather than just a wrote understanding. either way i'll hire them over someone that thinks it's worthless being conversant in the algorithm.

Bro - I’ve made a 7 figure TC, delivered 8+ value, and I still don’t think LC is worth a damn. It has little to no impact on day to day.

But - ok - you know - think that algorithms in software are literally the end all be all. You have some arbitrary standard where I need to remember how to implement fusion trees on the fly. It’s utterly ridiculous.

99%+ of software eng (even the super duper highly paid shit - remember I’m the dude who was making more than a million/yr) is boring ass pipes and glue. You don’t need advanced DS&A. In fact - if I saw some of the shit that I know gets advanced runtimes and gets some good performance metrics - I’d probably rip that shit out because it’s not maintainable by enough people and performance doesn’t fucking matter 99% of the time. Sure - that 1% is interesting but it’s like once a year you go, “huh, might need to crack out the ol’ stopwatch!”

Gatekeeping like a motherfucker. Holy shit.

I think it's entirely possible to memorize algorithms superficially. These types of interviews are selecting for exactly the type of person that is good at that rote memorization, and are otherwise selecting for a very narrow type of skillset.

It's unreasonable to not expect pathological outcomes with such a rigid system, especially when some people are themselves specialized for the ability to game social systems. Nothing is free. There are always trade offs when choosing one approach over another.

I'm sure the companies themselves understand that much, and understand a variety of the tradeoffs involved with the way they hire. What they might not understand is that they are at the exploitation stage of their lifespans. There's an entropy-like process as a company matures and cycles through its workforce which leads it to becoming highly specialized.

My bet is these companies don't understand the various ways in which they're limited, and therefore the ways in which they're limited in filtering candidates. And even if they did, they couldn't really hire any other way now even if they wanted to because they don't have the internal diversity for it, that possibility has long since closed on them.

Well established, where?! In hn discussion boards?!

Just so I understand where you’re coming from, are you not ok with your business collapsing due to lack of workers or are you a manager at Amazon, Team Bondi of LA Noir fame, or in the general retail industry?

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.)

You cover a lot of ground as a coder having skimmed an algorithm book. So I do actually think there's some value in DSA preparation. At the same time I'll admit I don't have any of those things memorized, I just know they are things and can pattern match aka learn when they show up.

You realize the difference when you run into an inexperienced coder, especially a smart person like a quant. They run into a problem and think it's new, and solve it naively.

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!