Preparing for C++ interviews

[SamiraMHosseini]

[SamiraMHosseini]

I haven't been able to find good and reliable resources for C++ interview questions and I am lost and don't know what to study and what topics matter most!

[lefticus]

Twitter thread: https://twitter.com/lefticus/status/1554844035751165952

Ideas:

• Be aware of the Dunning-Kruger effect. If you think you're a 4/10, you're probably a 2/10. If you think you're an 8/10, you're probably a 9/10 https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect (but DO NOT give yourself an actual ranking in your CV!)
• Familiarize yourself with Best Practices. Look for random code on the internet and review it
• Be aware that templates exist, and know how they can help your code
• Be aware of the arguments for and against auto
• Practice talking about the projects, concepts, tools, and ideas in your CV. If you cannot have a conversation about something on your CV, you should probably remove it.
• Know that C and C++ are different languages! If you list C/C++ on your CV, many companies will consider this to be a red flag that you don't actually understand either language.
• Review the basics! How many different ways can you write "Hello World" in C++? Practice live coding them (compiler-explorer is a good tool for this). The point is to be familiar and practiced with common things like IO and the signature for main.

[lefticus]

• Be very careful with terms like "expert" and "guru." If you say "expert in C++" it is guaranteed the person interviewing you will know something about the language you do not know. Instead consider just talking about your accomplishments, or being very specific "expert in porting C++ code from Windows to Linux"

[lefticus]

See this terrible example: https://twitter.com/IgnitionWeb/status/1554865524500320260

[marzer]

If you think you're a 4/10, you're probably a 2/10. If you think you're an 8/10, you're probably a 9/10

~Isn't this partly backwards?~

Wait, never mind. Just double-checked the wiki article and this makes sense.

[CorrodedCoder]

"Demonstrate curiosity" as this seems to be one constant I've gleaned primarily by being the interviewer, but also being the interviewee. If you don't know the answer to something then don't be afraid to acknowledge that up front (it's usually not hard to tell), but equally if you think you might know something related then ask them if they'd like you to speculate. Later on in an interview, I typically ask a question that has no right/perfect answer that requires the candidate to speculate on something that could have any number of possible outcomes depending on what the compiler does, time, threading, and it's ideally a very interactive discussion. The purpose is to see how well the candidate collaborates on something they aren't trivially able to answer. The best outcome is that they get really interested in the problem & discussion and forget they're in an interview at all and this gives me a feel for what it will be likely working with them. The worst outcome is a refusal to engage at all. I'm not saying this is perfect and it certainly has to be done sensitively (and once they are relaxed) but I have found it to be useful to me.

[lefticus]

• What is the difference between a shared_ptr and a unique_ptr and when should you use them?

[Paiusco]

A few that I remember hearing/using:

• what's the difference between a std::vector and a std::list?
• which mechanisms can one use for multithreading synchronization? How can you make a thread wait for something without the need for polling?
• what's the difference between stack and heap? static and dynamic memory allocation?
• What can cause a memory leak? What can one use to prevent it from happening?
• What's a pure virtual method? Why one would use a virtual destructor?
• Can you explain the difference between the Move and Copy constructor?

Then we could show some code for review or do a quick "pair programming session" with a quick assignment.

[CorrodedCoder]

Assuming a candidate for something beyond a graduate role, a very key indicator for me is some understanding of resource management followed by being able to write exception neutral code. In my example I tend to combine them both to something like:

int * data=new int[100];
do_something(data, 100);
delete data;

The sorts of things I am aiming to tease out are:

1. What happens if an exception is thrown in do_something? I'm looking for the most basic risk of a memory leak.
2. How would you improve the situation? Use std::vector is an answer which tells me a lot about the sort of code they are used to. Use int data[100]; is great too, but I then change the question so the size is variable. Answers involving catch and release aren't without value, but they are a bit earlier on their C++ journey.
3. Check for data being NULL is an interesting discussion and awareness around the possibility of "new" throwing is another good sign, but I am not too fussed about someone knowing the correct behaviour (mostly because "it depends", or at least it used to).
4. Recognition of the missing [] on the"delete" line and the potential consequences depending on POD vs object can be another interesting indicator of depth of understanding, although a newer C++ programmer may have been in the lucky position never to have issued an explicit "delete", which would only arouse envy in me.

The actual choice for the"do_nothing" may vary between some inline code that actually demonstrates a throw. As interviews are quite artificial situations it can be more helpful to show something concrete, but at the risk of making the question more involved.

[lefticus]

• talk about const and its various uses in C++ (member function, member variable, automatic variable, static variable)
• What are the 4 storage classes

[lefticus]

Closing as merged with #194 that episode is not C++ specific, but I think it all comes around.