The instinct for experienced people when getting a question like this is to just ignore it and give you some broad generic advice (e.g., "he language shouldn't matter!"), which is not what you want. I will try to actually answer your question.
Fact is these days simple programs are not written in C++. C++ is used in kernel code, storage array code, file and database system code, i.e., things with caches where strict control of resources matter for uncommonly important performance reasons (uncommon because performance is not usually a priority 0 problem for "Apps" but it is for systems). If your friend is going to write C++ code they are going to work on a complex system. So then the amount of C++ they will need to know will be probably most of it because for complex systems the code base is large and mature, worked on by many engineers, and usually strictly controlled (code reviews, regression testing, etc...).
What makes the job entry-level then? Answer: they will not be responsible for making large sweeping changes, but instead will be focusing on fixing specific bugs. It will take a while until they earn enough trust and domain-specific knowledge to fix bigger bugs (bugs involving multiple components) and even more until they can design/architect new features. What that means is your friend in an entry-level C++ job will actually be _reading_ more then they write, a lot more.
So your friend will be working on a mature, complex system, fixing bugs with limited scope, and reading lots and lots of code written by other engineers. In the context of reading code the minor features will matter less (e.g,. type parameterization via templates, or various constructor syntaxes, or throwing/catching exceptions). What will matter? What does he need to know to read C++ code and fix small bugs?
1) Being able to identify layers of abstraction and modularization so your friend can tell what a particular piece of code is trying to do and how it fits into the larger system. In this case the major C++ things to understand would be how classes and their data members are declared (often in separate .h and .cpp files), and how class hierarchies are declared (e.g., abstract classes, inheritance, overriding virtual functions, etc...).
2) Being able to understand common memory bugs. The fact is 30+% of bugs in C++ are because it doesn't have strict reference tracking and GC like, e.g., Java, has. Your friend needs to know pointers, pointer arithmetic, referencing, dereferencing, call-by-value, call-by-reference, references, arrays, malloc, free, constructors, and destructors cold. Also your friend needs to know how to use a debugger (e..g, gdb) and something like valgrind that can help find where memory bugs originate from.
3) Soft-skills. Your friend needs to be able to talk to other engineers to ask them how a problematic part of the system was supposed to work, what was the intent? They also need to propose their solutions, and explain what they think the bug is. Particularly for large and complex systems this is really important as you do _not_ want to introduce breaking changes and with more complex systems it is often difficult to regression test just the bit that your friend changes to fix the bug, so you need to import others' experience and get more eyes on your changes when necessary.
Bottom line your friend will be fixing small bugs (often memory related), reading a lot of code, and learning about the particular system they are working on as an entry-level C++ coder. Good luck!