On the off chance that you'll look back and see this, I'll response. Your implication is that data structures are algorithms, and while that certainly may be true, both traditional computer science curricula and hiring tech companies make a distinction between the two.
In the latter case, what they call algorithms usually tend to be similar to the kind of "brain twister" problems that Microsoft was famous for.
In the former case (academics), data structures include things like stacks, queues, deques, linked lists, and on to graphs and trees. Whereas algorithms are specific procedures carried out with data structures, like sorting and searching, and dynamic algorithms. And then on to much harder stuff, like FFT.
My point is simply that I feel comfortable creating stacks, queues, linked lists, graphs, trees, etc., whereas when someone asked an open-ended algorithmic question to be solved on the white board or phone, I struggle under the pressure and gazing eyes of multiple interviewers to solve these problems (whereas I do fine in my own environment with only the pressure of finishing a job).
>Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
I completely agree with this. Which is why all the LeetCode interviews always struck me as odd. They focus on algorithms, not data structures, which is exactly what you don't want to do out of the gate, most of the time.
I suppose, if you don't know algorithms at all you wouldn't realize when it is either
A) an exception to the rule
or
B) A time where you need to lean into specific algorithm for X, Y or Z reason
However, you can teach algorithms in relatively short order, I have honestly found people grok which data structures to use less easily, though its all anecdotal
These are all well and good, as long as you remember not to blindly live by them (which you'll often see people do with advice from authority).
> If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
I'm not sure what the author wants me to take away from this? Data structures and algorithms should very much both be taken into consideration, although I'd agree that "it all starts with the choice data structure".
Key word here was "front-end". Algorithms aren't usually featured as often there. Before we break out the broad brushes, lets not paint all programming jobs as requiring the same skills.
[1] Eric Lippert summed this up quite nicely:
>> Does not having knowledge in Data Structures really affect one's career in programming?
> Well it certainly will prevent you from getting a job on my team. But like I said before, programming is a huge field. There are lots of kinds of computer programming that don't require knowledge of data structures.
As someone with no formal background in CS, I was unexpectedly thrown into the world of web development 3.5 years ago. All of what I have learned has been self-taught with the help of books, tutorials, trial-and-error, googling, etcetera. Something I have frequently encountered along the way is a call to learn data structures and algorithms. So far I have only glimpsed the tip of the iceberg with that topic, just enough to realize how immense it is and how much effort it would take to internalize it. Basically I am on the fence about whether or not to plunge in headlong. Specifically, I am interested to know how your knowledge of data structures and algorithms has helped you to do the job that you do.
On the flipside, while I am intellectually fascinated by the idea of data structures and algorithms, I am kind of put off by it as well. The reason being that I find programming to be an extremely creative (and therefore enjoyable) activity, and part of me thinks that acquiring this new knowledge will detract from that. For example: if I am to get from point A to point B and realize that algorithm x will do the job, the process of creativity and discovery between A and B has been replaced by the act of implementing algorithm x. While from a pragmatic standpoint this latter is obviously optimal, from a creative standpoint it is not.
About algorithms: It very much depends on the thing one works on, whether one ever needs to look up what a good algorithm is for a problem, which needs solving. Often it is more about how to put pieces together, using APIs, building an API, making a service, etc. Similar for data structures. For most you only need to know the basics like when to use a hash table, when to use an array or whatever of the data structures that are often available anyway in the standard library of the language.
This even more diminishes the gains that engineers get from their expert knowledge.
Usually only when in a position to develop something ground up, does the expert knowledge of data structures and algorithms come into play.
Algorithm and data structure questionaires rather seem like mathematics in many cases. A filter to weed out people, but not often of use at the job.
Obviously I might be biased due to personal experience.
Only starting with algorithms bugs me. A focus on data structures seems much more natural. (On the other hand, data structures are intimately tied to algorithms. What would a red-black tree be without insert, delete, look-up?)
in all seriousness, algorithms and data structures are essential to computer science theory. When trying to get a job as a software engineer, technical interviews will mainly be problems about algos and data structures.
I think the guide to asking questions on Math, Algorithms and Data structures is to ask real world problems which will require you to use these problems.
Its like Math Vs Physics. You can learn the pure math there is out there, but unless you start studying physics you don't quite see how those concepts are applicable to the real world.
Similarly, its simple to ask these questions to a programmer. Give him a real world programming problem to solve, and then see how he uses the concepts from math and CS to solve them.
A very simple example of the complete divergence between "algorithmic" thinking and "software engineering" oriented thinking is explained in this blog post [1]. You cannot, for example, TDD your way to writing a sudoku solver without figuring out the basic math. The line below is an indication of not-like-me, there is no guarantee that doing the first part well (data structures) means you can do the second one well (unit testing), but vice versa too.
> where the person can wax on for ages about obscure data structures or algorithms, but you ask them something simple (What sorta unit tests would I write for this?
And
> I expect its the same reason google asks (used to?) everyone about red/black and b trees. Same thing, just levelled up a level.
This is quite presumptuous. After all, even the folks who actually invented these data structures went through many, many iterations of failed attempts at data structures before finding out that a red/black tree or a b-tree is the right "problem-data structure" fit. Does their previous failed attempts mean those people didn't know what they were doing? These data structures were iteratively and slowly refined into what they are today: does anyone believe they just "struck" the inventors as the right structure for the problem at hand?
Suppose the "right" data structure is more complex than a hashtable. How often are you running into this data structure in your code base? If it really is a lot, you PROBABLY know how harsh it is to judge a candidate by their inability to come up with the appropriate data structure for something more advanced than a hash-table. Don't believe me? Go and look at the many open source projects you use at work today. What is the most advanced data structure you see there? Now ask yourself how much value the programmer has provided you by creating that project? Would you reject that person if you found out their data structure knowledge maxed out at the hashtable? (Of course, if you are actually some company where the impact of the correct choice of data structure can be directly observed on your bottom line - you are already an outlier. What are you doing dispensing generally applicable advice?)
And lastly, based on what I see in the comment, suppose the data structure is more complex than a hashtable, say a tree. Would you ask whether they have used/maintained tree data structures in their code before? If they have not, will you chalk it down to lack of exposure, or lack of smarts? If you are keen on seeing if they can write recursive code, surely you have some simpler ways to test that?
Whatever ability you THINK you are gauging by choosing the candidate who can do a spontaneous problem-data structure match in an interview environment, it is more likely you are just optimizing for the time you can spend on a given candidate and then justifying your decisions based on their failure to answer "a simple thing such as X". There is an excellent chance the candidate could go out of the office, spend a few hours thinking about it deeply, and come up with a clever, maintainable solution to the problem using neither a hashtable nor the data structure you have in mind. They may have failed to meet your expectations, but there is a not very small percentage possibility that this says more about the interviewer's time constraints rather than the candidate's abilities.
Not that you are wrong for you opinion, but I feel differently. My data structures class was all programming, essentially just the professor writing code on the board for a linked list / trie / etc. after briefly describing it conceptually, and then having to implement the data structure and perhaps solve a problem with it for homework. My algorithms classes were all proof based / theoretical (the most applied problems asking you to come up with a "novel" algorithm to solve something, but still written). I felt cheated out of an actual class once I realized my data structures class could have been designed the same way. Coding the algorithms is usually the trivially boring or frustrating part to me; it's the actual design or concepts that I enjoyed.
People in these arguments always talk about the algorithms, but I think that entirely misses the point. It rarely is about the algorithms themselves, but, rather, it's about the data structures.
One is obviously tied to the other, but what I mean is that many slow apps are slow because the people just used the wrong data structure. Sometimes it's as simple and silly as using a list and constantly iterating over it instead of using a dictionary/KV-map. I think the idea with having people know about "algorithms" is to get them in a state of mind where they will automatically pick more appropriate data structures. I really don't remember how to implement RB-trees or AVL-trees, nor do I really know their pros and cons against each other at this moment (I have a very very faint idea), but I know they exist and I certainly have a better idea of when to use a tree versus a list, versus whatever.
Would I fail these interviews? Probably, unless I studied a bit, but do I think that the concepts that they ask about are pointless? No, not at all. I've looked at my fair share of legacy code bases built by subpar developers and the one thing that always pops up is the bad data structures chosen. Once we fix that, usually everything else automatically falls into place.
EDIT: To be clear, what I mean is that in most cases, just picking the right data structure, among the most basic and elementary data structures given to you by the language, is more than enough. Only in rare cases does one then have to go beyond that and carefully engineer a more precise algorithm. The data structures are way more than half the problem, in nearly every application.
This is a tangential point in the article but he mentions interviewing people and asking questions about arrays vs linked lists. I was wondering whether a lot of you are working on stuff that involves deep understanding of data structures, sorting algorithms, etc? I seem to see it in a lot of interview questions. Is that just a good topic to separate those with formal education from self-taught people, or are a lot of you really spending a lot of time working on those types of problems?
(To add to that, I should say that I did study data structures in college and know the answers to these questions, but I just personally never have to deal with that level of the code in my work.)
I like algorithms and coding competitions, but in my 22 year career in software engineering I have never had to code any algorithm myself, except in numerous job interviews.
As for data structures, the only one I occasionally need to code myself is a simple tree.
2) some sort of odd string / array manipulation that never comes up in real life
3) some sort of linked list manipulation where again there is an STL for that and/or wouldn’t come up in real life
4) some optimized algorithm that literally took the first person years to discover prims vs kruskals MST for example, but now is expected to “figure out” on the fly.
5) Expects you to solve all these tasks with an insane time pressure that again is not a simulation of real life, it just makes it stressful almost as a rite of passage
I disagree. Studying algorithms and data structures is not at all like memorizing integral solution formulas. People who are good at these types of problems generally do the same steps:
1. What is the class of problem I am dealing with? (e.g., solution uses a stack, queue, heap, etc.)
2. What is the likely complexity of the solution?
Knowing, or at least having a guess, to these two questions greatly simplifies the approach. You do the exact same thing with solving integrals (e.g., is this an integration by parts question? is it a substitution question? etc.) and the same for physics, chemistry, etc. With algorithms, once you've done enough and have a very good mental model, you will start making translations between problems. That is, given problem A, you are able to map it to problem B which is easy to solve using some technique you know.
I don't think they are the same thing at all. I've been practicing literate programming for a decade now, but my brain still has to switch gears when I go from writing up the English-language description of an algorithm to writing the algorithm. A good description of what an algorithm does (e.g. "This function finds the largest subset of edges in the graph which could be removed without disconnecting the graph") is very very different from the code which does that, and requires very very different kinds of thought.
In the latter case, what they call algorithms usually tend to be similar to the kind of "brain twister" problems that Microsoft was famous for.
In the former case (academics), data structures include things like stacks, queues, deques, linked lists, and on to graphs and trees. Whereas algorithms are specific procedures carried out with data structures, like sorting and searching, and dynamic algorithms. And then on to much harder stuff, like FFT.
My point is simply that I feel comfortable creating stacks, queues, linked lists, graphs, trees, etc., whereas when someone asked an open-ended algorithmic question to be solved on the white board or phone, I struggle under the pressure and gazing eyes of multiple interviewers to solve these problems (whereas I do fine in my own environment with only the pressure of finishing a job).
reply