The reality is, in my area, Java enterprise development pays a lot more. I'm sure this is the case in plenty of other areas as well. Surprising but true.
In an interview setting, keep answers contextual and tight. In my previous professional setting, we would solve the problem like this : <however>. Try to solve problems using only the subset you know.
if you're pushed into a corner and they really want to overload [] or whatever, be clear that because, c++ is a large and sprawling language, for production code you'll need to check the spec, or consult with a teammate. With that understanding in place, you can take a stab at it.
If you get dinged for that, you probably don't want to work there anyway.
I find it so frustrating how hard this is to sell in an interview. I understand how important it is to avoid bad hires, but I'm a self-taught web developer so I just flat out don't know a lot of CS "basics". I've been a professional SWE for 5 years, have made all of my teams very happy, have accomplished some very good work, and have dug into the docs enough to get the most out of the many tools/libraries I've had to use.
But, sometimes there's a coding challenge on a topic I've just never seen before, and I'm dropped. As unrealistic as it is, I wish interviews had options for demonstrating my ability to learn a new tool quickly and make use of it. I'd spend a work day taking on a mock ticket for some new security procedure I've never touched before if it showed them that I can actually get the job done.
I agree that asking details related to syntax are not good questions. But copying objects is a very natural thing to do in most languages, and if you don't have some idea of the implications, that's a red flag.
Also: Some understanding on default copy constructors. I think it's OK not to know whether a default one is created for you or not, but just knowing that it might be is worthwhile to probe in an interview.
Of course, these concepts are due to a poor language design, but what can you do? If your team uses C++, you need to deal with the poor design, and need people who understand the poor design.
certainly, a bad interviewer can ask bad questions (for any language), but the copy constuctor (and call by value or call by reference) is one of the basic features of c++.