This would be like how much English do you need to get a job at an English speaking company?
If the domain of the programming is really specific such as financial machine learning, or embedded systems then a tiny handful of fizzbuzz tests would be enough as the core questions would all be about the domain knowledge. But if the job involves pushing C++ right out to its limits where the company has occasionally made contributions to LLVM or GCC then maybe the minimum knowledge would be that of a C++ god.
But the simple reality is that the surface area of C++ and its applications is so large that as long as the programmer had demonstrated that they can deliver in one area of C++ and are capable of learning whatever SDKs or specifics that you use I would not be too torn up to hire a programmer who knew little of the local company's subset of C++ used.
I personally have delivered C++ applications for embedded systems, mobile, and desktop. Yet it would take me very little time to write a (apparently) simple test that I would fail. Then I could point to myself and say, "Ha ha you don't even know these basics, you fool!"
For instance what is the keyword "compl" used for? Answer: it is a replacement for the ~
Why would you want to use compl other than having a broken tilde key? Answer: Because some systems don't have a ~ but do need to compile C++.
So, I am a huge fan of talking over some code that was created by the person and then seeing a quick fizzbuzz test or two to make sure they aren't full of crap. After that it would be to talk about projects that are at least similar to the project in question.