I've interviewed many engineers. My process involves asking open-ended question about important topics, and let them explain.
Write down about 20 or 30 tidbits about the language you expect them to know. Include a range of simple, medium, hard, and, hard-core expert stuff. See where they fail, or where they struggle to explain or discuss.
You can't "practice test" your way into that, and it's always obvious where someone is knowledgable, and where they struggle, or don't know anything.
Further, I ask probe them for their 'problem solving' approaches. How do you learn new things? Name some of your favorite books on programming/development/design.
Oh, that last one, that may date me, cause I come from a time when they had these things called books. We would buy them, and read them. I've found so many developers that just say "oh, I google for it". Sure, that's great, and I google the crap out of things also.. but, here is the fundamental issue with "learning" that way.
"You only get the answer to the question you knew to ask."
The other answer, the one that says "oh, there is a totally different, but superior approach" you learn from reading and getting a solid background on the capabilities of the language/library/module/environment. Books (and online courses or comprehensive material is equivalent) teach you that stuff.
The best programmer I ever hired read books. She (yes, she) was far younger, and unlike her peers, had discovered that reading and keeping some books in your library is valuable.
My advice, ask them what they read. If they "just google it", kick them to the curb. "Next".