How to accurately quantify your ability of a technical skill on a scale of 1 to 10?

Question

During interviews for engineering / technical positions I am always asked the question:

Regarding your experience with ____, how would you rate yourself on a scale of 1 to 10?

I find this very hard to quantify with programming languages because the more you do know the more you realize how little you know.

1. Is there any sort of standard system to figure out where one might rate on this scale?
2. If you're unsure is it better to go higher or lower during interviews?

Answer 1

Given how the answer seems straightforward, but is really dependant on your own perspective, I'd say clarify your perspective in the answer... something like:

I find that the more you know, the more you know what you need to learn. Generally I'd rate a "10" as ((insert how you define ultimate knowledge)), and "1" as ((your own words on very basic knowledge)). In my opinion, you need at least a ?3? to be trusted to code in a language reasonably successfully with peer reviews only for complex issues and high-stakes verification, and at an ?8? you can help most other people... in X language I rate myself an N and here's why..."

Yes, very wordy, but it gives them a great sense of how you see the world. I'm a big fan of being able to clarify where I expect to fit in the team, because team work is such a big part of me and my career. You may see it differently, and want to give a different example of how you rate skills in comparison to how you contribute on the job... but showing the employer that you have a reasonable grasp of how your skills fit with the job function is a real win here.

Standards:

I don't think there's really a standard, since demonstrations of behavior are a factor of both domain knowledge and other skills... for example, a great teacher with a solid knowledge of the basics may be a much better teacher than a vast expert who can't string two explanatory sentences together. In general, my personal rating system is:

1. I picked up a book and tried a simple project or two.
2. I can do basic things, and use a few of the special features.
3. I can use the language well enough to the do the right thing a decent amount of time. I can debug. I'm not always elegant, but at least I get the basic gist. NOTE: for some types of languages, this can be enough. In others that rely on complexity, this can be downright dangerous.
4. I do better than that.
5. Middle of the road - I've been working in the language enough to do the right thing most of the time. No one will read my code and think "WHAT IS THAT???".
6. Better than that.
7. Has a good working knowledge of some of the real nuances and special features of the language. Not only syntax but why is one approach better than another for a complex situation.
8. Has become the go to guy. For hard debugging, for tricky/risky designs - this is the guy who can get you on the right track in a sentence or two cause he just gets it.
9. Better than that.
10. Can write the next book on it. If he's not blogging, lecturing or otherwise talking on the topic, it's because he doesn't like that part of being an expert.

Risks in Rating

Generally, be cautious with the extremes. If you have slathered this technology all over your resume, you better be around a 5 or better. If you have it on there at all, figure you need at least a 3.

If you rate yourself at a 8 or better, you're advocating a really high skill set. Absolutely great if you have the skills/knowledge to back it up - but prepare for a good solid quiz or deep dive with a fellow expert. Dangerous ground in the 9 & 10 range, because if you are wrong and you're really not an expert, you'll come off as dangerously overconfident.

I'm not saying that to warn away from numbers outside of the 3-7 range - if it fits, it fits. But be prepared to justify.

Answer 2

This question is almost completewly impossible to accurately answer, shown particularly by the Dunning-Kruger Effect.

So then, what to do? On one hand, ask yourself how in depth you can go during the interview on the topic. These questions are often a way of negotiating what a valid set of questions would be. Saying "10" is going to be code for "I know everything, and can answer every question you have".

The only time I ever use this in an interview is when I pair it immediately with something like:

How would you get from (Your Answer) to (Your Answer + 1)?

In that case, I am using the questions to judge your ability to rate yourself, as well as your understanding about what you do not know and how you would learn it.

Answer 3

When asked this question in a face to face interview and it is a technology that I have worked with to deliver any non trivial project then I always say 10 and also give some details of the problem I used the technology to solve.

The reason I do this is because the question is completely meaning less, like the questioner states, its very hard, if not impossible to quantify such a scale and the person asking the question is going to have a different level of expectation than the person answering. Even if that wasn't the case there is no way for any answer to be verified in any meaningful way anyway.

So I believe the only way to take the question is as the interviewer asking you how confident you are in your ability to fulfil their requirements. Almost as if they are seeking your reassurance that you can do the job.

Also usually by the time you at the stage of a face to face interview you have already passed any technical tests they have set you so they already consider you to be at a level at which they are willing to hire you.