Honestly I don't care about the algorithms and data structures used for string search, or event sourcing for that matter. I use that code to build stuff. There's a vanishingly small portion of the population devoted to these problems, and indeed most of those people are probably working on search at Google or something similar. Calling them "foundational" is a joke. They're important, absolutely -- we all use them daily. But expecting every developer to be able to implement a search algorithm? That's the kind of dumb interview question I'd walk out on. Programming is much more than algorithms. Algorithms are the tools we use to build problems. You don't expect a tradesman to build his tools himself, do you?
Algorithms aren't foundational, in my opinion. Once you understand the syntax of programming, you can start learning about the applications of that syntax, which for 99% of developers rarely ends up in the shape of an explicit algorithm. It's not all bad, debugging is foundational for sure.
I'd place a person's debugging skills, their ability to predict bugs, system design, knowledge of common (applicable) libraries (more so knowing when to use them, not method signatures), and perhaps even ethics above algorithms. Probably many more but there's a couple to start. Having never needed to build my own sorting algorithm in 14 years of coding, I'm pretty confident I don't need an engineer who can do that, either.
Foundational means the core set of principles/theorems/abstractions underlying everything else. Saying that debugging is foundational is like saying that knowing how to use a TI-89 is foundational for math. You don’t need a calculator or a computer to do math or computer science.
In the end you choose what you spend your time learning and if you decide that all this computer science is not worth it then that’s fine. But you will objectively become a better programmer if you understand these things. Even if you never use any of it.
> Having never needed to build my own sorting algorithm in 14 years of coding,
Neither have I. What I have had to do is recognize when I could do what I needed to do without sorting the array, understand various requirements when I'm writing comparison functions, understand why std::list::sort exists when std::sort is right there, debug a stalling mapreduce job, recognize when a library I'm using has done a stupid and written an intrusive data structure that sorts in N^2, etc. Are you seriously claiming that you'd be able to do any of that if you didn't know how sorting algorithms worked? If those things aren't in the documentation, or if you run into the intersection of that thing and some other issue, you're hosed unless you know the math.
For that matter, why are you so focused on sorting? You know what I have to write all the time? Tree and graph traversals. Why does it matter if I use a stack or a queue if my traversal will visit every node anyway? Why can I get away without maintaining a set of visited nodes in one case or the other? Hell, I have to implement something very much like a toplogical sort once a year or so. That's not something you'll ever learn by groveling over for loops in fifty languages.
I agree that you rarely need an explicit "algorithm". What you do need, regularly and consistently and on a basic level to write correct code that is usable in the real world, is knowledge of algorithms. In a perfect world everyone would know from reading the docs and from staring at stack frames that their code gets slow when they use particular data structures and libraries. We do not live in a perfect world. The engineer that cannot write a single sorting algorithm is not the one that just uses library functions for everything and is fine in the end. The engineer that cannot write a sorting algorithm is the one that writes a jumble of for loops and you improve runtime from eight minutes to eight seconds by replacing it all with hashes. The engineer that cannot write a sorting algorithm is the one that designs an API that fundamentally requires server-side session state that grinds to a halt at ten QPS. These are people that I have worked with. In every case the fundamental issue was that they had "started learning about the applications of the syntax" and never studied formal CS theory.
> The engineer that cannot write a sorting algorithm is the one that designs an API that fundamentally requires server-side session state that grinds to a halt at ten QPS
I've come cross more than a few "can write a sorting algorithm" engineers that nevertheless design APIs requiring server-side session state, or that have gone ahead and implemented a sorting algorithm embedded in the server-side HTML template.
Of course it's not sufficient. I don't even think it's necessary. But, generally speaking and in my experience, formal algorithms knowledge is incredibly useful, and you are at a significant disadvantage if you do not have it in your toolbox.
I was pointing out that a specific correlation you mentioned wasn't particularly robust, and certainly didn't amount to the causation you were implying.
Perhaps I should have made my point more explicit by noting the existence of counterexamples - engineers that design and implement good APIs without any particular knowledge of CS or the implementation of sorting algorithms.
You actually are conceding my point when you admit that knowledge of algorithms isn't even necessary.
Depending on you work you don't need to use it again. I have not used it for a decade. I somewhat remember the theory. For interview i can just memorize it.
You seem to have a nonstandard definition of "foundation". It doesn't mean "introductory" or "beginner"; it means "what everything else is built upon".
Ok. I'll tell you that I want my API to never take longer than 100ms as part of our service level objective. Code you contribute to our system is consistently failing to meet our objectives. Make it faster.
We're designing a game engine. Our objective is a smooth 50 frames per second. We want to do dynamic lighting, destructible voxel terrain, the works. Code you're contributing is consistently dropping our frame rate. Make it faster.
We make financial trades in some secondary market. Our goal is to ensure all transactions are atomic and take less than 100ms to complete. Code you're contributing is consistently failing serialization of the transactions leading to failed trades. Fix it.
These are but a handful of examples where algorithmic knowledge is useful. There are more. Without algorithmic knowledge you'll simply be rediscovering everything on your own, making up new things that don't make sense, and struggling to stay useful to your team.
There are programming tasks that clearly don't require it. Most web development jobs for SMEs are competing on price with other contractors for a commodity resource: time. For those jobs a pragmatic knowledge of the programming language, tools, and libraries is sufficient: the problem you're solving is valuable but low-effort where time is of the essence. The faster you can pop out a web app and move on to the next one the better.
These things belong to the same class of skill: programming. However I think algorithms are still foundational because even in the latter case performance and correctness still come up in less critical areas: time to first paint, real-time updates, etc. Even a cursory understanding of the difference in magnitude between O(n) vs O(n²) is useful if you understand that using the right data structure will solve 90% of your problems.
> Once you understand the syntax of programming
Syntax is trivial. semantics are what matter. Take Hy as an example: it's a lisp syntax. But a Hy program is only a Python program. ReasonML takes this idea even further allowing programmers to work in whatever local syntax they find useful.
