Which are...?
I'm guessing, depending on the niche you work in, your basics are very different from many other niche's C++ basics. If you're working in FPGA development you'll have very different basics then a fintech. Likewise, game development is very different from backend web dev. C++ at Facebook is probably very different from C++ at Microsoft. Microsoft Kernel development C++ is probably very different from Microsoft Windows 11 adware C++.
I'm glad that interviewers exist that think they can pwn the interviewee by quizzing them on the "extreme basics", because it's an immediate red flag to me that the interviewer is acting with extreme hubris to claim that such a thing exists at all. I go back to this all the time, but when the guy who has literally been writing entire books on the esoteric features of C++ for 20 years says he doesn't trust himself to evaluate potential errata[0], I highly doubt any single person is capable of understanding the voluminous pitfalls and complexities of this large, bolted, amalgamation of a language.
[0]: https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati...
I guess they're different for different interviewers.
The one I would use is something about undefined behavior. I mean, the fact that it exists and consequences. For example: "this program works, but if I add this line of code at the very end, the program crashes. Can be I sure that it crashed because of that line or some incorrect inputs to that line?"
In (almost) all other languages the answer is "Yes". Not in C++ or C. You may have a faulty program in the first place that just happen to not crash.
All other quirks and syntax can be picked up when needed. You can play around and investigate. But undefined behavior requires one to think and debug in a very different mindset. One cannot assume that a program that does not crash and gives a correct answer will do that if extended.
I've taught to freshmen students who have personally encountered dozens of different false positives and false negatives not only with sanitizers, but with compiler warnings as well. Nothing extraordinary, just `-Wall -Wextra -Werror` with the latest available GCC/Clang on the latest available Ubuntu LTS.
Some examples (some library bugs are also included):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105729
https://github.com/llvm/llvm-project/issues/59432
https://github.com/boostorg/dll/issues/30
https://github.com/boostorg/asio/commit/71964b22c7fade69cc4c...
https://github.com/chriskohlhoff/asio/issues/997
I've also seen fun examples of a program working with all sanitizers in 14 modes across 3 OSes (GCC and Clang on Ubuntu, Apple Clang on macOS, Visual Studio on Windows), and _only_ failing with Visual Studio Release mode. It was an array overflow. Just was not caught by sanitizers.
Mind you: no weird C++ magic, just standard coding exercises.
What does change is the STL. Asking someone what a constructor is, or templates, or auto, or ConstExpr, ConstInit, ConstEval and the differences. It's the exact same code on any format or machine. Asking someone what a "Unique_ptr" or "Ranges" or whatever is a bit in the bullshit realm of an interview and should be shamed. But C++ is vastly seperated from the STL. And odds are in an interview, you can ask someone about their specific domain of c++ they use in most cases, since usually a win32 shop is going to interview win32 people.
What is a smart pointer? Or if I'm sadistic, whats the difference between unique_ptr and shared_ptr? To me, smart pointers are one of the tells that you are actually writing C++, and not just C with classes.
That said, testing syntax is generally awful and I only use to gauge someone's familiarity with the language (same with Go, I'll say what is a goroutine, but Go is easy enough to learn that it wouldn't factor into my decision unless the candidate was brazenly lying about past experience).
> To me, smart pointers are one of the tells that you are actually writing C++, and not just C with classes.
To me, shared_ptr is one of the tells that you should be writing Go or something like that, and not just C++ with reference counting.
It's moreso I've had so many interviews crash on this question that I've started to feel bad for asking it (and starting to assume that, no they don't know C++).
Most of these jobs we didn't even use C++, it was just identifying C++ engineers was usually a very strong signal, especially because we were early adopters into Rust.
What isn't esoteric? Shared pointers, move semantics, atomics, inline assembler, CRTP...
If you quiz someone on your particular known C++ language details you can far too easily think everyone is pretending.
It's surprisingly easy to fool people with just words. I think this is why we have so many incompetent people working in tech. Most people don't know how to qualify people.
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++.