Why I Put Skill Ratings On My Resume

Tl;dr — My skill ratings generally indicate how competitive I should be with peers who are skilled in a specific technology, based on my own assessment of my level of proficiency and familiarity with that technology, following an asymptotic curve.

What They Don’t Tell You

• Whether I am “good” or “bad” at something
• Whether I “like” working with something
• What percent I possess of all possible knowledge about something
• How much interest I have in something¹
• How many years I’ve worked with something²

Why I’m Talking About Them

When I created the first iteration of my current professional resume last year, I included ratings for each of my highlighted skills using a five-star system. This feature has since spread to my portfolio website as well. I’ve had some people ask me about the real meaning of that data and how it should be interpreted, and a few have openly questioned whether its actually sending a good message. I thought it would be a good idea to share some thoughts on why and how I rate my skills on my resume, in case it’s helpful to any consumers of my resume, or to anyone considering a similar approach for themselves.

What They Mean

The sentence at the top of this post is the most concise definition of my skill ratings.

My skill ratings generally indicate how competitive I should be with peers who are skilled in a specific technology, based on my own assessment of my level of proficiency and familiarity with that technology, following an asymptotic curve.

Let’s break that down.

• How competitive I should be — My estimation of how well my skills are likely to hold up against others who are skilled in the same thing, based on what I know about how the technology is used.
• Peers — Speaking very abstractly, “peers” are people with whom it’s reasonably fair to compare myself. Obviously I’m not comparing myself to someone with 20 years of experience in TypeScript³, or the singularly talented people who invented things like React or Babel.
• Specific technology — I rate my skill in a technology, not in any particular application thereof. I might claim mastery of TypeScript, but that doesn’t mean I have used TypeScript in every popular or possible application context. This is one reason I link my skills to actual projects whenever possible.
• My own assessment — Ratings are not based on any sort of external scoring system or defined measurement of specific competencies in a given technology.
• Proficiency and familiarity — My ability to use the technology successfully in a project through a combination of knowledge and critical thinking, and my general understanding of how the technology works from basic to advanced concepts.
• Asymptotic curve — I firmly believe that there is no programmer who knows everything there is to know about any technology (with the possible exception of the creator). A maximum rating does not mean I believe I know everything; it just means I believe I know anything you’d reasonably expect a person skilled in that technology to know.

Why I Created Them

If you look at my resume, and even more so my portfolio, you’ll see that I have some degree of experience with a wide range of technologies. I like to experiment and learn new things, and I’ve never been completely focused on one part of the stack. As a result, my knowledge is broad but not evenly distributed. I have deep knowledge of JavaScript, for example, but I’m still relatively new to MongoDB.

This creates a transparency challenge when it comes to listing my skills. I could choose to list only the very strongest skills, and forfeit any benefit that might be gained by showcasing my versatility. Or, I could choose to list everything, which could either seriously oversell certain skills, or come across as resume-padding. I didn’t like any of these options, because they all have the same flaw: they fail to provide an accurate representation of my skill set.

Assigning a rating to each skill solves all of these problems. It allows me to highlight the wide variety of things I can work with. It prevents anything from being oversold by clearly pointing out where I’m still learning, while also pointing out where I’m an expert. And it doesn’t come across as resume-padding because I’m making an up-front statement about my knowledge of each technology that I can be expected to back up (more on that below).

Why I Have Some Low Ratings

I have received some comments that listing a skill as only a one or two out of five could be interpreted very negatively in some circles. I understand the idea here, because one-to-five rating systems are often used for things like product reviews, where one star equals an abysmal product.⁴ But my hope is that people interpreting it that way will be few and far between, because I honestly don’t think that makes a ton of sense in context. It’s a resume, after all; who puts “I am abysmal at React” on a resume? If that were the case, you and I would both just leave React off the resume entirely. If we put it on a resume, it’s because we’re trying to say something good.

Why You Should Trust Them

You shouldn’t. There, that was easy.

Or, to be more specific, you shouldn’t trust them blindly. You should understand by now, after all, that they are subjective. What you should do is use them as a starting point for discussion or consideration. I don’t put down skill ratings that I don’t think I will be able to back up. By understanding my reasoning behind the ratings, you should now understand what it is I’m trying to say with them, and determine for yourself by talking to me or looking at my public code whether my self-assessment is likely to be reasonable.

Notes

¹ My resume shows the skills I most want to call attention to professionally. Leaving a skill off the list doesn’t mean I’m not interested in it, nor is it safe to assume I am more interested in higher-rated skills.

² In general, I don’t support putting a ton of stock in “years of experience” with a technology. While there is certainly wisdom that can only be gained over time, the pace of learning, the quality of learning, and the breadth and depth of applications all can vary greatly from one environment to the next. “Four years of JavaScript” just really isn’t the universal constant some people seem to think it is.

³ This is a hypothetical example. It’s not actually possible to have 20 years of experience in TypeScript. (I’m looking at you, recruiters.)

⁴ Some people seem to treat these ratings like the Michelin system, where one star still represents good quality, and bemoan that they are “forced” to give at least one star. This interpretation is wrong, a fundamental misunderstanding of the paradigm, and potentially the subject of a future long rant blog post.