The solution to this problem is to follow up the question with "oh, so you're an eight, great, what is something that a seven would have difficulty with?" Make them calibrate the scale for you.
Or flip it around, and ask them what they are going to do in order to get to 9. It shows how self aware they are of their own knowledge gaps and also calibrates the scale.
On the off chance they say 10, well, they better know just about everything.
(TL;DR: Multi-purpose languages are pretty large and used in particular ways across different domains. It doesn't even make sense to ask about the difference between a 7 and an 8. An honest interviewee with become bogged down realizing they're not a competent social science researcher who can design useful fine-grained rubrics, and will refuse to give any answer to these questions except a long-winded and hopefully not too ego-bruising "this is stupid/doesn't make sense/it depends/I'm not a 1. Everyone else in the 3-8 range is just bullshitting the +/-1,2 deltas. So in other words, the entire number and reasoning is completely just BSing.)
> what is something that a seven would have difficulty with?"
My honest answer is "this is an ill-posed question and there's no way of stating for certain that feature X or library Y is something every FooLang developer who's not as good/informed as me doesn't know."
But of course that won't get me the job. So I just pick based upon my perception of your personality/background from the 5-8 range. When asked for justification, I choose the most esoteric-but-not-inconsequential thing I know and bullshit for a minute or two while being personable. Whelp, that was a useful signal as long as your goal as to find a professional bullshitter...
Concretely, I've created stand-alone implementations and hacked on compilers for a couple of languages, but would not have a non-BS answer to this question for those languages. Mostly because I'm totally unfamiliar with the most recent set of popular libraries in that language's ecosystem, and also there are certain language features that I know how to implement but don't know the canonical usage patterns/idioms. Your standard FooLang dev could probably hack together certain programs in their sleep that would take a week for me to write. But then for other programs -- or especially if you needed a static analysis or optimization -- I could whip it up in a couple of days where the standard FooLang dev would probably take weeks just getting up to speed on the language spec and some particularly thorny parts of the implementation. Hm. Apples and Oranges. And what if you want a static analysis/optimization that exploits idiomatic use of FooLang's whizz-bang BarLib? Hm. Not sure who has the upper hand.
I know you'll say "but that's the point -- I want to hear exactly that reasoning so I know what you know/how you assess language familiarity." But this is all meta -- performance on this question crucially depends upon 1) ability to bullshit (i.e., come up with plausible-sounding hypotheses and give plausible reasons for them, quickly and on-the-spot -- this is not a particularly crucial skill in software development); and 2) ability to intuit the purpose of the question.
In conclusion, I'm not really sure what the point of this exercise is, except to select for bullshitters or people who read your HN posts.
> Make them calibrate the scale for you.
You're not just asking for a calibration, you're asking for a rubric and a scale. That makes a lot of sense as an interview task if you're hiring a manager who will be doing lots of interviewing or a business processes/HR processes expert/researcher. I'm not sure why this is a relevant skill for a software engineer, though.
