What are some examples of the basic concepts?
You want someone that can easily talk about the pros & cons of using different data structures or algorithms to solve problems. Who can move up & down layers of abstraction without getting confused & lost. Who can hide complexity to make clean, readable, maintainable code.
Many people, especially junior/less experienced engineers, have only memorized solutions to problems. They don't have a strong toolbox of solutions and the experience to know how to apply them (and evaluate the options).
A good problem solver is methodical - they don't just guess at random data structures, they identify what the requirements are of the problem and then choose the appropriate data structure (or compose one) which meets those requirements. They'll have a process, which may be different than your process, that they use to break down problems into smaller, solvable pieces.
It sounds to me like we are forgetting all the other important things.
Like how easy it will be to replace that data structure if maybe the requirements changes? Do we really need to optimize this thing fully now? Or maybe for the next 5 years to simple solution will be more then enough? And so many other questions.
A lot people need to think longer then 1 minute to come up with a good solution or maybe you need to try or maybe you need to learn something?
Isn't that what we actually do? How often did we think that framework X is the best but after a while it was not that great? Don't we need to play around with an API to understand it better? Or let me read about that and tomorrow we can talk about because last time I was doing something with binary trees was in university because in the real world I don't need it that often because yeah we have other important things to do.
There's like 5 basic data structures. Choosing the right one based on desired functionality and explaining why you picked it, that's just table stakes.
I'm not paying you six figures to write software professionally if you can't tell me when to choose a linked list over an array, and apply that knowledge to solve a problem.
The right data structure does not only depend on performance. I can write you the most performant code in the world if you want to but it will take 5 years. Oh we only have 1 month? then sorry for now an Array will do.
In most cases you pay someone for the skill to learn new things fast and stay motivated. Why? Because in good companies you want to hold on to the people for a long time and this people need to educate themselves. Why? Because even the basics depend on the context they are in and languages, frameworks and runtime and other stuff will change over time. 20 Years ago memory space was a problem? Do we even think about memory now? Not really unless your working on some embedded systems.
1. Those are the building blocks of software, and
2. They don't stop being useful when you move from domain A to domain B
What I said was that "movement" was a building block of life and your response was "no, cause if you do polka-STYLE movement while trying to lay bricks, you'll FAIL".
Right, but what they both have in common is movement. The fact that you felt the need to add style is exactly why I'm correct.
uh, not really.
In my world majority of performance issues comes from N+1 queries, I don't need people who can do crazy things with trees. I need people who write testable code, actually write tests, care about security and take responsibility for their code/refactor.
Of course you can argue that N+1 query fits algorithms part, but very often algos mean leetcode
But, since "you guys" always talk about data structures then I'd want to ask - how often do you use something fancier than literal basics?
I've had plenty of candidates who don't know what data structure to use in that example, and they just start randomly listing things...tree, hash, linked list, etc until they stumble on the correct answer.