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.
Well, to be honest, I have deep-scripted accessing HN, but I tend only to use it when doing big data crunching on trends and similar. When providing cross-references I've usually just put the IDs - actually counting points, comments and age is something I've not done for a while.
Don't think I'll bother again, I get enough grief and hate-mail just from trying to point people at earlier conversations.
I really appreciate it when earlier conversations are pointed to. (The additional points/comments/age numbers are wonderful, too, if you feel up to providing them.)
I wonder if a bot could be written to automate this? There are lots of horrible reasons one could have for writing a HN comment bot, so I'm hesitant to even suggest it, but this seems like a really useful/good bot.
Actually, I can't tell you how many times a HN comment like yours has turned me on to an ultra-valuable related discussion that I would never have seen or thought to look for.
So don't let negative comments (perceived or actual) speak for us silent appreciaters!
I won't post the unpleasant emails - I'd have to go and find them and I'm not inclined to re-read them. You can read some dissenting opinions, and a reasonably civilized discussion here:
Came here to post this, except I was going to suggest it be built into HN itself and be in a section at the top of the comment page, perhaps between the link and the comment box. A way to suggest/add the links to the box would be good too (maybe mods + the submitter could have control of which links show up via this system)
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.
This is a quote I use very often! As with many other great quotes, I think it originates in English from Trevanian's Shibumi (when Otake-san, the Go master is giving his final teaching to Nicholai):
Do not fall into the error of the artisan who boasts of twenty years experience in his craft while in fact he has had only one year of experience — twenty times.
Most probably Trevanian has drawn upon some other source, tough I've never been able to track that.
If you haven't read this fantastic book I strongly recommend it.
It's an ok potboiler that relies ever-more improbable plot devices.
It's also impossibly incorrect politically -- so transparently so that I think it's essentially harmless. But if you don't understand why some people would feel that why you really should watch your step.
David Courtwright used a slightly different version of it to describe the Vietnam war: "we were not in Vietnam for 10 years, but for one year 10 times."
I believe the origin is in medicine. My wife introduced the idea too me 10 years ago. In medical practice, watch out for the doctor who's been practicing the same year of medicine over and over and over.
I've heard it from one of the karate instructors I've corresponded with (although in that context it was less of a dismissive phrase and more a cautionary one for our own training). Regardless of the origin, it's a good one.
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.
The problem is that you're relying on interviews to hire someone who will hopefully work with you for years to come. Would you interview and pick your wife or husband in one day? Would a table like the above help?
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.
I'm 30, and have a computer science degree, and am log(n) on the chart in many areas (but certainly not all). In almost all cases, the relevant experience came from me trying to do a side project that required knowledge I didn't have. I can install a database because I had to. I can program in functional languages because I was reading about them and I tried to use one for a side project.
The side projects don't even have to lead anywhere, but they get you to the point where you can say "ya, I can write a node.js server" and then you can do it on the job, and a few years later you're an expert.
This is definitely not the only way to acquire skills. I'm sure some people dig through books, or just focus on doing their job and still grow. But for me, side projects have always been the driving force.
I was a lifer Sysadmin until I was 40 and learned Ruby on Rails. I've always had an unprovable theory that Sysadmin always results in a fork in the career path: management or programming, and I didn't see myself in management. I'm self-taught and was accepted for Startup School this year, and while I'm not quite where I want to be, I think programming and creating with an awareness of the system side of things is a better direction for me to go in.
You can also always program on the side if you want to maintain the stability of an established career.
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.
True. But note that the matrix isn't a binary "good/bad". If you know the concepts that underly dynamic programming and can look it up when needed, great. If you have used it before and can bang out an implementation without looking it up, well, that's even better.
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
It may be a "hobby" but I've been doing it for 12 years, made money off of it, and would argue that I probably know more (theoretical and practical) than your average bachelor's grad in CS.
And I don't know where this "random info on the internet" came from. My knowledge comes from algorithm textbooks or papers from university websites.
there are few more levels of knowledge and experience to achieve in order to improve overall quality of your work and that's the point of this article,
you can ALWAYS achieve your target in a better way
You still seem to be advancing your original point that hobby programming or side projects is an inferior pursuit relative to professional programming. McAfee was a shareware project, eBay was written by Pierre in a matter of days. I've seen many projects that were of much higher quality than many professional enterprise and startup projects.
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'm not sure how 'Source Code Version Control' and 'Build Automation' is anywhere near the words 'Software Engineering'.
I'm not sure how they couldn't be. True, they are not a part of computer science, but both are very helpful to be able to build software efficiently (i.e. software engineering). The places I've worked tend to not have build managers (and the one time there was one, the person wasn't technical and needed 'help' from engineering, to have sane policies and organization). Both skills are also important if you want to launch something -- either a personal project (open source or otherwise), or on a small team at a startup.
Let me get this straight, you do not know how to set up version control, therefore knowing how to set up version control is useless?
What I said:
Professionally, I've never set up version control.
I also never said it was useless. In fact, I use it at work AND at home on my own projects religiously.
However, I don't feel a need to ask about it in an interview. If you haven't used one you will be soon and if you know how to manage one it's just gravy. I might not even ask it's so inconsequential. Continuous integration is the same.
And no matter how you spin it, it's not software engineering. Not in the ballpark, not even the same game.
It wouldn't be useless but it could be unnecessary. I don't anticipate ever needing to set up version control, unless it's my own business. Any place I work will almost certain already have it set up, and if not, someone else will be tasked to set it up.
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.
For example, on attitude: Learning to be patient. Patient with planning the right solution, selecting the right libraries, fixing bugs, dealing with other developers who may not be as experienced as you, etc. I think patience is an overlooked "programmer's virtue."
Eh, I guess. I've experienced a lot of career fields at their mid-levels, swap "solution", "right libraries", "bugs" and "developers" with your nouns of choice and that's a pretty universal thing.
Maybe what you mean is that impatience is more of an accepted thing among programmers? I can get behind that.
Ugh. A pox on people who write programs that "anticipate your needs". They get it wrong more often than right, slowing you down, blocking you, or interrupting you and breaking the flow.
And to make matters worse, those features tend to be baked into the system such that you can't disable them.
> Those are part of the "existing-in-modern-society-as-a-human-being competency matrix", along with bathing and wearing pants as often as possible.
Excuse me but did you just present attitude, communication and other soft-skills as an absolute bare minimum and a total given that pretty much anyone "existing-in-modern-society-as-a-human-being" would live up to anyway? Where is this dream world and how do I get there?
Need I remind you of examples like geeks practically sexually harassing girls at conferences in this day and age? Or the insane amount of social-anxiety / communications / soft-skills related cries for self-help all over the net? We are FAR from any of this being a standard.
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.
I really like the idea of a way to measure my knowledge and skills. My preference would be for a directed knowledge graph, where nodes list the knowledge and skills fundamental to the nodes they connect to. This way, I could start from the bottom of the graph and place a checkmark on each node that I felt comfortable with. The end result would be an outline of what I needed to learn next to progress.
Alternatively, if I were in a rush to learn a specific item, the tree would give me a roadmap for getting there.
I'd be interested in a wiki-like interface for building such knowledge graphs, so that they could be built quickly and completely.
I'm not sure if "has used git" should be log(n)-- I'm only barely a programmer, and I've never used CVS/SVN, but I use git to version control markdown files.
"Checks all arguments and asserts critical assumptions in code "
Wait, I just finished code complete, and it told me that you specifically _don't_ check all arguments throughout your program. Instead, you choose a list of classes at that will check arguments for input as a firewall, and assume all classes behind those logically will receive the correct, sanitized input.
If you're paranoid (eg, programming embedded where it absolutely, positively, should not fail), you always check all arguments and return values. Sometimes libraries shipped from the vender are not perfect, sometimes the vendor's compiler will do something, ahem, unexpected with your return value in some edge case where you've exceeded the stack. I'll agree that wrapping with inlining is a good idea to make code readable, and these days you usually don't have to worry about a lot of hardware limitations (especially in the general case: desktop/Android/iOS/web/etc).
> programming embedded where it absolutely, positively, should not fail [means] you always check all arguments and return values
Let's distinguish "checking" invariants, preconditions, and postconditions from blithely propagating logic errors as error codes all the way up the stack. If you're programming in "paranoid mode", as it were, and you detect inconsistent state, you should abort the program. If you don't, you're in uncharted territory and you have no idea how your program will act. If you abort the program and restart the system, you'll probably end up back in a useful state.
Many, many times, I've seen code like the following:
Say someone passes a NULL pointer to a function somewhere deep inside DoComplexThing's implementation that doesn't expect NULL. If this function helpfully "checks" all parameters, detects the NULL, and returns E_POINTER, E_POINTER will probably propagate all the way up the stack to the top level, where we'll abort the program. Now you have a crash report, but you have no idea where the problem actually _is_.
If this function had instead not checked the NULL pointer and crashed or explicitly asserted its preconditions instead of treating contract violation as a runtime error, the problem would be a lot easier to diagnose.
In general, you can separate problems into two classes: logic errors and runtime errors. Logic errors are indications of the program being written incorrectly. Your program should blow up when it detects one. Runtime errors are errors that could conceivable occur at runtime due to reasons outside the program's control (e.g., removing an SD card). Only runtime errors should be propagated using your error reporting mechanism of choice.
I'm amazed that Oz surface up in this matrix. The number of people actually program in Oz for production purposes must be less than 100. It's a lovely language and I can miss somethings one could do in (Mozart)-Oz that I can't do in Haskell.
This probably isn't very useful for evaluating an interview candidate as a whole, but I like how comprehensive it is in terms of technical knowledge. It's a useful roadmap to evaluate your own technical competency too.
I'm sure it's a perfectly good topic to discuss, but I wonder what's motivating this sudden trend of "You must be this tall to call yourself a programmer" posts?
maybe it's just because i'm mostly an algorithms guy, but the bar for "O(log n)" systems programming seemed to be somewhat higher than that for datastructures and algorithms. and having "author of framework" be on the same level is another huge leap.
I love how they non-chalantly squeezed "automated testing" in there... because to really do well in that area you need so much more than the average handful of junit-or-whathaveyou tests and the whole "comes up with good test cases" is just extremely shallow. While developers do well to implement some simple unit tests, automated testing includes SO MUCH more they just left out. It is a whole software project and includes a lot more people than just "programmers" and "testers".
Another personal pet-peeve of mine are those endless suggestions of how to pick and hire developers, how can you get the very best of the best for the likely average salary you are offering to begin with - yet we have a continuous stream of coding-related horror stories.
It doesn't take any magic, it doesn't even take a catalog of weird questions that might work for google. Ideally go with recommendations, people who know people that are good. Or pick the interesting CVs and cover letters, avoid the buzzword rally. Then interview them and talk about what they have done so far and go into some details there, scratch on the surface, get a feeling for what they got going on. By now you should have quite a good idea. Then hire them on a temporary contract and see how they do. Be ready to give the new-comers and graduates a chance and be ready to invest in them, both in trainings and compensation.
IF you are in a position where you just cannot afford to put good faith in a common sense choice for a candidate then you should not be hiring in the first place because that means you either don't have the money for one more hungry mouth anyway or your project is so far into the death-march that another pair of hands is not going to rescue the sinking ship even if you get a true kernel-hacker to work on it.
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.