I agree with you, and it's something I'm trying to influence where I work, but the reality is that knowing these things will help you get hired.
In preparation for an interview, you should implement common data structures and implement common algorithms, all while understanding their space and time limits. It's basically like studying for a big test. If you pass, you can go ahead and forget most of it.
With all that being said, just because a data structure is included in a language doesn't mean it isn't important to know what's going on under the hood. When and why would you use a LinkedList over an ArrayList? How about HashMap vs TreeMap? Can you identify code that has a quadratic runtime and make it linear? These are the types of questions you can answer once you've gone through the trouble of implementing various data structures and algorithms, even if you forget most of the implementation details.
I get that they're important, definitely. But they are nice to haves, not essential for most software jobs. You can make a decision on which data structure to use based on their high-level definition/documentation, no need to get to fine details.
So the main test on if you can do a job well is based on mainly trivial nice to haves, and not in any way representative of your real-world performance.
You have to remember that it's not exactly trivial from the interviewer's perspective either. How do you determine over the course of a few hours that a person is worth the investment of a software engineer's salary? This is especially hard when you're hiring people right out of school.
The fact of the matter is, people coming right out of school have no real-world experience, generally speaking. While having candidates implement data structures on a whiteboard or recall the exact runtime complexity of a non-trivial algorithm is not going to gauge real world experience, having them solve novel coding problems is a way to gauge their thought process and problem solving skills. This involves knowing when and where to use appropriate data structures, and at least being able to speak to their performance characteristics at a high level.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with you, and it's something I'm trying to influence where I work, but the reality is that knowing these things will help you get hired.
In preparation for an interview, you should implement common data structures and implement common algorithms, all while understanding their space and time limits. It's basically like studying for a big test. If you pass, you can go ahead and forget most of it.
With all that being said, just because a data structure is included in a language doesn't mean it isn't important to know what's going on under the hood. When and why would you use a LinkedList over an ArrayList? How about HashMap vs TreeMap? Can you identify code that has a quadratic runtime and make it linear? These are the types of questions you can answer once you've gone through the trouble of implementing various data structures and algorithms, even if you forget most of the implementation details.
I get that they're important, definitely. But they are nice to haves, not essential for most software jobs. You can make a decision on which data structure to use based on their high-level definition/documentation, no need to get to fine details.
So the main test on if you can do a job well is based on mainly trivial nice to haves, and not in any way representative of your real-world performance.
You have to remember that it's not exactly trivial from the interviewer's perspective either. How do you determine over the course of a few hours that a person is worth the investment of a software engineer's salary? This is especially hard when you're hiring people right out of school.
The fact of the matter is, people coming right out of school have no real-world experience, generally speaking. While having candidates implement data structures on a whiteboard or recall the exact runtime complexity of a non-trivial algorithm is not going to gauge real world experience, having them solve novel coding problems is a way to gauge their thought process and problem solving skills. This involves knowing when and where to use appropriate data structures, and at least being able to speak to their performance characteristics at a high level.