I find it particularly difficult to assess my skills in a specific programming language.
Even if I've done some projects solely in one language, I feel like that's not enough for me to say that I'm comfortable with that language.
Then the question is: when and how should I say I know a language? More precisely, when should I add one to my CV?
Add a language to your CV when you are fluent enough in the language to understand all the syntax and you can read anything written in the language and you have written code yourself in it. This doesn't mean you are an all out expert and know every detail, just that you are capable in the language. Most of the time we use 60-80% of a programming language IME, so once you know that common set you are good. That other 20-40 percent of a language is usually specialized to specific things or fringe and not common, so not knowing those fluently is fine IMO.
Put another way, you know a language when you can pick up any project written in it and can read it intelligently without having to look up what common library functions do (not all of course, but the most common of the functions).
When you:
* can read gnarly real-world code with confidence
* know the stdlib and common libraries reasonably well
* have written something significant enough to be a good demonstration of your skills in that language, either at work or as a side project
Everyone with some programming experience knows that needing a refresher on a language you haven't used in a while is normal, so you can safely put languages on your resume that you used a while ago as long as you have brushed up on today's ecosystem.
As a general rule, the more senior you are, the more in-depth knowledge you'll be expected to have about anything you put on your CV. For that reason, splitting technologies up into a few different levels of proficiency is a good idea.
I've tried to distinguish levels of proficiency with a language in my CV. For example, "expert/highly proficient", "proficient", or "familiar". There's only one or two that I'd consider myself "highly proficient" in, and probably a half dozen that fall into the latter categories. Gives you some flexibility to say "hey, I've worked with [language X], but I'm not as strong as I am with [language Y]"
List if you can write code in the language. If it comes up in the interview you can elaborate on your skill level.
From a practical standpoint, when you can write idiomatic code in the paradigm that the language supports.
And inversely, when you can confidently do code reviews and your comments are in the idiomatic zone.
The breakpoint for me is when I stop looking at "how to do x" on the internet. I do it from muscle memory.
As an employer, broadly speaking, the languages you know doesn't matter. I'd rather hire a "good programmer" than a "knows X" programmer.
A good programmer will be able to "learn" a new language in a matter of days. [1]. Factor in a few more for new IDE etc. A bad programmer writes bad code in all languages.
All coding starts in the head, with ideas on how to go about solving a problem. Good knowledge of one language at least makes that easier. Being able to express the solution in elegant code is the key skill. Knowing the syntax for comparing strings is meaningless - anyone can figure that out in no time. Understanding what string comparison means is much more important [2]. And so on.
[1] within reason. Imperative languages are all the same. Functional are all the same, but I would not hire an imperative programmer for a functional language or vice versa.
[2] turns out comparing unicode strings for equality is a whole barrel of fun and starts with deciding what "equals" even means...