I get asked "how good are you at {a programming language goes here}" and quite honestly, I'm not sure how to answer them.
I can judge if I am beyond beginner when I know the key structures and could make a basic web page in that language (assuming it's web based) but the line between intermediate and expert is somewhat blurred.
To some extent, I think that sort of question is misleading to begin with. Once you reach a certain level of competency in a language, your skill in that language is moreso governed by your overall capability as a programmer than your skill in that particular language.
In other words, when write C code, I'm not "programming C"--I'm just programming. I don't think much about the specifics of the language when I code--they are second-nature. IMO, once one reaches a certain level of experience, one thinks less about the language and more about what one is actually writing.
The sky is the limit, you can never be an expert on some programming language. You can be called an expert by others but you can never say you know every detail of a programming language.
The line between intermediate and expert isn't determined by how well you know the language, but rather by how well you know programming. Even if you don't know all the "cool" ways to do something that are provided by the language, if you're an expert programmer you will use the tools you do know about in elegant ways -- and chances are you'll find out about the "cool" ways pretty quickly.
The question should be: "Are you confident enough in your own skills to accomplish some arbitrary task?" You don't have to know how to do everything just off the top of your head, but as long as you can formulate a path from problem to solution and are able to take the first step, then you're probably in the "expert" category.
Real programmers use documentation and external resources all the time. Mastering a language has nothing to do with memorizing the library backward and forward, it is understanding its idioms and composing them to express complex ideas. When you are comfortable with that task in a given language, you can consider yourself quite accomplished.
"Intermediate" and "Expert" are hard to back up by themselves.
Instead, answer these types of questions:
It's hard to naswer, because the question is vague. it does not define how you measure good. in c# parlance, no IComparer is given ;) Clearly you can tell beginner from somehow advanced programmer, but how do you tell how good someone really is? Is someone who knows language specification better than someone that does not, but instead can do crazy things with some aspects of a language? I've been programming in c# (my language of choice) for quite some time, and still I find things that suprise me. Another thing, is that each language comes with its standard library, and it's not practical to talk about one without the other.
I don't think you can answer them with a sentence. If they seriously need to know (perhaps they're a prospective client), a portfolio of work is the best way to show exactly how much you know and how much experience you have.
Proficiency at programming languages is like proficiency at a martial art. No matter your skill level, you are a hundred times more proficient than some people, and there are people a hundred times more skilled than you.
And though I wouldn't call myself a novice today, I have always felt like I was a novice a year ago. A year from now, I'm pretty sure I will think I was a novice when I answered this question. So yes, it's very hard to answer that question!
If I were you, I'd give examples of the kinds of things I can do, like, "I could write Mario 3 in a year of free weekends". That's pretty easy for other programmers to relate to, and to laypeople it sounds really impressive. :)
You should really be thinking how well you can think like a computer scientist. Non-technical people get worried when they ask you to do something for them in a language or system and you tell them you've never used it. Whether or not you can pick it up quickly answers whether you are a good programmer.
I'd just go with how many years of experience I have in the language. Or, for those who can, how many books you've written about the language.
Or you can return the favor by asking them to define "good" in the context of knowing programming languages. That should teach them.
It seems to me this is a rather subjective question, but I, personally, would make a point to clarify that being good at programming is language agnostic and that you skill-set is not limited by language, but rather a compilation of all the experiences you've had with all languages. I can learn a new programming language pretty comprehensively in a couple days and google the tidbits here and there when needed, but more important than the exact language, the patterns and practices involved with various programming styles is much more important.
Personally, I feel that core language concepts, like those expressed in functional languages, scripting environments, object-oriented design or generics/templating are more important than how much syntax of any given language you know. Somebody who knows C# can switch to Java pretty easily, whilst somebody who knows JavaScript might not transition as quickly, and likewise a PHP programmer might not move to F# as well as someone with Haskell experience and somebody that already has .NET experience might beat the both of them because they already understand the patterns frequently used in the .NET Base Class Library. I think you should gauge your skills based on your confidence and past experiences if you're questioned about a new programming language; if you're an expert in something, make it a topic, not a language (like a Service Oriented Architecture expert should likely be able to accomplish their task with J2EE, ASP.NET or PHP depending on the requirements).
I would argue that when this question is raised, it's missing the point - especially if it's just for bragging rights. Even in a job interview, it's a much too surface level and subjective question just because everybody has a different perspective on it.
I love JP Boodhoo's (http://www.jpboodhoo.com) view that you're absolutely wasting your time if you're constantly comparing yourself to other developers. The question to ask is whether or not you're a better developer than you were a year ago and whether you'll be further along another year down the road.
[UPDATE] Wow, there were three answers when I started writing, and 10+ when actually posting....
I went through a couple of Ruby books and I still very very much consider myself a beginner, but I actively work with VB.NET and I feel like I am much more experienced in that. While I still feel that I am a beginner in the world of VB.NET, I feel much more experienced with that because I use it so much. I now feel like I'm more experienced with VB.NET than C++ too, even though I learned on C++ and used to use it all the time.
I guess for me it comes down to how actively you're using a certain language.
For me, this depends upon who is asking the question.
If it is another programmer just trying to see how big his (or I suppose hers) is next to mine then I usually punt the question. I find that most often what they really want is to tell me how good they are at {a programming language goes here}.
If it is an interview frankly the only answer I would give is some derivation of fantastic. It is not lying if you are being self-delusional.
I think it is a bad question because it skips past what I believe is the important thing which is someone's ability to solve problems. Having a foundation in the language is important but not always mandatory. I like to show people code that is not in the language they are going to be working in to see if they can figure it out.
Personally, I have tried in the past to emerse myself in a language and become a syntatic expert and I just cannot do it. It is counter to how I function. I think more like solve the problem like this, now how do I do it in {a programming language goes here}.
As with human languages, there are definitely distinct levels of proficiency, and between and beyond them it's more about your other skills and abilities than language knowledge. I'd identify in particular:
No specific knowledge of this language but knowledge of the language group. For example a C programmer can get some idea what's going on in the source code of a Java program, because they're both curly brace languages with some similar ideas about what symbols represent and so on.
Novice: Can write simple programs, often after much trial and error, can also read simple programs. Does not know many control structures, data types, etc. of the language but only a subset they have learned. Finds it difficult to learn about other features of the language from reading other people's code. Tends to use the idioms of other programming languages they know better, for example they might make heavy use of recursion in C if they're really a LISP programmer. A C programmer learning C++ might create one class called "Program" and put everything inside that class.
Able: Can express any program in the language, perhaps with some difficulty and use of reference book. Knows most features of the language to some degree, and can pick up new features by seeing them used. Uses a few idioms from the language they're learning, but doesn't have much of a distinctive style of their own. You can assign an "Able" programmer to do useful work in the language, so long as you don't mind it taking longer and not being of very good quality.
Fluent: Finds it easy to express programs or program fragments in this language. Spots errors in other people's code in this language. Knows all but the most obscure features of the language, though they may not have an entirely accurate knowledge of how to use them correctly. Has a consistent style which combines the idiom of the language with their own personal preferences (and any house rules). Can offer a useful opinion about whether the language is suitable for a particular problem. You can assign "Fluent" programmers to do useful work in the language and should expect code written quickly and efficiently which does the intended job to a good standard.
A good programmer would necessarily be fluent in at least one language. But they wouldn't necessarily even know any others to a basic standard. However from a career point of view it makes sense to learn several quite different languages, just to get a feel for how they vary - and I think any good degree course ought to offer you at least the opportunity to do that, before you (perhaps) go into industry.
Beyond those levels I might identify an "expert" as being someone who is not only fluent in the language, but has actively studied it as an end to itself, rather than as a means to become better at programming. Such people aren't necessarily better at producing programs written in the language, but could be useful if you think you need a custom language which is similar, or need to create tools (such as a compiler) for the language.
How well you can read code? Especially bad code.
Obviously you have to be comfortable writing code, and you have to know what library functions are available, and so on. And at a basic level, reading might seem easy, because you can guess a lot from context or similarity to other languages. But you don't need to know operator precedence to write a long expression, because you can add more parentheses when in doubt. You do need to know operator precedence to correctly read a long expression without parens.
Consider a "spot the bug" interview question containing an algorithmic flaw (unchecked buffer, say), and a misuse of a language feature (incorrect operator precedence, say). A general programmer spots the former. Someone who knows the language spots the latter. The person you want doing your code review spots both.
Beyond basic level, the same applies. Most languages have obscure corners you wouldn't use every day, or even every year: an "expert" might be defined by how well you have those covered. The true expert level is that if you can write a compiler/interpreter, that means you can read anything written in the language.
I try to answer the question by reference to years experience, projects worked, and comparison with other skills the questioner is interested in. So rather than saying, "intermediate but not expert", say, "it's not my main language, but I have spent the last couple of years supporting a product with bug-fixing and new features, for half a day a week". The reason for this is that since there's no standard meaning of "expert", you could waste a lot of time agonising over what languages to claim "expert level" in, but the questioner gains no information useful in comparing you with other people.
Knowledge of a programming is like a funnel, you start at the narrow bottom and go up. At the bottom it is easy to believe you know "everything". The further up you, go the more you realize that there is so much more to know. You broaden your horizons...
:)
//W