The reality is that there's a shortage of highly qualified STEM majors. As an ECE student, if I were to ask students in my major to code a linked list, or binary node tree, a good 25-50% would fail. And this is at a Top 10 program.
Coding one's own own data structures/routines for common data structures is probably suboptimizing. There are debugged modules available in most languages. Do students get an extra 10 points if they use a debugged tested solution from a library? e.g., http://stackoverflow.com/questions/6831231/should-programmer...
Yes, in production code you'd usually use a library implementation - although if you had specific requirements you would still need to build your own. That's beside the point though - any decent engineer should still understand how they work and be able to write a implementation of them fairly easily.
> Coding one's own own data structures/routines for common data structures is probably suboptimizing. There are debugged modules available in most languages.
But if you can't code common data structures on your own, you'll probably have trouble coding the more advanced data structure that you found a paper on describing (possibly described in part by replacing parts of a more common data structure) with some code, but not in your language of choice, that would be, from its description, far better than the common data structure for your problem, for which there is not a debugged library for your platform of choice.
I'm really having trouble with the notion, common on HN, that programmers don't need to understand or be able to code simple data structures. Hash tables, simple binary trees, and heaps are extremely basic computer science. You may never use a DIY binary tree container library, but if you can't comfortably write a binary tree or a heap, you won't be able to understand or implement advanced or domain-specific algorithms either.
This is a learning task that might take a competent developer all of 2-3 days. If you're rationalizing not figuring out how to write a heap or a hash table, consider asking yourself whether you actually want to be a developer. You might feel OK about what you're doing now, but a career spent redesigning unit test suites and coming up with ever- more- elaborate HTML templating schemes is unlikely to be fulfilling.
I've expressed disagreement in another sub-thread with the idea that programmers need to understand or be able to code simple data structures, not because I think that knowledge is unimportant, but because "need" is a very strong word. (My previous objection was in the context of hiring--for 99% of CRUD web apps being built, the ability to use or implement a binary tree won't matter, and even when it does matter it won't need to matter for more than a few members of the team.)
It's very possible to make a positive programming contribution in a professional context (and in a wide variety of fields) without having ever implemented a hash table (I had not, before just now). Obviously it's more important in some contexts than others, and that's fine, but the suggestion that programmers who don't have that experience are not programmers or that they're incompetent programmers is nonsensical--the context in which they work makes the difference.
Now obviously, it's been a bit embarrassing making essentially this same post multiple times recently, so I just implemented a hash table and read a few sources for heaps and binary trees--yay! But this isn't rocket science--if I ever encounter data which doesn't conveniently fit in the basic structures available in my environment, I go find out what works (so, for example, I'm working on a project where I need to find the closest points in a data set according to Euclidian distance, and discovered that VP trees fit the bill).
It is entirely possible that the ability to synthesize a simple data structure is a valuable signal of programmer competence for people with a formal computer science education (because they were presumably taught and tested against that knowledge multiple times, and if they can't reproduce it afterwards they might be bad at learning) but my suspicion is that the implementation of domain-specific algorithms is more often limited by a lack of domain knowledge than a lack of CS knowledge.
> I'm really having trouble with the notion, common on HN, that programmers don't need to understand or be able to code simple data structures.
Well, do they? Being able to code simple data structures is not a pre-requisite to being paid to write code.
I can't base this statement on cold hard numbers, but I feel comfortable stating that the majority of dev positions in the world today do not require this particular skill set.
Thus : no, they (programmers) don't need to be able to understand or be able to code simple data structures.
If the inverse were true - namely, that a large percentage or majority of dev work required knowledge of and the ability to implement basic data structures - then you would be quite correct.
> You might feel OK about what you're doing now, but a career spent redesigning unit test suites and coming up with ever- more- elaborate HTML templating schemes is unlikely to be fulfilling.
That's a bit dismissive. Also, are you speaking generally or referring to me as an individual?
The realities of the industry would seem to be to write code that doesn't collapse under the slightest strain. In order to write code that doesn't fall down, or that does what it purports to do, the coder needs to understand how stuff works. If you don't understand how to build a linked list, or other common data structures, it is quite likely that you won't know how to use it. Or where it can go wrong. Or where it is not the correct thing to use.
The realities are more stark in our breach-infested world. Sloppily implemented systems put companies in the headlines.
Examples abound, not only with data structures, but also with algorithms. Someone who has written a compiler is far less likely, in my estimation, to try to "parse" a URL with a regular expression, with negative consequences. Someone who has written a hash table is less likely to be surprised when the insertion behavior ends up being n squared.
It's the edge cases that separate a good engineer from an average engineer. When that good engineer runs into that problem, he/she will solve it quickly and move on. An average engineer will spend days or weeks struggling with the solution -- costing lots of money and potentially delaying schedules.
There was a post this week about a Ruby on Rails contractor who helped with a talent search. He didn't recommend people that didn't know what Ruby Gems were or what Active Record was... They got hired anyway.
Amazing. Another reason to still ask 'senior' developers a fizzbuzz type question.
Above is also the reason good (not great or rockstars) developers are in high demand and almost never on the open market. Once you work with people and vet yourself with other good developers, new jobs are usually just a phone call away.
Again, it depends on where you live and who you know.
Every job I have ever landed, I've had to go through the full HR rigamarole, from finding the posting through multiple rounds of interviews. I've never quite been able to make a friend--or even acquaintance--that has subsequently been able to backchannel me into a job. I've had several interviewers say directly that I appear to be one of the most technically qualified candidates they have, but after I walk out the door, I never hear another word from them again, not even to say they picked someone else.
The hiring system is broken. And the damage is at least in a load-bearing member, if not the foundation itself. There is no financial pressure for anyone capable of fixing it to actually do so. And so we suffer as entities with far more political experience glide smoothly among the sharks, depressing our wages today, and tomorrow, they quietly dismantle the dreams of young people passionate about our field.
It sickens me to the point that I feel like there are no good employers left in the U.S., in any field. I have no reason whatsoever to buy a house, befriend my neighbors, and invest in my local community, because at any moment my gracious employer (or their new owners) could decide to fire everyone and move out. That would leave me again in the position where I have to also move, just to find a job not quite as good as the one I just had.
And now that I am in one of the few locales recognized as a "tech center" in the U.S., I find that most of the jobs here are military-industrial complex tax-leeching jobs, where industry best practices are routinely ignored, because the primary goal of the contractor is to produce billable hours instead of permanent solutions, and the overseer-boss got his job via military good-ol'boy networking rather than having one inkling of competence.
What's the solution? I don't know. But making me retype my entire resume into your stupid web forms to better facilitate its automatic rejection for lack of required hidden keywords is completely antipodal to it.
I'm fairly certain their career prospects don't hinge on whether or not they can perform a few job interview parlor tricks.
If I were to poll all my SE colleagues, present and former, and ask them when they last manually coded a linked list or b-tree - I can assure you the answer would not be "on a product we shipped".
B-trees with augmented information are very fast, and I know of no generic augmented B-tree. So I've contributed to a program that shipped a custom augmented b-tree. I assume the same goes for other types of augmented data structures. Is that so rare ? Or do most people simply not know how/why to augment data structures ?
