Those who are interested in this subject and want to discuss it, you may be interested in seeing the points - good and bad - that have been made on previous occasions that this has been submitted. Here are a few previous discussion:
Discussions like this can be of value, and no doubt some of the newer people on HN may have points to add. OTOH, many points will already have been made, so seeing the past discussions may be of benefit.
This is someone's (very arbitrary) opinion in a grid. I hope you don't actually interview people. Figuring out someone's skill level is a soft science; it takes months after a hire to really know where someone is.
Some people I know are great at fixing bugs but have narrow language experience. They're damn valuable. Others integrate well into teams and provide great product feedback. Where's that on here?
Experience isn't measured in years but in knowledge gained. You really start seeing it 4-5 years in, some people move forward, some don't.
There are so many holes in this. I feel like whoever wrote this has a strong desire to reduce people to a number. It's not only terrible, it's a great way to fool yourself.
On the contrary, it is useful to have a comprehensive, substantive measure of technical skills. Having one does not preclude additional assessments, as you assume. I have been continually disappointed with the lack of extensiveness in technical interviews, as a candidate, but also as an interviewer when reviewing other interviewer assessments of potential candidates. I have yet to meet a programmer who doesn't believe they are very good at what they do and I believe this problem is due in large part to the shoot-from-the-hip approach that the industry takes at the interview stage.
I must've read this very differently. I rolled my eyes and skipped over the experience table. I've seen one too many programmers with literally decades of experience but still without a clue.
But the rest… I assume it's a matrix for a reason. Someone isn't a level log(n) programming mage, but he or she might be a level log(n) data structure and algorithm wielder, a level n^2 systems programming apprentice, and a level n requirements gatherer, or some other combination of strengths and weaknesses. It's still a lossy abstraction, but significantly less so taken that way.
If its title swapped 'Programmer Competency Matrix' with 'Computer Science Competency Matrix' it would make a lot more sense. Some of the level 3 competency ratings have little relevance in the real world.
Everyone in the programming world knows programmers (often intelligent, educated, and experienced ones) get caught up in silly details of perfecting their code and are completely unproductive without an experienced manager (or tutor) guiding them. I can't help but laugh when a bushy tailed non-programmer steps in, and produces something quickly and effectively using seemly simple tools.
It's a good list of skills. I don't find them all so linear, I'm sure most of us have bits and pieces from all of the squares, even though it says explicitly that you have to know all of the proceeding skills in order to move to the next column.
I can't help thinking when I read these lists, though, that they probably favor the author's particular skill-set and experience. Maybe not necessarily the author's current state, but perhaps where they'd like to go or what skills they aspire to have.
I'm not sure this has anything to do with "competency". When I was in high school, I implemented a kd-tree for a ray tracer using photon mapping. I knew that my n^2 algorithm was slow and that there was probably a better way, so I Googled and figured out how to write code for such a structure.
Since I'm not a programmer (I'm a chemical engineer), I don't instantly know all of the orders of various algorithms (which according to this article makes me "incompetent"). But you can bet that when it comes to implementing something, I'll research and figure out the most efficient algorithm available and use it.
I'm not sure being good at programming has much to do with having a whole bunch of CS knowledge; rather, it's being able to figure out what knowledge you need to know -- when you need to know it.
I agree with this - e.g not being able to bust out a dynamic programming implementation perfectly on a whiteboard doesn't make you a bad programmer - more important is to understand, "hey, looks like when I divide this problem up it has overlapping subproblems - let me research using memoization or dynamic programming". But that still assumes you have the right terms in your head to be able to do the research - and to me that's where some fundamental knowledge of algorithms and data structures comes in handy.
to be fair: It's both. You need knowledge and smarts. If you know everything but you don't know how to apply anything to new problems, you're screwed. If you're a genius but you know nothing about computers, you're effectively incompetent at that point, and it'll take you a while to learn everything you need to know to solve the problem.
> I'm not sure being good at programming has much to do with having a whole bunch of CS knowledge; rather, it's being able to figure out what knowledge you need to know -- when you need to know it.
What I often tend to find valuable is not so much knowing what I need to know (although that's good too), but knowing what's possible. For example, there's really little need for me to be able to rattle off the code for a splay tree off the top of my head, but knowing its characteristics (and those of other data structures) is very useful - it allows me to match potential solutions to problems. All I then need to do is read up a bit more on the specific solution I have in mind.
I've found that this approach stops me reinventing the wheel too much, although it has also given me a slightly depressed view on many innovations within the computing world :-).
Indeed, one does not need a CS degree to be a good programmer. This makes sense, cause somehow good CS degrees still seem to produce some people who can't program.
so programming is your hobby, have some fun while researching and solving some problem using some random solution found on the internet which might work or not
Level 0: Saw the post title and didn't think he needed to look at it because he was so confident in his abilities already.
Level 1: Read the post, noticed a lot that he didn't know but didn't intend to do anything about it.
Level 2: Read the post and went out and learned everything in it that he didn't know.
Level 3: Read the post, figured out which things from it he didn't know but might need to or want to, and learned those.
Oh, and a special level -1: Read the post, noticed a lot of things that he didn't know, and decided the post was stupid because clearly he's an amazing programmer and the post didn't agree with that self-assessment.
Interesting. One thing that caught my eye was "someone who knows most of the tools from Scott Hanselman's power tools list." I had never heard of Scott Hanselman, nor his power tools list and had to look it up. Frankly, it looks useless to me as a programmer and looks more like a list of desktop gadgets, and watered down versions of tools you get for free with most Linux distributions. He also doesn't mention Linux (or OSX), nor Emacs nor vim. The great majority of the tools are Windows specific or Windows only (I caught one or two that weren't).
Another part of that item was confusing to me as well - "ORM tools". I'm assuming this isn't referring to an ORM library or framework, since this section seems to be about editors, IDEs, and other desktop software. What are "ORM tools"?
Agreed. I'm not sure how 'Source Code Version Control' and 'Build Automation' is anywhere near the words 'Software Engineering'. And 'Automated Testing' isn't a given at a lot of shops.
Professionally, I've never set up version control. It's there when I start the job, it'll be there when I leave. I've branched and merged but a lot of times this is handled by a build manager. Build automation I have never expressly done - a shop that needs continuous integration is typically one where it is already set up.
Seriously, unless the job is 'Build Manager' then the question should be just used to gauge what you might have to teach them. 'Have you used source/version control software? Which ones?' 'Do you have experience with build automation tools?'.
I personally believe I fall into "n (Level 2)". I recently completed a degree in Software Engineering, and despite programming for a long time before that I would have ranked myself at "n2 (Level 1)". The degree pretty much brought me and everyone up to scratch with "n (Level 2)" in terms of knowledge. Having actually tried to work with some of my classmates - who also achieved first class degrees (some with higher grades than me despite little prior programming experience) - they're mostly terrible programmers.
As far as I'm concerned, this table is purely for working out a programmer's education, not competency. Experience and passion are the only ways I chose to judge my colleagues.
"able to identify NP problems" ? Most of the problems we face are NP. Maybe he was meaning NP-complete problems. See http://mathworld.wolfram.com/NP-Problem.html for the definition.
NP-hard is the actual class of problems you want to identify, although people who can identify NP-complete problems have no problems spotting NP-hard ones.
Inexperienced programmers consult documentation a lot and the more experienced you become, the less you consult documentation? If this were true, the initialism "RTFM" would never have been coined.
That one seems totally backwards to me. Experienced programmers should be able to read and understand more technical documentation such as language specs or RFCs and use it to figure out the answers to their problems. Inexperienced programmers are the ones that sak for help at the first sign of trouble.
Perhaps we just consult different documentation as time goes on... RTFM is most often directed at people who have an easy answer waiting for them in the documentation, but lazily asked a newsgroup/list/etc. to solve their problems instead as a first step.
This is technically not a "bad" measure of performance, but the real danger is the word "competence." Imagine I am hiring two candidates, one has log(n) (level 3) competence across these charts, while the other has very mediocre/poor competence. What if I am working on an application is not performance-critical? What if the "incompetent" guy/girl works twice as fast, because he does not worry about crafting coding-works-of-art? What if the "incompetent" guy is three times cheaper to hire, and eager to prove him/herself, thus putting in extra hours voluntarily? What if I am hiring for a problem with a very specific domain, and expertise is required in only one area?
You don't need a wizard for every task. There's nothing wrong with taking someone from the left side of the matrix. You just have to consider what they'll be working on and what resources are available to them (ie. mentors, etc.) Hiring decisions are comprised of tradeoffs, just like everything else in engineering.
This is a rather narrow viewpoint of what makes a great programmer in my opinion. One completely missed element here is the ability to track organizational complexity. For example, you have a site with 100,000 lines of code. Making one change somewhere affects 10 other things elsewhere, each of which might affect another 10 things. Keeping track of all that is what I'm talking about. Same skill you find in great chip (integrated circuit) designers. Personally I think it's far more important than some of the concepts here, which focus mainly on algorithm-level stuff.
Interesting. One thing that caught my eye was "someone who knows most of the tools from Scott Hanselman's power tools list." I had never heard of Scott Hanselman, nor his power tools list and had to look it up. Frankly, it looks useless to me as a programmer and looks more like a list of desktop gadgets, and watered down versions of tools bundled with most Linux distributions. He also doesn't mention anything for Linux (or OSX), nor Emacs. The list is very Windows specific.
Thank goodness B-trees are considered the most-advanced of the data structure knowledge. My com sci classes never did a great job of making those applicable.
B-trees are great! They have better locality than binary trees --- that's why filesystems are universally based on B-trees: seeks are slow. As cache effects become ever more important, B-trees are starting to become important even for problems that fit in main memory.
I land solidly in the right-hand column, particularly on the systems programming front: I've made major contributions to the NT kernel. I'm not sure this matrix has all that much significance: Google rejected me after the in-person interview: do they want people who can sort N items in O(1) time, work 30 hours per day, and create new scripting languages over lunch?
I would like to see a section that includes things like identifying/clarifying customer requirements, finding business solutions, controlling scope, organizing a project around some methodology, leading a team, etc. I see the lines for Problem Decomposition and Communication, but I think there is something much broader that is being left out.
Either where I went to school had an exceptional CS program, or most CS programs don't cover what my run-of-the-mill state school covered during my undergrad. About 10 years ago I came out of school at around a level 2 or 3 in almost all of the areas on this grid. I would wager pretty much any 3.5+GPA student in a decent CS program should be the same.
I didn't pursue being a professional developer so I've lost most of these things, but I remember having worked on almost all of these things (such as they were at the time). Some of these things I haven't heard mentioned since my undergrad!
Interestingly, we never studied functional languages, but did cover Prolog. This has definitely created a deficit in my thinking and consideration about certain problems/languages. If that's any indication this matrix can give insight into the abilities of people who simply haven't covered certain topics.
[+] [-] ColinWright|13 years ago|reply
http://news.ycombinator.com/item?id=232192 (indiangeek.net) 75 points 4 years ago 33 comments
http://news.ycombinator.com/item?id=554338 (indiangeek.net) 83 points 3 years ago 33 comments
http://news.ycombinator.com/item?id=1022394 (indiangeek.net) 67 points 2 years ago 40 comments
http://news.ycombinator.com/item?id=1949915 (starling-software.com) 155 points 1 year ago 106 comments
http://news.ycombinator.com/item?id=2823912 (indiangeek.net) 12 points 1 year ago 1 comments
http://news.ycombinator.com/item?id=3434350 (starling-software.com) 2 points 9 months ago 0 comments
Discussions like this can be of value, and no doubt some of the newer people on HN may have points to add. OTOH, many points will already have been made, so seeing the past discussions may be of benefit.
[+] [-] praptak|13 years ago|reply
[+] [-] andrewvc|13 years ago|reply
Some people I know are great at fixing bugs but have narrow language experience. They're damn valuable. Others integrate well into teams and provide great product feedback. Where's that on here?
Experience isn't measured in years but in knowledge gained. You really start seeing it 4-5 years in, some people move forward, some don't.
There are so many holes in this. I feel like whoever wrote this has a strong desire to reduce people to a number. It's not only terrible, it's a great way to fool yourself.
[+] [-] Swizec|13 years ago|reply
[+] [-] riazrizvi|13 years ago|reply
[+] [-] LnxPrgr3|13 years ago|reply
But the rest… I assume it's a matrix for a reason. Someone isn't a level log(n) programming mage, but he or she might be a level log(n) data structure and algorithm wielder, a level n^2 systems programming apprentice, and a level n requirements gatherer, or some other combination of strengths and weaknesses. It's still a lossy abstraction, but significantly less so taken that way.
[+] [-] pippy|13 years ago|reply
Everyone in the programming world knows programmers (often intelligent, educated, and experienced ones) get caught up in silly details of perfecting their code and are completely unproductive without an experienced manager (or tutor) guiding them. I can't help but laugh when a bushy tailed non-programmer steps in, and produces something quickly and effectively using seemly simple tools.
[+] [-] akulbe|13 years ago|reply
I'm ~40 and going back for a CS degree isn't very appealing / practical. But if I knew what things to study... I could start on my own.
I'm advanced in my career, but its been mostly advanced level support and system administration work. I want to get into programming.
I say all that to make the point that a degree track isn't the best fit for me.
[+] [-] DanielRibeiro|13 years ago|reply
http://news.ycombinator.com/item?id=1022394
[+] [-] jakejake|13 years ago|reply
I can't help thinking when I read these lists, though, that they probably favor the author's particular skill-set and experience. Maybe not necessarily the author's current state, but perhaps where they'd like to go or what skills they aspire to have.
[+] [-] Xcelerate|13 years ago|reply
Since I'm not a programmer (I'm a chemical engineer), I don't instantly know all of the orders of various algorithms (which according to this article makes me "incompetent"). But you can bet that when it comes to implementing something, I'll research and figure out the most efficient algorithm available and use it.
I'm not sure being good at programming has much to do with having a whole bunch of CS knowledge; rather, it's being able to figure out what knowledge you need to know -- when you need to know it.
[+] [-] krosaen|13 years ago|reply
[+] [-] pilgrim689|13 years ago|reply
[+] [-] AlisdairO|13 years ago|reply
What I often tend to find valuable is not so much knowing what I need to know (although that's good too), but knowing what's possible. For example, there's really little need for me to be able to rattle off the code for a splay tree off the top of my head, but knowing its characteristics (and those of other data structures) is very useful - it allows me to match potential solutions to problems. All I then need to do is read up a bit more on the specific solution I have in mind.
I've found that this approach stops me reinventing the wheel too much, although it has also given me a slightly depressed view on many innovations within the computing world :-).
[+] [-] YokoZar|13 years ago|reply
[+] [-] dotborg2|13 years ago|reply
professional coding is about something different
[+] [-] lathamcity|13 years ago|reply
Level 0: Saw the post title and didn't think he needed to look at it because he was so confident in his abilities already.
Level 1: Read the post, noticed a lot that he didn't know but didn't intend to do anything about it.
Level 2: Read the post and went out and learned everything in it that he didn't know.
Level 3: Read the post, figured out which things from it he didn't know but might need to or want to, and learned those.
Oh, and a special level -1: Read the post, noticed a lot of things that he didn't know, and decided the post was stupid because clearly he's an amazing programmer and the post didn't agree with that self-assessment.
[+] [-] gridspy|13 years ago|reply
Is there a level for "Skimmed the first part of the post and then went back to working on his/her startup" ?
[+] [-] npsimons|13 years ago|reply
[+] [-] gosub|13 years ago|reply
[+] [-] robbles|13 years ago|reply
[+] [-] lucian1900|13 years ago|reply
Meh.
[+] [-] Zimahl|13 years ago|reply
Professionally, I've never set up version control. It's there when I start the job, it'll be there when I leave. I've branched and merged but a lot of times this is handled by a build manager. Build automation I have never expressly done - a shop that needs continuous integration is typically one where it is already set up.
Seriously, unless the job is 'Build Manager' then the question should be just used to gauge what you might have to teach them. 'Have you used source/version control software? Which ones?' 'Do you have experience with build automation tools?'.
[+] [-] welder|13 years ago|reply
[+] [-] HyprMusic|13 years ago|reply
As far as I'm concerned, this table is purely for working out a programmer's education, not competency. Experience and passion are the only ways I chose to judge my colleagues.
[+] [-] pykello|13 years ago|reply
[+] [-] praptak|13 years ago|reply
[+] [-] sequoia|13 years ago|reply
[+] [-] kisielk|13 years ago|reply
[+] [-] sk5t|13 years ago|reply
[+] [-] eranation|13 years ago|reply
- can the candidate do the job? (github projects, portfolio, hands-on test)
- when they talk, do you understand?
- when you talk do they understand?
- do they sit all day and read HN / Stackoverflow?
- on the other hand, they never heard of the above
- do they get the job done or try to make it perfect?
- do they fit the culture of the company
- can they learn a new skill quickly
give 1 point for each of the above and you got a much better matrix (if you want to hire people you won't need to fire)
[+] [-] DodgyEggplant|13 years ago|reply
[+] [-] coob|13 years ago|reply
Attitude section?
[+] [-] mattdeboard|13 years ago|reply
[+] [-] buro9|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] gavanwoolery|13 years ago|reply
[+] [-] bmohlenhoff|13 years ago|reply
[+] [-] politician|13 years ago|reply
[+] [-] arbuge|13 years ago|reply
[+] [-] npsimons|13 years ago|reply
[+] [-] danso|13 years ago|reply
[+] [-] quotemstr|13 years ago|reply
[+] [-] seattlecoder|13 years ago|reply
[+] [-] moconnor|13 years ago|reply
[+] [-] pjungwir|13 years ago|reply
[+] [-] bane|13 years ago|reply
I didn't pursue being a professional developer so I've lost most of these things, but I remember having worked on almost all of these things (such as they were at the time). Some of these things I haven't heard mentioned since my undergrad!
Interestingly, we never studied functional languages, but did cover Prolog. This has definitely created a deficit in my thinking and consideration about certain problems/languages. If that's any indication this matrix can give insight into the abilities of people who simply haven't covered certain topics.