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

Answer

[s.petry]

NONE! Find a real language! *ducks*

Re:Answer

[lgw]

NONE! Find a real language! *ducks*

For non-ducks, the most important things to know about C++ aren't list in the summery: RAII and shared_ptr<T>

C++ is not C. C++ written like C tends to be crap code - just an overly complex and distracting language for that coding style. If C++ is the right tool for the job, you need to be using a coding style very similar to C# and Java: throwing exception when errors are encountered, writing exception-safe code all the time, returning from functions in the middle, and never, ever, worrying about cleaning up at the bottom of a function what you allocate at the top.

If all of that sounds wrong to you, congrats, you're a C coder, and there's nothing wrong with that. Good C code is good code. But C++ is designed to be used with "scoped objects", that is, every object cleans itself up when you exit scope, so you really have to internalize the tools for that, and that mindset.

Re:Answer

[Spazmania]

C++ is not C. C++ written like C tends to be crap code - just an overly complex and distracting language for that coding style. If C++ is the right tool for the job, you need to be using a coding style very similar to C# and Java

That's a bit of a problem, because when you program in C++ the same way you'd program in Java, you lose the efficiency and simplicity of C without gaining the clean design of Java. Java is superior to C++ in almost every reasonable use of C++ *except* the ones which call for programming in C but with, you know, a little bit plus.

If all of that sounds wrong to you, congrats, you're a C coder

I resemble that remark.

Re:Answer

[rjh]

unique_ptr is normally preferred over shared_ptr -- the former is zero-overhead compared to a pointer, while the latter has a reference count associated with it which has to be incremented and decremented. If you know two or more things will be using the pointer and you don't want to have to worry about ownership semantics, shared_ptr makes a lot of sense. If you know only one will be using it, unique_ptr makes more sense.

Re:Answer

[TheRealMindChild]

I don't know how to respond because this whole post is bullshit.

If you are using C++ as such a high level language as Java/C#, you may as well use them because you threw away some of the most useful/valuable parts. Also, Exceptions are EXCEPTIONAL and should be treated as such... only expected to be thrown when something exceptional happens, not as a means of flow control.

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

[Ichijo]

And don't even think about touching production code until you understand const-correctness.

Re:Answer

[Gibgezr]

In the field I work in, we aren't allowed to use RAII; we compile with it turned off. Same for exceptions (this is not exactly unique; Google coding practices require this as well, as do many other companies). Performance-critical real-time code shuns that stuff. We haven't used C for 20 years, because C++ offers the stuff mentioned in summary, and what we need is all that power PLUS the ability to manipulate memory directly, and all as fast as possible. There are huge swaths of industry that need more than "C with classes", but less than Java/C#.

Of course, what it boils down to is the old joke about C++: get 5 experts on the language in one room, and you discover that each of them only is comfortable with 40% of the language...and it is a DIFFERENT 40% for each of them!

Re:Answer

[lgw]

Oh fuck yes. But that's easy to explain to a new-hire - it's just a tedious convention, not really a mindset thing. IMO, the single most annoying flaw in C++ was not making all members and parameters "const&" by default. (Passing an int by value instead of by const reference is just the optimizers business, not a semantic change). I'd much rather declare the non-const exceptions!

And while I'm wishing, C++ really needs C#-style properties - a way to optionally intercept "foo.bar = 4" to add a non-trivial setter, without cluttering code with getBar() and setBar() functions "just in case".

Re:Answer

[Anonymous Coward]

You cannot turn off RAII (Resource Acquisition Is Initialization) in C++, since it is an idiom and not exactly a language feature. What you are talking about is problably RTTI (Run-Time Type Information). Both of these features have zero performance overhead if not used, so there is really no point in turning them off. Just don't use them in performance critical places.

Re:Answer

[lgw]

(You can't "compile with RAII turned off", as RAII is a coding style: you're probably thinking of RTTI. But the RAII style might not be good for a realtime system, as it can hide expensive work to release resources.)

The abomination that is Google's C++ coding conventions is why I hang up on their recruiters. (Though I hear an internal war has been raging for a couple years within Google over their 80s-night coding conventions). Actually, I'm not sure what's you'd use from C++ beyond "C with classes" if you're writing C-style code. If you're not comfortable with exceptions, and are following an "allocate at the top, clean up at the bottom, never return from the middle" mindset, C++ is damned awkward - you won't be using the standard libraries much, you won't have non-trivial constructors, and so on.

Re:Answer

[Grishnakh]

C++ is not C. C++ written like C tends to be crap code

You might want to avoid flying on commercial airliners then, because they have lots of avionics systems running C++ code exactly like that, with exceptions explicitly banned. Countless other embedded systems are the same way.

never, ever, worrying about cleaning up at the bottom of a function what you allocate at the top.

In these embedded systems, the "delete" keyword is also banned. You're never allowed to free memory once it's allocated.

Re:Answer

[angel'o'sphere]

Nothing beats C++ in multiple inheritance (which Java does not have and Groovy/Scala only mimic half arsed) and in templates, which Java/Groovy does not have either. Not sure about Scala, originally they wanted real templates, but no idea if they scaled down to generics, too.

Re:Answer

[angel'o'sphere]

Properties are easy achieved in C++ by using so called "property templates" where you wrap attributes into such a template and overwrite operator = for assignment and the cast operator for reading ...

Perhaps you should catch up and buy one of the 20 year old C++ books :D

Re:Answer

[ron_ivi]

unique_ptr ... shared_ptr

LOL at how C++ gets new smart pointers every couple years.

It's like they're trolling their own users with their:

• classes are kinda like structs, so you can use 'typedef struct ... *' for classes and 'void *' for generic functions (Everything from CFront in 83 through ARM in 99)
• no! 'void *' pointers are broken! use 'auto_ptr' instead (C++03)
• no! 'auto_ptr' is broken! use 'shared_ptr' instead (C++07/TR1)
• no! 'shared_ptr' is broken!(for most use cases) use
• 'boost::scoped_ptr' instead (non-standard, but more useful than the standard's shared_ptr)
• no! 'boost::scoped_ptr' is broken! use 'std::unique_ptr const' instead (C++11)
• no! 'std::unique_ptr const' is fugly! use "auto" and hope C++14's "return type deduction" will guess a safe type and hope C++17's "new rules for auto deduction" won't break stuff (C++14)

crap.

How the heck can people take an "object oriented" language seriously when it takes literally 30 years (1983 to 2014) for them to come up with a non broken way of making a reference to an object....

... and in the end they give it a syntax like "std::unique_ptr const".

W.T.F.

Re:Answer

[rjh]

I don't know who told you C++ was an object-oriented language. It's not -- ask Bjarne. It supports many different styles of programming, object-oriented being just one of many, but it is in no way object-oriented. You can write large code bases without using a single object.

Re:Answer

[Tanuki64]

It really is unbelievable how many wannabes bad-mouth C++ here and at the same time show that they don't have the slightest idea what they are talking about. 'Disable RAII' suuuure... I compile my programs always with the -no-crash option so my programs never crash... Never heard of it? Not surprising... it is in pre-standard C++21 and only supported in GCC 7.2 ;-)

Re:Answer

[lgw]

Yeah, I've done that trick before: it's not quite the same. It's been a while since I tried, but I remember it not working for some operators and implicit conversion the way it would with a simple public data member - complexities of type inference.

There was actually a provision for this originally, sort of: by overloading the -> operator you can change what foo->bar returns, but you can't change what foo.bar returns, and since I almost never pass pointers around I rarely use the -> operator

Re:Answer

[brausch]

Huh!? According to Stroustrup in "Design and Evolution of C++", C was certainly intended to be "C with a little extra". It was also designed to be C with a lot extra. He intentionally created the language so that C style code would still run just as fast as before. You could just take advantage of the nice things like function prototypes (remember when C++ first came into being was before ANSI C) and declaring for loop variables inside the loop, etc. You could begin to use the new features as you wanted.

Or, you could go full bore with objects, etc.

Thirty years of development later, we have today's C++.

Re:Answer

[Grishnakh]

*shudder* Are avionics really written in C++?

Yes, but only a subset of it. Things like exceptions aren't allowed.

Is memory deterministically pre-allocated in such systems? That would certainly make it safer, but less flexible.

Yes, that's the whole idea. They aren't meant to be flexible, they're meant to do exactly what they're designed to do and no more, in a completely deterministic fashion. These systems aren't all things with UIs, they include all kinds of systems on an aircraft, which frequently don't have any UI at all except maybe some switches. On a car, an ABS computer would be a good example of one of these systems. There's no display or UI or anything of the sort; you just plug it into the car, and it sits there monitoring wheelspeed and brake pressure and when it sees a wheel locking up it releases brake fluid pressure to that wheel (it's a bit more complex than that, esp. on cars with dynamic stability control and traction control where these are all tied into the ABS, but this is the general idea). A system like that doesn't need to free memory, it just needs to allocate what it needs when it powers up, and then run its program continuously, monitoring inputs and controlling outputs (implementing transfer functions etc). All the tasks it'll ever have to do are well-defined, and all start up when the system powers up, and all get a timeslice.

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.

Re:Answer

[Jeremi]

I have yet to encounter a non-contrived example where multiple interitance is a plausible solution to a problem.

Okay, I'll give it a shot, then... here's where I find multiple inheritance not just plausible, but preferable.

I have a publish/subscribe model including an abstract-base-class/interface (call it IDataSubscriber) that can be subclassed by any object that wishes to be notified about e.g. data updates coming in from the network.

There are a number of common-case standard responses (implemented as concrete IDataSubscriber methods) to those data updates that are useful for many situations, and I don't want to have to have to rewrite them separately for every subclass, so I make a concrete or almost-concrete subclass (e.g. StandardDataSubscriber) that contains this common logic.

Finally, in my client code (based on Qt) I have a number of GUI widgets based on QWidget or QPushButton or whatever. I want these widgets to react to published data in the standard way, so I often end up with this:

class MyButton : public QPushButton, public StandardDataSubscriber {...}

... and it handles my needs nicely. It's also possible to do the same thing with "just" single inheritance and interfaces as well, or with Qt's signals-and-slots, but AFAICT do to it that way you end up having to do lots of manual method-call-forwarding through proxy objects (or, alternatively, lots of manual signal/slot connecting), which is less efficient, harder to read/understand, and more error-prone.

Re:Answer

[david_thornley]

Check out Interactive Fiction (what used to be called text adventures). The good IF languages I know all have multiple inheritance. The ability of a safe to inherit Lockable and Container saves a lot of work.

None. Go meta.

[Anonymous Coward]

Knowing C++ shouldn't matter. Demonstrating that you can quickly master and use any language should.

Re:None. Go meta.

[Anonymous Coward]

This is surprisingly accurate. No amount of programming language knowledge will help you write a good program if you can't design the software from a practical level, upwards. What do you want the computer to do? What exact steps do you want it to take? Good, now translate that into $programming_language. That last part is actually the easiest part of software engineering.

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:None. Go meta.

[shadowrat]

i've been working with c++ for the past 4 years. prior to that i had 15 years experience using all kinds of other languages. In my interview, I said, "hey, I don't know the c++ for solving this problem, but it would be easy in c#." they said have at it. i was hired.

Re:None. Go meta.

[Anonymous Coward]

OP is saying "If you know Spanish that should be good enough for France since you can just pick up French along the way. They're all Romance languages so it'll work out soon enough".

Soon enough... Except when the company wants you to know C++ tomorrow rather than 2 months later when you've mastered the API.

He has a point but it's not something I would bank my resume on...

Re:None. Go meta.

[IamTheRealMike]

That sort of logic holds true when moving between languages that are very similar. The transition between Python and Ruby or Java and C# spring to mind.

However if I need a C++ programmer and need one pronto, I'm not gonna hire a guy who has only JavaScript on his CV no matter what. Learning C++ is not merely learning a different way to create an array or slightly different syntax. To be effective in C++ you need to know how to do manual memory management and do it reliably, which takes not only domain knowledge but more importantly: practice and experience. You need to understand what inlining is. You very likely need to understand multi-threading and do it reliably, which takes practice and experience a pure JS guy is unlikely to have. You need to be comfortable with native toolchains and build systems: when the rtld craps its pants and prints a screenful of mangled symbols you need to be able to understand that you have an ABI mismatch, what that means and how to deal with it. Unfortunately that is mostly a matter of practice and experience. You might need to understand direct manipulation of binary data. There's just a ton of stuff beyond the minor details of the language.

Could the pure JS guy learn all this stuff? Of course! Will they do it quickly? No.

How to read f*ucked up code

[mveloso]

The biggest skill in C++ is how to read code that's got templates, generics, overloaded operators, and custom keywords.

"What do you mean they overloaded '+' to merge objects?"

"This doesn't look like C++, it looks like some foreign language."

"Oh, we reversed the meaning of + and - because the senior guy thought that the original semantics were incorrect. But only for some objects."

Re:How to read f*ucked up code

[Em Adespoton]

THIS. The things to look for in entry-level C++ are:
1a) a grasp of ANSI C
1b) a grasp of OOP
2) a demonstrated ability to figure out how to understand all the legacy C++ code
3) a demonstrated ability to write new C++ code in the style of the legacy code such that the next person who comes along has a clue as to what they were meaning to do
4) appropriate documentation (via comments AND proper code structuring)

But what counts even more is that the person is a good working fit with the senior programmer in general, and appears to be someone who can learn as they go (because no matter how good their C++ skills are, they're going to be DOING IT WRONG according to the senior programmer).

Re:How to read f*ucked up code

[goose-incarnated]

The biggest skill in C++ is how to read code that's got templates, generics, overloaded operators, and custom keywords.

"What do you mean they overloaded '+' to merge objects?"

"This doesn't look like C++, it looks like some foreign language."

"Oh, we reversed the meaning of + and - because the senior guy thought that the original semantics were incorrect. But only for some objects."

This. Outside of academia I've never encountered C++ written in a sane manner. Hell, even inside of academia things get a bit iffy. Things you can expect to see if you ever maintain C++ code:

* Objects passed by value which don't have a deep assignment copy constructor.

* File scope objects using other file-scope objects - "Because VS2010 ensures instantiation order."

* Dependencies with no real reason; this is especially bad on Qt projects. Why use std::vector when you can use a QVector?

* const char *use_this_later = MyQstringObject.toStdString().c_str(); // Bang! There goes another foot... maybe if we had GC...

* You used copy semantics? You *meant* move semantics (This should never had made it into the standard).

* Overloaded functions - "myfunc (foo);" does something different to "myfunc (bar);", because hilariously foo and bar are different types

* Ditto for operators - "foo + bar" does something quite different to "bar + foo".

* Other than "type var[size];" there is no primitive array type. Arrays are implemented in the library, not in the language like every other sane language.

* No GC. In other languages you can get away with it, but in C++ you stand no chance - someone, somewhere back in the mists of the past, would have created a critically dependent-upon class that *will* return a temporary object that gets deleted automatically while you still have references. QString, for example.

All of the above, in addition to all of the gotcha's in C as well. In this day and age there is very little reason to use C++. If you need objects, UI, etc use Java or C#. If you don't need objects use C; at least you can trivially expose every single piece of C code you've written to other languages via a library. This lets you reuse your code. The only C++ code you'll ever expose to other languages are C-compatible functions.

I'm looking, right now, at a mountain of code, some 20+ classes, many with file-scope instantiations, every single fucking object a Qt object. The original developer noticed that the code for Qt-derived classes won't compile without a copy constructor so he very cleverly made empty copy constructors for all the classes so that even a shallow copy won't be performed. As expected, he also stores instances in containers - which means every now and then the program would give incorrect results with seemingly no predictable occurrences. It doesn't crash, mind, just gives incorrect answers.

Good luck; you'll need it.

Stay away from C++ - stick to languages that implement context-free grammars only.

Re:How to read f*ucked up code

[Anonymous Coward]

* Objects passed by value which don't have a deep assignment copy constructor.
* File scope objects using other file-scope objects - "Because VS2010 ensures instantiation order."
* Dependencies with no real reason; this is especially bad on Qt projects. Why use std::vector when you can use a QVector?
* const char *use_this_later = MyQstringObject.toStdString().c_str(); // Bang! There goes another foot... maybe if we had GC...

If someone is doing any of these, then they should be fixed at the code review stage. There's no reason to let any of these live. If someone insists on continuing, then let them find a new place of employment.

* You used copy semantics? You *meant* move semantics (This should never had made it into the standard).
* Overloaded functions - "myfunc (foo);" does something different to "myfunc (bar);", because hilariously foo and bar are different types
* Ditto for operators - "foo + bar" does something quite different to "bar + foo".

If there are differences in these behaviours, then, again, you're doing it wrong. "Foo + Bar" should always behave analagously to "bar + foo". There's barely a language around that gets away without overloaded functions, so failure to grasp that is a failing indeed. Move and copy semantics really only need to be understood by library writers. For everyone else, they basically just need to understand that it's ok to to return vectors by value.

* Other than "type var[size];" there is no primitive array type. Arrays are implemented in the library, not in the language like every other sane language.

So, other than an array type, there's no array type? What does that even mean? The whole strength of C++ is that things can be built into libraries rather than baked into the language. My container with feature Y is just as integrated into the language as the STL's vector, or a "type var[size].

Which C++?

[Anonymous Coward]

Is it abort maintaining some old code which tends to be more like C with use of class instead of strict,
Or is it C++14 which is a much more modern language?

Re:Which C++?

[GerardAtJob]

That's the real question! Too bad I'm all out of points!

I'd go with...

[jones_supa]

Classes, class inheritance, smart pointer, vector, operator overloading.

That should suffice as the starter pack. You can learn the rest in your job when the need comes.

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).

"How do you monetize Slashdot?"

[93 Escort Wagon]

That's a question Dice posed to several middle managers recently. "We paid a lot of money for this tech property, but we have absolutely no idea how to use it", said one Dice higher up who requested anonymity. "Seriously - help us out here! There are over three million Slashdot subscribers, but none of them will click on an ad!", he lamented. "And they won't come over to dice.com and discuss these stories we keep cross-posting! We don't want to just be a second-rate job board forever..."

oooh really?

[Anonymous Coward]

and that job isn't teaching the ins and outs of programming

That is called mentoring. It usually one of the jobs of a 'sr developer'. Learn on your own time is a crap way of putting the cost of learning your system onto the developer.

Every language has its gotchas

[Rei]

And it's important for new programmers to learn them - more important than learning syntax.

  For C++ for example I'd warn about classes containing pointer member variables with implicitly-defined assignment operators / copy constructors. You have Foo a and Foo b, where Foobar has a member variable "int* bar". So the newbie does "a.bar = new int[100];" then later "b = a;" then later b goes out of scope, then they try to use a.bar and the program crashes. Seems to be a very common C++ newbie mistake. Eventually they learn to see pointers in class definitions as having big "DANGER" signs over them calling their attention, and/or rely on smart pointers.

Any others that people can think of that are common?

Oh, here's one more: iterator invalidation. A newbie who's not warned about this in advance will likely get bitten by it several times before the point gets driven into their head: "if you're using a class to manage memory for you, it's going to manage memory for you, including moving things around as needed."

Re:*shrug*

[Anonymous Coward]

C++ programmers do get paid more, but there's much, much more .NET and Java work around.

"a senior developer will likely get furious"

[gatfirls]

....and water will likely get wet.

For C++, there is no standard answer

[swillden]

For C++ there is no standard answer, because every C++ shop uses a different subset of the language. There are probably a few things that all of them have in common, but it's unreasonable to expect that any entry level C++ programmer can be productive without support from senior programmers while they learn the local ropes. Even experienced C++ programmers will need a little time to get up to speed on the local style guidelines.

C++ doesn't have an extensive set of standard libraries, either, which means that every shop has its own set. So senior programmers have to expect that new people are going to spend a lot of time getting up to speed on those.

Finally, I think the question is fundamentally bad, because it implies a misguided expectation of immediate productivity. That's a common expectation (hope?) throughout much of the industry, but unless you're hiring contractors for six-month jobs, its stupid. What matters in the longer run isn't what your new hires know coming in the door, it's how well they learn, and think. Because whatever they know coming in is invariably inadequate in both short and long term. One of the things I found very refreshing when I joined Google is that they don't much care what you know in terms of languages, libraries and tool sets. It's assumed that capable people will learn what they need to when they need to learn it, and that any new project involves some ramp-up time before people are productive. On the other hand, given a little time to get up to speed capable people will become very productive. Much more so than the less capable person who happened to know the right set of things when hired.

Code reviews

[JustNiz]

Your best bet is to find out if the place you intend to work for does regular peer reviews of code as a part of their process, and if not either stay clear or get an agreement that they will code review your stuff at least for a few months until you know the ropes.
Code reviews of your efforts, if done properly, are the best way I know of becoming effective quickly.

As a hiring manager

[Anonymous Coward]

As a C++ hiring manager I like you to have a relevant degree; know C++-98 pitfalls to the level of Meyers, "Exceptional C++", "More Exceptional C++"; be aware of or know the Gang of Four Patterns. Familiarity with Sutter and Alexandrescu's writings are nice. Knowledge of Lakos and physical design (rate) is a big bonus. In a big project, even with good programmers, they usually make a mess out of the physical design. Some understanding of unit test and coverage is good too.

Re:As a hiring manager

[janoc]

And I do hope that you offer a senior developer wages as well for these sort of requirements. The OP was talking entry level job.

People requiring these sort of skills for an entry level job are the true reason for the perceived "lack of IT talent" - unreasonable expectations and entry level pay.

Easy answer

[whoami-ky]

More than the other applicants.

Re:Not much

[BlackPignouf]

I wouldn't like to clean up after you.
There's a difference between "learning a language" and "knowing how to write clean and maintanable code while avoiding subtle caveats".

C++ is so broad as to render this question useless

[EmperorOfCanada]

This would be like how much English do you need to get a job at an English speaking company?

If the domain of the programming is really specific such as financial machine learning, or embedded systems then a tiny handful of fizzbuzz tests would be enough as the core questions would all be about the domain knowledge. But if the job involves pushing C++ right out to its limits where the company has occasionally made contributions to LLVM or GCC then maybe the minimum knowledge would be that of a C++ god.

But the simple reality is that the surface area of C++ and its applications is so large that as long as the programmer had demonstrated that they can deliver in one area of C++ and are capable of learning whatever SDKs or specifics that you use I would not be too torn up to hire a programmer who knew little of the local company's subset of C++ used.

I personally have delivered C++ applications for embedded systems, mobile, and desktop. Yet it would take me very little time to write a (apparently) simple test that I would fail. Then I could point to myself and say, "Ha ha you don't even know these basics, you fool!"

For instance what is the keyword "compl" used for? Answer: it is a replacement for the ~
Why would you want to use compl other than having a broken tilde key? Answer: Because some systems don't have a ~ but do need to compile C++.

Plus if you were to quiz me on after I had been maintaining some other systems in Objective-C/Javascript/Python/PHP/SQL you could probably catch me up on all kinds of little stupid things where I would muddle the languages together. So just asking me the string function for reversing a string, upper/lower case, or other trivial things. I could end up looking like a real boob even though I could point to the hundreds or many thousands of times that I had used that construct/function/keyword in C++.

So, I am a huge fan of talking over some code that was created by the person and then seeing a quick fizzbuzz test or two to make sure they aren't full of crap. After that it would be to talk about projects that are at least similar to the project in question.

That all said; I wouldn't even be terribly offended if someone didn't even have much C++ experience as long as they could show that not only did they have mastery of one of the languages similar to C++ such as Java, javascript, or even even PHP; but that they had a proven ability to have quickly mastered a new language in the past. On this last note I would find it odd that an aspiring hard core programmer hadn't solidly encountered C or C++ in the past.

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).

The Correct Answer

[Anonymous Coward]

If Bjarne Stroustrup doesn't come to you for advice, you aren't qualified for an entry level C++ position.

How else can we prove that there are not enough qualified applicants and need more H1-Bs?

Encounter

[SuperKendall]

Don't think he was a duck. From the fact that he was about to give us a list of real languages but then failed to do so, I can only assume the last "ducks" was him exclaiming at being overwhelmed by a wave of ducks, that subsequently ate him.

Yes, I am quite sure the real problem is he was a victim of.... fowl play.

How much C++? All of it, if possible

[OrangeTide]

Unless you've mastered C++, all you will accomplish is writing lots of difficult bugs. Really only gurus should be working on C++ projects. If I can't find enough gurus, then I would pick a different language for the project. (I worked on C projects most of my career because I'm not a C++ guru)

Re:slashdot and languages

[OrangeTide]

C++ is just another language. It's in no way harder than C, interlisp or Python.
Standard libraries are just some libraries. All languages have those.

Easy for you to say, but tough for you to prove or defend.