I've run into a lot of website and job-application questions, attempting to quantify my ability to do programming. The obvious first problem here, is the question, “how many years have you used said language (or any other tool)?” Are we talking home, work, both? How do you accurately reflect the couple of years you may not have used a language, or had to re-learn it? However, that situation pales in comparison to the real metric…
I think a solution here may be best presented as a rubric. In my time moderating r/altprog, I've had the chance to look at a bunch of interesting languages. And as my schooling and IT career have chugged along, my own experience is a mishmash of some 21 languages over 30 years. The following is a rubric, that can be applied to a table, or possibly turned into a numerical score/index (except for the last point). I was able to get some help from folks on Reddit, and friends of mine, to put together the following…
We all start from here, and that's the most basic test of how to get going. A lot of programming books / tutorials will have details on setting up an IDE, compilers, runtimes, etc. Note: not all languages are compiled (especially scripting ones).
Can you write a basic program from scratch?
Any program worth its salt is going to have repeatable tasks, that you can call upon with functions, subroutines, templates, etc. It may even be necessary to call functions from other functions, in a Russian nesting doll fashion. Some scripting or niche languages may not have this ability and obviates most of the subsequent points.
Languages such as C++, C#, and Java; rely heavily on the use of classes to segment variables, functions, returns, etc. And many languages support some kind of type-management: either to create custom variables, create dictionaries and/indexes of values, and treat data the way a function might be treated for re-use and/or clarity.
Java, in particular, relies heavily on binding together classes, that may or may not have been imported from an external library. Other languages rely heavily on “import” and “include” features, that permit code-reuse between programs. If you've had to use a Windows DLL; work with a Linux .so file; load something from pip, nimble, cargo, etc: you're using libraries. So, are you able to make those yourself?
Newer languages have documentation features, that can be parsed by tooling to create documentation available in HTML, Markdown, or other formats. This is particularly useful when creating libraries for others to make use of.
Different languages have advanced features, that aren't always put to use by developers. But utilizing those features may make code easier to read, more performant, and/or expand the possibilities of what you can code. “Design patterns” definitively fits in this category.
Usually, issues with code can be figured out via normal code editor tools. But sometimes it may be necessary to deploy a proper debugging tool, that can read values from memory and track program execution. This isn't always easily to accomplish, and not all the necessary details may be immediately clear. Many languages do have some kind of runtime debugging support in IDEs, or REPL / run-time execution.
A relatively new “best practice”, various code coverage suites have been developed for different languages, that can assure certain things will work upon compilation and/or execution. Via “unit testing” and other checks, you can determine in advance if undesired behaviors may occur when using your program. Some argue that this should be an earlier step, but it's still technically possible to do the other steps first: this practice will help guarantee that earlier code works.
Teaching others, giving talks, writing books, creating guides… you are truly a master of this language.
Many languages are open to the community for adding features and debating changes. And maybe you originally wrote this particular language?
This is an attempt to qualify if you feel comfortable working with a language. Maybe it's been a few years, and you can't pick it back up? The baseline here might be if you expect to fail on a LinkedIn test, code interview, or other measurement.
This is my own experience, as of November 2022; you may come up with a better way to implement this. Also, some of these features don't apply to these languages, but I can't confidently mark those at this time (folks usually try to fill in those gaps on their own).