How Much C++ Should You Know For an Entry-Level C++ Job?

Nerval's Lobster writes: How much C++ do you need to know to land an entry-level job that's heavy in C++? That's a question Dice posed to several developers. While the exact topic was C++, the broader question of "How much X do you actually need to know to make money off it?" could also apply to any number of programming languages. In the case of C++, basics to know include virtual methods, virtual destructors, operator overloading, how templates work, correct syntax, the standard library, and more. Anything less, and a senior developer will likely get furious; they have a job to do, and that job isn't teaching the ins and outs of programming. With all that in mind, what's a minimum level of knowledge for a programming language for entry-level developers?

Comments

As much as possible... or none at all

[Thornburg]

Any really good company/department is going to find it more important to find the right person than skills in a particular language.

Obviously, a person who is a good fit in other ways and has experience in the exact skill/language is the best, but you're better off hiring someone good who doesn't know the language (and then helping them learn it) than you are hiring someone who's not a good fit but does know the language.

When I'm involved, I want to see at least 2 different similar skills (in this case, programming languages), to prove that the person can learn and has a core understanding of the common principals.

So, learn a few languages (preferably at least one of which is popular), and be prepared to learn a new one for a job.

Do you really want to work at a place that isn't willing to take the time and money to train the right person? Odds are you'll be looking for a new job before long (either by your choice or theirs).

First, define what you mean by "C++"

[Miamicanes]

Define what you mean by "C++".

C++ firmware for an Atmel AVR microcontroller?

C++ native Android loadable kernel module?

C++ MFC Windows app?

C++ hardware driver for Windows?

C++ Linux app built for GTK+?

The borderline-useless artificial construct college textbooks pretend is C++ for the sake of having something consistent and coherent to teach students for a few years at a time?

My point is that knowing "C++" (as an abstract, academic construct) barely equips you to do anything commercially useful with it. Probably 60% of what you need to know to do anything useful in C++ is platform-dependent, and another 20-30% is IDE-dependent (at least, in the Windows & Android realms, where trying to do anything independently of Visual Studio or Android Studio is an exercise in masochistic frustration (because both platforms are so tightly-coupled to their respective IDEs).

Re:None. Go meta.

[war4peace]

Pseudocode.
http://en.wikipedia.org/wiki/P...

Also Drakon charts.
http://en.wikipedia.org/wiki/D...

I actually was taught DRAKON charts (a variation of it) in high school back in '96. It tremendously helped me in more ways than strictly programming (which I never embraced). My teacher used to call it pseudocode back then, although Pseudocode is different.
At the time, generating a high level overview of the processes in DRAKON before building any code was mandatory, and it sped up code generation because you always knew what the next steps would be.

Re:Answer

[lgw]

. Java is superior to C++ in almost every reasonable use of C++ *except* the ones which call for programming in C

That's just, like, your opinion man!

Seriously, though, C++ was never intended to be "C with a little extra", but instead a Java-like (but native code) language with backwards compatibility with existing C code. You can see that throughout Stroustrup's writings, including how he says C++ should be taught (start with std::vector and std::string - don't even teach arrays and char* until people have the basics internalized).

IMO, C++ properly written is a better Java - no worries about resource cleanup (Well, now Java has try-with-resources, so it's not so bad), vastly less boilerplate, a great standard algorithms library, and so on. Java's advantage is in its easy learning curve, and standard cross-platform libraries, which led to a vast selection of open-source tools. If the C++ standard had included more cross-platform system libraries earlier, Java might not have the library advantage. While C++ finally has threading in the STL, it's missing so much other systems-level stuff. But at least I can have a freaking unsigned int in C++ if I want to!

Re:Answer

[slimjim8094]

(I work at Google and use C++ there, but what follows is my opinion)

What precisely don't you like about the C++ style guide? (This is almost identical to the internal guide)

- It is true that exceptions are verboten, but honestly it's not particularly limiting. Java gets exceptions right - something is truly "impossible" (in a crash-the-program you-have-a-logic-error sense) and thus you don't need to handle it, or else it's "expected" like an I/O issue and the language forces you to do something with it - either try/catch, or declaring that you're potentially passing it along. C++ doesn't have any such enforcement, which makes it very hard to reason about what a function may throw at you. You rely on everybody in the entire call hierarchy doing the right thing. Reminiscing about my Java days, the lack of exceptions does make some things somewhat more cumbersome to deal with - having to explicitly return a status object, for instance, to deal with plausible-but-atypical cases. But the Google guide is fairly apologetic in this area and basically says "sure, we'd use it if we had a brand-new codebase, but we don't..." and the reasons that follow for why exceptions are hard to integrate into a truly enormous codebase seem sound to me. What do you disagree with about this reasoning?

- There is certainly no rule about "allocate at the top, clean up at the bottom, never return from the middle". In fact, with unique_ptr and the like, there's even less reason to do those kind of things than there's ever been. The local variable part of the style guide actually explicitly encourages as-close-as-possible declaration, and the rest of the style guide is quite gung-ho about unique_ptr (we actually had an internal class for a long time that was sufficiently identical to unique_ptr that they were able to replace all uses and remove the custom type in just a few months). I can find no reference to any sort of prescription about the location of return statements.

- The standard libraries have actually been moving away from exceptions, haven't they? C++11 introduced 'noexcept' and added it to a bunch of methods, and the specs for a lot of other ones guarantee that the only exceptions are from the allocator (e.g. std::bad_alloc). To be clear there is no prohibition against *using* code (especially the standard library) that may throw exceptions.

In a nutshell the style guide is, in order, "be readable" followed by "be consistent". It is hilariously easy to write unreadable, bug-prone C++ code. Nobody cares if your code is perfect and correct, they care if the next guy along can modify or use it correctly and it is useful to have a style guide to make some of the more hard to reason about things impossible. How many different bits of code could the statement 'a = b;' potentially execute? (It's a lot - copy constructor, operator=, operator Foo(), etc.) The style guide limits it to just a few things you might have to consider, so that when you use some code someone wrote 6 years ago there's not so much to look at. C++ has references and pointers, which is great, but at least with pointers there's a hint that you might have "spooky action at a distance" so the guide mandates their use for out-params which seems perfectly reasonable since it's basically arbitrary which to use - and in practice, it's a really handy hint to have when you're reading. Unless you're passing an address, you know your copy can't be modified. IMO, way more readable.

If you've really been hanging up on recruiters because you object to the style guide, it is probably worthwhile to actually ensure that your understanding of it is correct and up to date. It has changed in recent years as C++11 has become better understood and it is fair to say that it is far more liberal to things like lambdas, template metaprogramming, operator overloading, copyable classes, etc - than it was a few years ago.