While I don't think that whiteboarding aho-corasick from scratch is a good quality interview. I don't think algorithms and data structures are useless or impractical. IMO a basic understanding of the main data structures is important and useful in the day to day.
Granted, some applications will involve more or less use of data structures/algorithms than others, but if you discount them completely you mark yourself out of a whole subset of work.
I would want most of my fellow employees to know what a trie/binary tree/linked list/vector/array/etc is, and I would want them to know how to evaluate space and time complexity of the code they write. What is a good style interview for that is an open question, but I don't think the content is impractical.
By all means, spend your time however you like. I just think it's unfair to call knowledge of these sorts of things "impractical". Impractical for whom?
Those two, yes (and vectors really only apply -as such- in C++), but the rest? It depends (the best answer to every conundrum).
I write consumer/developer software; not ML or Big Data Mining stuff. My work is generally in device control, user interface, SDKs, APIs, etc.
That means, that, in over thirty years of writing software, I have encountered exactly 0.000000 binary trees. BTW: Binary trees and linked lists can be an issue in parallel-type programming. We had some image processing algorithms we did that used similar structures, and we had to be very careful. We often had to back out optimizations.
Writing consumer software has issues that don't seem to occur to folks writing engine software. These are things like localization, security, adaptive user interfaces, aesthetic design, information architecture (hoo-boy), responsive controls, branding, testing (all kinds of testing), etc.
That "information architecture" one is a big deal, and almost everyone falls down on it. This is most obvious in settings. Engineers design settings to match the underlying architecture, and don't worry too much about how they will be perceived by users. The result is the infamous "Find the hidden setting" game. I just went through that, yesterday, helping a friend set up a Zoom meeting. Fun! I also just went through it yesterday with my wife, and her Mac. Apple has started to segregate settings the same way, and there be dragonnes.
Testing is another big one. Everyone is fixated on automatic testing and unit tests. If a project comes with a bunch of unit tests, then everyone thinks it's "high quality."
Also, if we write device control, or a lot of communication software, unit tests can be worse than useless. Usability and accessibility testing are also something that can't really be automated.
Shipping software is really boring. There's a lot of "'snot mah chob, man!" stuff involved, that, nonetheless, needs to be done by someone, or we end up with steaming piles of crap.
Some of that involves the programmers directly. For example, do we habitually autodoc document our method headers and class/struct definitions? Do we use tokens and localizedVariant calls for all displayed text? Do we follow good secure programming practices from the start? How would a blackhat use this function I just wrote? Do we throw dependencies in as a first resort? Is that good, or bad? Do we know what that dependency we just committed the company to does? What's our testing strategy? How will we integrate this, and when? etc.
Also, power usage. That's a big one, if we do mobile or embedded software. Sometimes, highly optimized code is the worst code to run, as it can drain the battery, or end up with really strange race conditions between chipsets.
That's practical stuff. When you're a one-man shop, like me, you get to deal with all of it. I was also quite involved in all of it in my last job, where we were a huge, global team, supporting some pretty intense hardware products.
> Those two, yes (and vectors really only apply -as such- in C++), but the rest? It depends (the best answer to every conundrum).
I think other systems langs make the distinction, Rust does also, this is what I've been doing at my day job lately.
> That means, that, in over thirty years of writing software, I have encountered exactly 0.000000 binary trees.
I've been doing it for a third of that time and I've encountered binary trees and all kinds of other data structures a bunch of times. I don't do any big data or ML stuff, I was writing React frontends for about half of that, the last few years it's been systems programming with Rust; I still encountered these types of structures writing JS though.
> BTW: Binary trees and linked lists can be an issue in parallel-type programming. We had some image processing algorithms we did that used similar structures, and we had to be very careful. We often had to back out optimizations.
When sharing any memory between threads or tasks you have to be careful, I'm not sure there's anything special about binary trees or linked lists. Consequently Rust makes this sort of thing very nice.
I'm not sure how to respond to the rest of the comment. Personally, I'll take an expressive type system over a comprehensive unit test suite.
I'm not discounting your personal experience but I find it hard to believe you aren't encountering these types of problems, unless you are but just not noticing it. Curious about what kind of 'optimized' (optimized for what?) code is 'the worst'?
edit: I just re-read this and realized the tone was a little aggressive, I don't mean to come across that way, my bad.
I ran a C++ shop for 25 years. We wrote “pipeline” software for image processing. REAL heavyweight data processing/DSP stuff. Optimizations were crucial, and we often took advantage of things like GPUs, and threading.
There be dragonnes...
I learned that explicit threading is a scary place, full of surprises.
Nowadays, I write in Swift (which I love -I think that Rust is similar). Explicit threading is barely supported, which is just fine, by me.
I can get defensive, because I have been treated rather badly, simply because of my age. No one ever bothers to look at my portfolio. They just start with the condescending drivel, sometimes, even accusing me of “faking” ten years of commit history, hundreds of thousands of lines of code, dozens and dozens of repos, hundreds of pages of articles, documentation, prose, and training modules.
It was exactly this kind of behavior that convinced me to not even bother trying to get work.
I’m not arrogant. I’m actually a really decent person; warm, compassionate, and a great team member. My LinkedIn profile is jammed with testimonials. I worked on a team with some of the finest engineers and scientists in the world, and had their complete confidence and trust.
But that doesn’t mean a thing, if I can’t give a proper answer to a “Draw Spunky” test.
Coding tests; at least Codility/LeetCode style, are now pretty much worthless, as there’s an entire industry devoted to helping folks pass them.
I just love doing what I do. It sounds like you do, as well.
Every hour I spend, practicing for interviews, is an hour I’m not spending, learning new, practical stuff.