Item — HN Reader

Data structures, complexity, algorithms, abstraction, encapsulation, ...

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.

2 comments

Why do we focus so much on data structures and algorithms?

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.

This is about fundamentals - e.g. when to use an array vs vector vs linked list, and I'm not talking about optimizing performance. I'm talking about functional requirements and picking the data structure with the correct behaviors to support those requirements.

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.

If you programming language has this concepts and even then this will highly depend on the programming language you are using.

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.

I’ve never seen a linked list in the wild in my entire career (5 years). I work on crud web apps, etl jobs, frontend etc. Actually, now that I think of it, I’ve never even seen it in OSS libraries and I contributed to a few.

> Why do we focus so much on data structures and algorithms?

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

1. Its like one building block from 100 blocks 2. Yes they do. If you try to write C++ style data structure in java you will fail. If you try to write JS style algorithms in rust you will fail. Different programming languages and databases are optimized for different data structures and algorithms. You can normalize the shit out of an Oracle Db but if you delete the 'statistics' DB then you have a problem no matter what the data structure.

Thank you for making my point.

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.

>You want someone that can easily talk about the pros & cons of using different data structures or algorithms to solve problems.

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 was elaborating about fundamentals. Things like "we're going to need random access into this list, what's the right data structure?" and the candidate should be able to say "use an array or vector" and explain why.

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.

How often do you use vectors, linked lists and trees at your job?

Often.

There's a saying I've heard multiple people say in the C++ world. If you use something other than vector, you need to justify it.

That's because of the way modern CPU's are optimized.

https://www.youtube.com/watch?v=YQs6IC-vgmo