closed as not constructive by user40980, Robert Harvey♦, Frank, gnat, thorsten müller Apr 9 '13 at 7:21
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
If all you know how to do is write glue code, you may call yourself a code monkey. Lots of glue code needs to be written and you can make a decent living as a code monkey. To call yourself a Real Programmer TM and be trusted when code needs to be written from scratch, you have to know algorithms, data structures, memory management, pointers, assembly language, etc. and understand how to use this knowledge to evaluate tradeoffs.
those who don't know history are condemned to reinvent it
For Java OTOH, there's a difference. I suppose Java's standard library provides you about any datastructure your need. However:
- You need to know and distinguish those datastructures and understand how they perform in different situations so that you'll be able to chose the right one.
- In Java, it is not absolutely unlikely you will eventually want to write your own implementation for a hashmap to get better speed in some very specific case (for example if the keys you want to handle fullfill some special constraints that allow optimization).
When it comes to sorting algorithms, there isn't much need to know or understand them, because there's no need to ever implement one on your own. However, if such an algorithm is given to you, you should be able to understand and implement it.
Two things are certain:
- You can make a career as a programmer without relying on knowledge like this.
- It most definitely won't hurt you to know them.
Data structures and algorithms are simply a thing, that is good to understand. And it is something extremely clear and formalized and thus quite trivial compared to the intricacies of application or systems engineering. They are just one small piece in the puzzle, but they are easy to grasp - if you're willing to invest some time.
So no, you don't need them, but it would only be for your benefit to know them.
This might be an occasion where there can be a semantically-meaningful distinction between 'programmer' and 'software engineer.' In this context, specifically, we see that you have a knowledge of several programming languages and related technologies and that you can use them to produce desired results. This is a fine operational definition of 'computer programmer.'
I consider myself to be a software engineer. In most of the day-to-day aspects of my work, I probably do the same things that you do. I use computer language and related technologies to produce some desired result. However, I do have an understanding of data structures and algorithms, and I consider that knowledge to be a fundamental underpinning of my ability to do much more.
Often -- though not ever day -- my job involves finding solution to complex problems for which there are no obvious solutions, nothing that is directly addressed by the features of the framework that I am using or the capabilities of the language that I am working with. In this, I need to analyze the problem and devise a solution and occasionally this process goes in the realm of large-scale architecture.
While an excellent understanding of these deeper issues is necessary to doing that kind of work, it is not sufficient. In other words, just knowing how a hash table works or why a heap sort usually has good performance characteristics isn't enough to be a systems architect or a senior engineer. It's the logical starting place, and from there you can start to dig deeper and travel more widely and gain the experience that is also necessary to tackle the larger issues.
I suppose that in order to answer your question, you should ask yourself, "What do I want to be? Where will I go with my career?" If you are content to continue doing what you are doing, then you might just want to learn enough data structures and algorithms to get through the largely arbitrary interview questions that you are faced with.
If you want to grow in your career and you have the passion for it that is essential, you should embrace these subjects as tightly as you can. If you have some time to work on them, an open mind and true enthusiasm, you'll find some wonderful and exciting things. I'll never forget the day that I first understood quicksort. The feeling of excitement and discovery set the course for much of the rest of my life, and I couldn't be more grateful for that. Now, I can't imagine doing anything besides working as a software engineer.
Best of luck with whatever you choose.
It depends what the jobs are for. This sort of things are fairly standard interview questions but they're also fairly unimaginative and probably don't relate to the job at all - certainly not a job using the technologies you list.
For me as interview questions go they're a good judge of whether you did a Computer Science degree (and can remember it) rather than any measure of general programming ability or knowledge.
I'd suggest that either you learn this stuff so you can get through the interview, or you just accept that anywhere asking these things isn't for you, but no, you don't need to know them to call yourself a programmer.
I have interviewed a lot of API programmers aka code monkeys, and in most of the interviews they have routinely failed to design systems that are performance efficient and scalable. Bottom line: knowing loads of API will get you the bread, but for butter you need to start from the basics of computing.
I'll add "yes, of course you can still call yourself a programmer". But what sort of a programmer do you want to be? I think the very best programmers have at least some grounding in the theoretical basics. They know why they chose a particular data structure/algorithm as well as the trade-offs that come with that. I expect any developer I interview to have at least a basic understanding, even if they don't use the same jargon (although not knowing the jargon means you'll find it more difficult to communicate with other developers).
Knowledge of algorithms allow you to confidently say how your choices Will scale! I personally consider this to be necessary to be a senior programmer
"If you want to be a good programmer you just program every day for two years. If you want to be a world class programmer you can program every day for ten years, or you could program every day for two years and take an algorithms class."
-Charles E. Leiserson
It depends of the project: I'm a BEng in Computer Engineer and I work as analyst programmer.
I spent a lot of time for to work in design (testing, doc, code design). But, when I find a bug (or bad performance) or I have to coding a new data structure (because the requirement is very NEW for the application), I must to understand where's the problem in the algoritm and I must to correct him (I did this not very good, so :))
The classical algorithms and data structures are a kind of "dictionary pattern" in the world of developer.
Some excellent links:
You may well be a good programmer right now, but knowledge of Data Structure, Algorithms and knowledge of other topics in computer science would certainly help a lot in improving yourself in many ways:
You may be able to be more effective and faster at doing things. Even folks who already have a Computer Science degree and know a lot of these topics would tend to keep themselves abreast with latest advances in order to improve themselves.
This knowledge will also be good for, if upto a lesser extent, say if you move from programmer to management track later, because you would still be able to understand the technical aspects of projects better with this knowledge.
Of course data structure and algorithms are asked a lot in interviews, so that is one more reason why it might be useful to know them.
You mention hashes, trees, stacks, queues and sorting algorithms. Well, the technologies you've mentioned are mostly webpage and web-scripting related. You should definitely understand trees at the very least, so you can work with the DOM well. But if scripting is all you need to do, then you're probably OK. You won't need most of the tools of the trade for a real programmer. But that's because there's a big difference between the string-juggling that makes up most of Web scripting and what most of us consider "writing programs."
I work with hashes and trees practically on a daily basis, and stacks and queues less often but frequently enough. Sorting is basically a solved problem; just about any language has a quicksort built into the standard library, a Sort method on basic collection types, etc, but you should know under what circumstances quicksort's performance can degrade severely and the right strategies to delay sorting.
If I didn't know these principles and how they work, I could probably hack up coding solutions that work, but they wouldn't be very good quality solutions. They'd run slowly, be hard to read, and hard to modify, reuse or extend. So if you want to learn to be a good programmer, you should definitely read up on your algorithms and data structures. They'll really improve the quality of your code.