I've been writing C++ for 4 years now professionally. I don't claim to be some kind of god at it but what am I supposed to do? Leave it off my resume because I don't know every intricate detail? I've used it to get shit done and make a company money, everything else is fluff.
> I've used it to get shit done and make a company money, everything else is fluff.
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.
Every place that uses C++ uses some narrow fraction of the capabilities. Teams try to find an intersection of features that hopefully a majority of the team can understand.
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 suppose it depends on the work the interviewer's company is doing, but when I last had a C++ job, knowing what a copy constructor was and the implications involved was important.
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.
