views:

451

answers:

6

When you are asked to rank yourself in skills from 1-10. I don't know what to depend on. I know if I rank Jon Skeet as 10, then I probably at 5 even I got 7 years experience. Then employer (HR people) who never heard Jon Skeet definitely won't hire you because they think you are too junior.

But at my day to day practice, I think I am OK.

+1  A: 

It's going to depend on whether you think you're going to get asked to prove it, but in general, it's a good idea to come in the 7 to 9 range. 9 if you're awesome. Really. Few people like to hear you say you're a 10 because they will chalk it up to your ego.

However, if you say you're a 3 or 4, people are inclined to simply believe you :-(

I would suggest using this as a way of differentiating what you're good at from what you're not. Not good at windows forms? Ok, say 5. A lot better at SQL in comparison? Say 8...

There's not going to be a right answer to most interview questions. There are so many different ways that people interpret the answers they get in interviews, the best you can hope for is that the honest answers you give are valued. Then (hopefully) you have found the right position.

A: 

Answer it honestly but not using Skeet as a metric.

ojblass
A: 

You said yourself you don't know what to depend on, so ask them what their scale is. Then, answer appropriately. You can also discount the highest values as "impossible", stating that everyone always has more to learn.

You can also change the definition of "skill" to suit your needs, if they have not already defined it for you.

lc
I agree, Skeet goes all the way up to 11, so it's not really something to compare to. I would say I'm a 8 or 9 in some skills, even though I don't know half as much as some of the uber programmers. You probably have to throw out the bottom and top 5% of programmers to get good numbers.
Kibbee
+4  A: 

Generally interviewers ask this at the start to figure out where you feel your strengths are. Give values in accordance to how many questions you might want on the subject. From looking at a CV it's often hard to tell where a developer has the most experience. A good interviewer will only ask questions to skills you've listed on your CV. I might interview a candidate who knows a lot of .Net for a Java position. A good developer shouldn't have trouble picking up a new language or skill. If the candidate knows the position is for Java and ranks their Java higher than their .Net skills, then they are doing themselves a disservice.

As a general guide, if you think you know more about the subject than the person who will likely interview you, rank yourself a 9. Don't go for the 10, because even if you know more about a subject than the interviewer, the question asker can usually come up with the question to which you don't know the answer off hand. If you rank yourself to high and get several questions in a row wrong, then the interviewer might give up, feeling you don't have a realistic view of your skills.

Probably most of your skills should rank 3-8. Below 3, it's not worth putting the term on your CV, and 8 generally means you know the subject pretty well but haven't written a book on it.

brianegge
+3  A: 

Consider the three-bin protocol:

  • Lead a discussion in topic X
  • Follow a discussion in topic X
  • Don't know topic X

Expand that to:

  • Implemented a compiler for language X on more than one platform
  • Implemented a compiler for language X
  • Conduct a 12-week seminar
  • Conduct a 5-day training course
  • Lead a 45-minute discussion
  • Lead a 5-minute discussion
  • Follow an "X - Advanced Topics" discussion
  • Follow an "Introduction to X" discussion
  • Follow a "Pre-requisites for X" discussion
  • Shoot me

Not a linear scale.

Also:

This is a trick question, when Eric Lippert asks it:

Good candidates will clarify the question before they attempt to answer it. Bad candidates will say "oh, I'm a nine, for sure!" without saying whether they are comparing themselves against their "CS360: Algorithmic Design" classmates or Stanley Lippman.

Thomas L Holaday