Note that the knowledge for each level is cumulative; being at
level n implies that you also know everything from the
levels lower than n.
| Computer Science | |||||
|---|---|---|---|---|---|
| 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments | |
| data structures | Doesn’t know the difference between Array and LinkedList | Able to explain and use Arrays, LinkedLists, Dictionaries etc in practical programming tasks | Knows space and time tradeoffs of the basic data structures, Arrays vs LinkedLists, Able to explain how hashtables can be implemented and can handle collisions, Priority queues and ways to implement them etc. | Knowledge of advanced data structures like B-trees, binomial and fibonacci heaps, AVL/Red Black trees, Splay Trees, Skip Lists, tries etc. | |
| algorithms | Unable to find the average of numbers in an array (It’s hard to believe but I’ve interviewed such candidates) | Basic sorting, searching and data structure traversal and retrieval algorithms | Tree, Graph, simple greedy and divide and conquer algorithms, is able to understand the relevance of the levels of this matrix. | Able to recognize and code dynamic programming solutions, good knowledge of graph algorithms, good knowledge of numerical computation algorithms, able to identify NP problems etc. | Working with someone who has a good topcoder ranking would be an unbelievable piece of luck! |
| systems programming | Doesn’t know what a compiler, linker or interpreter is | Basic understanding of compilers, linker and interpreters. Understands what assembly code is and how things work at the hardware level. Some knowledge of virtual memory and paging. | Understands kernel mode vs. user mode, multi-threading, synchronization primitives and how they’re implemented, able to read assembly code. Understands how networks work, understanding of network protocols and socket level programming. | Understands the entire programming stack, hardware (CPU + Memory + Cache + Interrupts + microcode), binary code, assembly, static and dynamic linking, compilation, interpretation, JIT compilation, garbage collection, heap, stack, memory addressing… | |
| Software Engineering | |||||
| 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments | |
| source code version control | Folder backups by date | VSS and beginning CVS/SVN user | Proficient in using CVS and SVN features. Knows how to branch and merge, use patches setup repository properties etc. | Knowledge of distributed VCS systems. Has tried out Bzr/Mercurial/Darcs/Git | |
| build automation | Only knows how to build from IDE | Knows how to build the system from the command line | Can setup a script to build the basic system | Can setup a script to build the system and also documentation, installers, generate release notes and tag the code in source control | |
| automated testing | Thinks that all testing is the job of the tester | Has written automated unit tests and comes up with good unit test cases for the code that is being written | Has written code in TDD manner | Understands and is able to setup automated functional, load/performance and UI tests | |
| Programming | |||||
| 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments | |
| problem decomposition | Only straight line code with copy paste for reuse | Able to break up problem into multiple functions | Able to come up with reusable functions/objects that solve the overall problem | Use of appropriate data structures and algorithms and comes up with generic/object-oriented code that encapsulate aspects of the problem that are subject to change. | |
| systems decomposition | Not able to think above the level of a single file/class | Able to break up problem space and design solution as long as it is within the same platform/technology | Able to design systems that span multiple technologies/platforms. | Able to visualize and design complex systems with multiple product lines and integrations with external systems. Also should be able to design operations support systems like monitoring, reporting, fail overs etc. | |
| communication | Cannot express thoughts/ideas to peers. Poor spelling and grammar. | Peers can understand what is being said. Good spelling and grammar. | Is able to effectively communicate with peers | Able to understand and communicate thoughts/design/ideas/specs in a unambiguous manner and adjusts communication as per the context | This is an often under rated but very critical criteria for judging a programmer. With the increase in outsourcing of programming tasks to places where English is not the native tongue this issue has become more prominent. I know of several projects that failed because the programmers could not understand what the intent of the communication was. |
| code organization within a file | no evidence of organization within a file | Methods are grouped logically or by accessibility | Code is grouped into regions and well commented with references to other source files | File has license header, summary, well commented, consistent white space usage. The file should look beautiful. | |
| 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments | |
| code organization across files | No thought given to organizing code across files | Related files are grouped into a folder | Each physical file has a unique purpose, for e.g. one class definition, one feature implementation etc. | Code organization at a physical level closely matches design and looking at file names and folder distribution provides insights into design | |
| source tree organization | Everything in one folder | Basic separation of code into logical folders. | No circular dependencies, binaries, libs, docs, builds, third-party code all organized into appropriate folders | Physical layout of source tree matches logical hierarchy and organization. The directory names and organization provide insights into the design of the system. | The difference between this and the previous item is in the scale of organization, source tree organization relates to the entire set of artifacts that define the system. |
| code readability | Mono-syllable names | Good names for files, variables classes, methods etc. | No long functions, comments explaining unusual code, bug fixes, code assumptions | Code assumptions are verified using asserts, code flows naturally – no deep nesting of conditionals or methods | |
| defensive coding | Doesn’t understand the concept | Checks all arguments and asserts critical assumptions in code | Makes sure to check return values and check for exceptions around code that can fail. | Has his own library to help with defensive coding, writes unit tests that simulate faults | |
| 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments | |
| error handling | Only codes the happy case | Basic error handling around code that can throw exceptions/generate errors | Ensures that error/exceptions leave program in good state, resources, connections and memory is all cleaned up properly | Codes to detect possible exception before, maintain consistent exception handling strategy in all layers of code, come up with guidelines on exception handling for entire system. | |
| IDE | Mostly uses IDE for text editing | Knows their way around the interface, able to effectively use the IDE using menus. | Knows keyboard shortcuts for most used operations. | Has written custom macros | |
| API | Needs to look up the documentation frequently | Has the most frequently used APIs in memory | Vast and In-depth knowledge of the API | Has written libraries that sit on top of the API to simplify frequently used tasks and to fill in gaps in the API | E.g. of API can be Java library, .net framework or the custom API for the application |
| frameworks | Has not used any framework outside of the core platform | Has heard about but not used the popular frameworks available for the platform. | Has used more than one framework in a professional capacity and is well-versed with the idioms of the frameworks. | Author of framework | |
| 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments | |
| requirements | Takes the given requirements and codes to spec | Come up with questions regarding missed cases in the spec | Understand complete picture and come up with entire areas that need to be speced | Able to suggest better alternatives and flows to given requirements based on experience | |
| scripting | No knowledge of scripting tools | Batch files/shell scripts | Perl/Python/Ruby/VBScript/Powershell | Has written and published reusable code | |
| database | Thinks that Excel is a database | Knows basic database concepts, normalization, ACID, transactions and can write simple selects | Able to design good and normalized database schemas keeping in mind the queries that’ll have to be run, proficient in use of views, stored procedures, triggers and user defined types. Knows difference between clustered and non-clustered indexes. Proficient in use of ORM tools. | Can do basic database administration, performance optimization, index optimization, write advanced select queries, able to replace cursor usage with relational sql, understands how data is stored internally, understands how indexes are stored internally, understands how databases can be mirrored, replicated etc. Understands how the two phase commit works. | |
| Experience | |||||
| 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments | |
| languages with professional experience | Imperative or Object Oriented | Imperative, Object-Oriented and declarative (SQL), added bonus if they understand static vs dynamic typing, weak vs strong typing and static inferred types | Functional, added bonus if they understand lazy evaluation, currying, continuations | Concurrent (Erlang, Oz) and Logic (Prolog) | |
| platforms with professional experience | 1 | 2-3 | 4-5 | 6+ | |
| years of professional experience | 1 | 2-5 | 6-9 | 10+ | |
| domain knowledge | No knowledge of the domain | Has worked on at least one product in the domain. | Has worked on multiple products in the same domain. | Domain expert. Has designed and implemented several products/solutions in the domain. Well versed with standard terms, protocols used in the domain. | |
| Knowledge | |||||
| 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments | |
| tool knowledge | Limited to primary IDE (VS.Net, Eclipse etc.) | Knows about some alternatives to popular and standard tools. | Good knowledge of editors, debuggers, IDEs, open source alternatives etc. etc. For e.g. someone who knows most of the tools from Scott Hanselman’s power tools list. Has used ORM tools. | Has actually written tools and scripts, added bonus if they’ve been published. | |
| languages exposed to | Imperative or Object Oriented | Imperative, Object-Oriented and declarative (SQL), added bonus if they understand static vs dynamic typing, weak vs strong typing and static inferred types | Functional, added bonus if they understand lazy evaluation, currying, continuations | Concurrent (Erlang, Oz) and Logic (Prolog) | |
| codebase knowledge | Has never looked at the codebase | Basic knowledge of the code layout and how to build the system | Good working knowledge of code base, has implemented several bug fixes and maybe some small features. | Has implemented multiple big features in the codebase and can easily visualize the changes required for most features or bug fixes. | |
| knowledge of upcoming technologies | Has not heard of the upcoming technologies | Has heard of upcoming technologies in the field | Has downloaded the alpha preview/CTP/beta and read some articles/manuals | Has played with the previews and has actually built something with it and as a bonus shared that with everyone else | |
| 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments | |
| platform internals | Zero knowledge of platform internals | Has basic knowledge of how the platform works internally | Deep knowledge of platform internals and can visualize how the platform takes the program and converts it into executable code. | Has written tools to enhance or provide information on platform internals. For e.g. disassemblers, decompilers, debuggers etc. | |
| books | Unleashed series, 21 days series, 24 hour series, dummies series… | Code Complete, Don’t Make me Think, Mastering Regular Expressions | Design Patterns, Peopleware, Programming Pearls, Algorithm Design Manual, Pragmatic Programmer, Mythical Man month | Structure and Interpretation of Computer Programs, Concepts Techniques, Models of Computer Programming, Art of Computer Programming, Database systems , by C. J Date, Thinking Forth, Little Schemer | |
| blogs | Has heard of them but never got the time. | Reads tech/programming/software engineering blogs and listens to podcasts regularly. | Maintains a link blog with some collection of useful articles and tools that he/she has collected | Maintains a blog in which personal insights and thoughts on programming are shared | |
Thanks to John Haugeland for a
reformatting of it that works much more nicely on the web.
@John: the log(n) and 2^n refer to big O notation, ie how long it takes an algorithm to compute something based on n elements.
Nodding in agreement with most of George’s comments.
Thanks @Sijin for this great article. It would be even great if you can also tell us a roadmap or path using which a programmer can advance his skills from Level to Level 2 and from Level 2 to Level 3.
Creating a course out of this would be a great idea.
Great! thanks for sharing.
I think level 3 should also include “master Big O notation” in data structures/algorithms section.
This is a MUST at this level.
Found this same matrix here http://www.starling-software.com/employment/programmer-competency-matrix.html
It’s useful. Thank you.
So what types of difficulty would one experience jumping from one level to the next? Are there any steps to get to there?
So a good programmer writes in Prolog and can only do basic database administration? This matrix is interesting, but somewhat twisted in parts. I think though it serves a helpful model to adapt, but not one to copy-and-paste.
Your source control level 2 vs level 3 is very arbitrary. While I love DVCS systems, there’s absolutely no reason you wouldn’t rank a professional as a “3” merely because their work spaces did not use DVCS.
Quite good and useful tool, thanks for it. Nevertheless, IMHO, some dimensions need an update.
Here my suggestions:
– Rename the “database” row to “relational database”
– Add a row for “non-relation database” skills (to give room to document oriented, object oriented or graph DBs, Tinkerpop &c.)
– In the tools section: avoid the insistence in ORM, and maybe mention autotools or an equivalent
– Highlight the fundamental problem that an ORM solves: “Object-relational impedance mismatch”
– A row for scalability concerns would by very nice (v.g. clustering, time synchronization, distributed systems, data grids and caching topics)
Cheers!
This list is great and is probably the only one of its kind as of now. But it needs some catching up.
e.g. source code version control => Knowledge of DVCS is quite possible for Level 2 itself
For Level 3, I’d add the following
Database => NoSQL knowledge, Mapreduce jobs, ACID Vs. BASE
Scripting / Tooling => CI/CD using Ansible/ Vagrant / Docker
Interesting list, thanks for posting. I would suggest adding a rank column for real-world use, so that one could really “score” the results. Some of these criteria would be more important than others, depending on the specific skills needed for the situation and/or the environment.
Interesting stuff !!! thanks
I think you should add some machine learning skills to the matrix
Fantastic summary giving practical advice on what to work on to improve one’s abilities. Love it
Can I suggest that under defensive coding, you change “Has his own library to help with defensive coding, writes unit tests that simulate faults” to “Has their own library …” It looks like you’ve tried to avoid gender specific language elsewhere, so I assume that’s an oversight.
A more accurate title would be “paradigms exposed to”.
While some points might be right, this list represents a narrow minded perception of what a programmer should know. There exist areas where knowledge of embedded systems programming, digital signal processing or user interface implementation – to name just a few – are important, while topics databases are quite unnecessary. A good programmer is someone who knows how to solve specific problems in one or more specific areas by knowing proper tools and how to use them, keeping an eye on current trends and developments. And one who will not blindly follow popular paradigms.
Looks interesting, cheers.
I note the “Has his own library” – I think you mean “their” own library!
I would remove technology specifics which will cause this matrix to quickly fall out of alignment. Also under experience and knowledge, the languages used/exposed to seems redundant. Nice job pulling these thoughts together, In general, I think level three is a bit too easy to achieve so the list could use some tuning, or perhaps O(1) 😉
“Little Schemer”? Isn’t this a children’s book?
Overall this is a decently reasoned list that I respond well too. I am quite certain that the matrix has SOME ‘faults’ that might not apply in all cases, but I too have noticed many of the trends in this list and largely agree with the classifications. (One that I encounter WAY more than I think is reasonable, is inability to function AT ALL outside of an IDE.) This is just one that comes to mind, but others are notable. This is something that hasn’t changed in 20+ years as the IDE became more predominant (Borland/MS). I started hitting this in 94-95 when co-workers simply couldn’t reason why the ‘wizard’ was broken or couldn’t look deeper than the surface model exposed by frameworks (MFC/OWL) to solve problems. In SOME WAYS this trend was accelerated (at a different level) with the ‘managed language’ platforms. (But wow, some of the tools that ARE available CAN be exceptionally useful in the right hands given the extra meta-data the ‘managed platforms’ expose.)
Many of these issues are not addressed in interviewing and I think that this is missing. How EFFECTIVE a Software Engineer is largely (IMO) valued wrong. There is (at least in MY experience) at trend to want people to ‘function fast in cranking out code.’ This precludes ‘thinking’ AND I have been personally ‘dinged’ for exhibiting the secondary and ternary traits you describe in many of the columns. I find this ironic as I strongly believe that these TRAITS SHOULD be encouraged, but (many) current interview practices AND management practices ACTIVELY discourage people ‘going deep’ into a project.
I’ll have to think more about this, but I do like the general outline. Thanks.
Good starting point. It can be a simple reference for Engineers and Managers.
I have written few articles on Software Developers, Expectations etc. If you have time, you can refer http://optimism-careertips.blogspot.in/2015/05/software-developer-competencies.html
Found your blog. Its really have good information on computer programming. Really liked it. Thank you for all the information.
This is information amazingly useful to someone who does not have a grasp on these concepts. I will be using this to help build up my job description library.
Yes great article. Now I can make a roadmap of where I wan’t to be by the end of spring 2016 semester (which will be my last semester). Do you have any suggestions to how I can plot out my own personel roadmap to success???
Hey! I really love this map and I was wondering if you ever thought about updating it to 2015? I really think this map could be a bigger thing, we need a better grasp on programmers’ skills!
I think the map is great as it stands.
People who are saying “oh, it doesn’t include NoSQL” and “it doesn’t include Docker” are literally missing the forest for the trees. If you don’t understand the concepts, it doesn’t matter what tools you manipulate; you’re still cargo culting. And far too many of us spend far too much of our careers cargo culting in the name of the great god “expedience”.
I’m sure Level 3 represents the author
Would be great if the author could respond to questions left by his audience. Like, “how does one progress to the different levels in the table”?
You need to update the Version Control portion of this as it’s making it appear dated. Git is now completely replacing SVN at many places of work, so should be listed in the lower levels of the competency matrix.
I agreed up until “File has license header, summary, well commented…”, as stronger developers should strive to write self-documenting code. There are certainly cases in which comments can be useful, such as Javadoc or when working with a poorly-structured third-party. Otherwise, comments can be a sign that the code isn’t labelled and structured intelligently and potentially needs to be broken down further.
Fantastic list! Now it’s easier to objectively judge my own knowledge (and that of others). It would be nice to have an item on debugging as well, IMO.
Scott Hanselman’s Power Tools list is quite PC-heavy. Lua should be in the intermediate to advanced scripting. Can you set-up an Apache server from bare metal? How about scripting nginx configurations? Knowledge of what a proxy is, and a reverse proxy? API knowledge: REST calls vs. knowing how to traverse a Hypermedia response? Where’s concurrent programming models? Now about knowing how to interface with an AMQP server? And setting-up clusters of them? Functional first programming? Where’s the section on SECURITY??