Tim Etler

Stop using skill charts

November 21, 2013

Recently, I’ve noticed that the trend of using skill charts on your resume has become increasingly popular, particularly with new candidates looking for their first serious job. Many of these candidates are still inexperienced, so they want to show that even though they don’t have professional experience, they still have familiarity with programming. Normally, the chart would look something like this:

Language Beginner Intermediate Advanced Expert Master
Java
Haskell
C++
Python

The problem with these charts is that the candidates typically lack enough exposure to real industry experts to properly calibrate their scales. A skill chart is a heuristic metric, and it will vary from person to person, or even vary with the same person over time. You are a terrible judge of your own skills, and a year from now, you’ll probably have enough new experience to completely change your perspective on what makes a skilled programmer. An appropriate scale for people just learning to program might look something like this:

##Beginner:

  • At this stage you really have no idea what’s going on at all. You’re just following tutorials and much of it is foreign to you. If you can get something to work at all, you’re happy.

##Intermediate:

  • You’re starting to get a hang of this whole programming thing. The programs you make are no longer trivial, and you can start to solve actual problems and automate tasks. You still rely heavily on examples, but you need less hand holding by the day.

##Advanced:

  • After getting a few projects under your belt, you are now starting to feel more confident about programming. Your programs are becoming more usable, and maybe some other people are using them too. You’re starting to understand the more advanced features of a language and you’re thinking about pursuing programming more seriously.

##Expert:

  • You’re really getting into it now! You feel like you know the language like the back of your hand. There’s still really advanced features that you don’t understand but it hasn’t inhibited your ability to code, and you don’t need to know that stuff to be productive right?

##Master:

  • Almost any programming problem you face, you feel you can tackle. Your programs are getting to be very long and complex, full of lots of features. You haven’t worked seriously on a team yet, but how different could working with other programmers be?

Ok, this scale is on the low end of the spectrum, but it’s a fair scale for someone just starting out. At that point, programming seems to be more about what you’re capable of doing, not necessarily how you do it. The problem is that where this scale ends, is where my professional scale begins. At the professional level, you’re being paid for your services, and you should be able to tackle pretty much any problem. If your code quality isn’t up to snuff, you’re going to require hand holding to make sure your commits are up to the standard of the codebase. This is what I find to be an appropriate scale for professionals:

##Beginner:

  • Almost any programming problem you face, you feel you can tackle. While you can get something to work the code might not follow best practices, or might be much more complicated than it needs to be when a standard library function could do most of the work. Your code needs closer review and the time of a more senior member before it’s good enough to be merged into master.

##Intermediate:

  • You can handle most programming tasks on your own. Most of your code reviews only have a comment or two. You know your way around a professional code base, and keep code quality up to standard. You are completely comfortable within your project’s framework.

##Advanced:

  • You’re now handling entire programming projects, and even architecting new frameworks. You’re in charge of code quality and leading projects. You have strong experience in across multiple coding paradigms and know how to pick and choose which ones are best for the task at hand.

##Expert:

  • Your opinion is sought after. You do tech talks, and are considered an authority on the subject. Your expertise is wanted for the most important components of the system, and you’re overhauling old projects, and leading large complex projects. You’re setting down the foundations for future generations of programmers who will work on the system.

##Master:

  • You are one of the authorities on the language. You are among the leaders of the language community. You know the spec like the back of your hand. You work on the compiler, or interpreter, or maybe you’re on the standards committee, and you know nearly everything there is to know about the language, including detailed implementation knowledge, so you know the strengths and weaknesses of the language intimately. You are, after all, a master at your craft.

Now this scale, is at the high end of the spectrum, and is what I expect from established industry professionals. Now any given candidate’s personal scale can fall anywhere within the two scales. It might encompass parts of both, or be a subset of one. And therein lies the problem: everyone has a different scale.

When you use a skill chart, one of three things will most likely happen: If your scale is lower than the scale of the resume reader, then you are overrepresenting your skills, and the interviewer may think you are more advanced than you really are. This may lead to a nasty surprise at the interview where the questions go beyond the scope of your abilities. On the other hand, if your scale is higher than the reader’s, you may not get to the interview at all, as you are undervaluing your skills to that particular reader. This may be the case when your resume is filtered through non technical people, who don’t understand what programming abilities are expected on a professional scale. Many companies use HR or a recruiting agency before resumes are seen by engineers, and if you don’t seem confident in your skills on their scale, that may be seen as a red flag. Sometimes, the scales may happen to line up between the candidate and the reader, but to which reader? HR or engineering? And even if they do line up, there may still be a level of doubt.

All this leads to skill charts being easily misinterpreted, and that space would be much better served by talking about your experience instead of dumbing it down to a value on a scale. A scale tells me little about you as a programmer, and little about your actual skills, other than your self perceived ability, of which I have no idea what that is. If you can’t think of a decent project you’ve worked on in a particular programming language, then you probably shouldn’t be advertising that you know that language in any form. Non work experience is fine. For example, I haven’t written any C++ code professionally, but I have written a 3D graphics engine in C++ for a college course. That one project is far more representative of my experience with C++ than any single word, and it doesn’t take much more space than a bar on a chart would. If you want to accurately and honestly reflect your skills in your resume, bringing in past experiences will provide a better picture of you than a skill chart ever will.