How Much C++ Should You Know For an Entry-Level C++ Job? 336
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?
Answer (Score:5, Funny)
Re:Answer (Score:5, Insightful)
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.
Encounter (Score:5, Funny)
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.
Re:Answer (Score:5, Insightful)
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 (Score:5, Interesting)
. 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 (Score:5, Informative)
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: (Score:3)
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: (Score:3)
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 ha
Re: (Score:3)
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.
Re:Answer (Score:5, Informative)
Re:Answer (Score:5, Funny)
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:
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....
W.T.F.
Re:Answer (Score:5, Informative)
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 (Score:5, Insightful)
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: (Score:3)
Re: (Score:3)
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-tri
Re: (Score:3)
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: (Score:3)
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 (Score:4, Insightful)
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: (Score:3, Informative)
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 (Score:4, Insightful)
(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 (Score:5, Interesting)
(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 [googlecode.com]? (This is almost identical to the internal guide)
- It is true that exceptions are verboten [googlecode.com], 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 [googlecode.com] 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: (Score:2)
In the field I work in, we aren't allowed to use RAII; we compile with it turned off.
You are mistaken.
You can not turn of RAII. It is only a constructor call and a destructor call.
Re: (Score:3)
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: (Score:2)
Is it really C++, or "C with classes", though?
Re: (Score:3)
*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'
Re: (Score:2)
For non-ducks, the most important things to know about C++ aren't list in the summery: RAII and shared_ptr<T>
That is not really correct. As soon as you know about ctors and dtors you know about RAII, no special "point in the list" needed.
Re: (Score:2)
Not any more than owning a chisel makes you a sculptor. If I had a dime for every init() method I've seen ...
Re: (Score:2)
NONE! Find a real language! *ducks*
Ooh, another Dice discussion!
echo "import random\nprint random.randint(1,6)" | python -
Re: (Score:2)
Re: (Score:2)
1. Would you complain if this was an "Ask Slashdot", or taken from a respected programmer's blog? Does the name behind the thing matter that much?
2. Slashdot is now owned by Dice. The Golden Rule says the one with the gold makes the rules. You're free to seek greener pastures or linger on.
Re: (Score:2)
But... but... but without Dice, my python bash one-liner would make NO SENSE )-;
Re: (Score:2)
But... but... but without Dice, my python bash one-liner would make NO SENSE )-;
[rim shot]
Re: (Score:2)
But... but... but without Dice, my python bash one-liner would make NO SENSE )-;
Err, sting... [wikimedia.org]
Re: (Score:2)
The Correct Answer (Score:5, Funny)
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?
Re: (Score:3, Insightful)
None. Go meta. (Score:5, Insightful)
Knowing C++ shouldn't matter. Demonstrating that you can quickly master and use any language should.
Re:None. Go meta. (Score:5, Insightful)
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: (Score:2)
Yup. The language / environment is largely irrelevant. That's what references, manuals, APIs, and all other forms of documentation are for.
Knowing how to program is what matters.
Re: (Score:2)
Someone might have twenty years with RPG, COBOL, FORTRAN, and DB2, but that doesn't they'll be effective in C++.
Re:None. Go meta. (Score:5, Interesting)
Pseudocode.
http://en.wikipedia.org/wiki/P... [wikipedia.org]
Also Drakon charts.
http://en.wikipedia.org/wiki/D... [wikipedia.org]
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: (Score:2)
Candidate should be able to answer any questions in pseudo code. You are right that each language has its own intricacies, and e.g. perfect code in C is terrible code in C++, but C++ is not specific enough that general programming principles don't apply.
Reading a book about the language over the weekend before the interview won't make an expe
Re: (Score:3)
Re: (Score:2, Insightful)
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: (Score:2)
Unless they need you to be productive shortly, not in 2-3 months while you learn generic programming and STL/Boost.
Re: (Score:2)
Yes, it should.
But actually C++ is a beast of a language which no one so far quickly mastered.
All we have now in C++, like STL, boost etc. is stuff that was envisioned by people who minimum had 10 years language experience before they even came to the idea to (ab)use language features like that.
When I read the first time about the concepts of the STL (that was round 1993, and it was not even called STL then) I was shocked about its simplicity and that I was so dumb that I never came to that idea myself. Bas
Re:None. Go meta. (Score:4, Insightful)
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 (Score:5, Insightful)
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: (Score:2)
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 gene
Re: (Score:2)
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).
Very very true! I'm not a C++ guy, but everytime I got put on a different COBOL project, I had to adjust to a different way of doing it.
Re: (Score:2)
That's entry level C++? That list sounds like at least a mid-level C++ programmer... how are they supposed to be entry level but have had the experience to understand a wide range of legacy code?
Re: (Score:2)
You think that is bad,,, see what they are paying for someone with that skill set.
Re: (Score:2)
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?"
Irony: a C programmer who doesn't like languages that let you shoot yourself in the foot :)
Re: (Score:2)
Degrees of damage. Hell, it's the oldest joke in the programmer's book:
C: You shoot yourself in the foot.
C++: You accidently create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying "That's me, over there."
Re: (Score:2, Insightful)
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_thi
Re: (Score:2, Informative)
* Objects passed by value which don't have a deep assignment copy constructor. // Bang! There goes another foot... maybe if we had GC...
* 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();
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
Re: (Score:2)
I agree with most of what you said, but this one stumps me. You've just defined a primitive array - An array named var of type type and size size. Other than its... well, primitiveness (no fancy default conversions, no memory management, no overloads to deal with it as a whole), what about that syntax do you object to?
Re: (Score:2)
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
Which C++? (Score:5, Insightful)
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: (Score:3)
That's the real question! Too bad I'm all out of points!
I'd go with... (Score:4, Informative)
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.
Subjective questions deserve subjective answers (Score:2)
Simple Answer (Score:2)
Enough C++ to get the job.
Re: (Score:2)
The poster did not specify that they wanted to keep the job, only to land it.
As much as possible... or none at all (Score:4, Interesting)
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).
Re: (Score:2)
>> Any really good company/department is going to find it more important to find the right person than skills in a particular language.
Not at all. Companies used to be more like that but now its all about whether you can hit the ground running.
Re: (Score:2)
Rather... never hit the ground. Keep flying. And be fed insignificant amounts of $$fuel.
Re: (Score:2)
"How do you monetize Slashdot?" (Score:5, Funny)
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..."
Re: (Score:2)
Re: (Score:2)
Well played sir.
oooh really? (Score:2, Insightful)
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 (Score:3)
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."
"a senior developer will likely get furious" (Score:5, Informative)
....and water will likely get wet.
For C++, there is no standard answer (Score:5, Insightful)
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.
My opinion (Score:2)
I would say everything you listed with the exception of the standard library. (Read on before flaming)
You don't need to have full knowledge of the standard library but you should have an understanding of containers and iterators. You don't need to memorize all the APIs but have access to the documentation AKA Google to be able to look up what you are unfamiliar with and to understand the full capabilities of what you are using.
There are other things in the standard library that are useful to know like algor
Code reviews (Score:5, Insightful)
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.
You cannot generalize this (Score:2)
The question "How much C++ do you have to know for an entry level job" can be answered. The question "how much X do you..." not.
How much you have to know for an $X level job depends on the job. The more people can do X, the higher the level will have to be. Chances are that you need to know a LOT more C++ for an entry level C++ developer job than you need to know about some obscure assembler or industry machine language for an entry level job in that area, simply because there will be far fewer people with
As a hiring manager (Score:5, Informative)
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 (Score:5, Insightful)
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 (Score:2)
More than the other applicants.
C++ is so broad as to render this question useless (Score:4, Insightful)
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.
You need to know... (Score:2)
At least as much as I do and I've been coding in C++ for about 20 years...
Now get off my lawn!
Seriously, Know enough to satisfy the intervener, how much is that? Who knows.... So go for as much as you can...
Standard Library (Score:2)
Standard Library as in stdlib/stdio or iostream? BECAUSE FUCK IOSTREAM!
First, define what you mean by "C++" (Score:4, Interesting)
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: (Score:2)
C++ native Android loadable kernel module?
I'm an Android BSP developer, and I don't know what the hell you're talking about.
understanding of OO, not just the syntax of C++ (Score:2)
slashdot and languages (Score:2)
Now slashdot is doing it again.
If you understand programming, you can pick up most of that within a few weeks. If a senior dev gets mad at you during those weeks, look for another job.
If you don't understand programming and know all that stuff, there's no way you will learn the libraries and software that specific company uses within a few weeks and a senior developer will get furious.
C++ is just another language. It's in no way harder than C, interlisp or Python.
Standard libraries are just some libraries.
Re: (Score:3)
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.
How much C++? All of it, if possible (Score:4, Insightful)
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)
42 (Score:2)
What were the units again?
Read Yossef Kreinin's C++ FQA and its rebuttals (Score:2)
You'll get a lot of insights on C++ after doing do.
- http://yosefk.com/c++fqa/ [yosefk.com]
- http://stackoverflow.com/quest... [stackoverflow.com]
- https://gist.github.com/klmr/5... [github.com]
- http://c2.com/cgi/wiki?CppBash... [c2.com]
All of it. (Score:2)
The answer is the same as the answer to a question: "How much of the driver's handbook do you need to know for entry level driver job?" ... All of it.
Entry Level? (Score:2)
Based on most job postings I've read, I'd recommend about 10+ years of experience for an entry level position.
A knowledge of cache behaviour (Score:2)
As a game developer, I use a lot of C++, and performance is important. That's really a big part of the draw of C++ for game development. So when interviewing new grads I often ask them a bit about cache behaviour. Most really don't have a clue, but those who do show an understanding get high marks because it shows they've dug a little deeper than the rest:
Questions like:
- "Tell me what cache memory is and why it's important."
- "Let's say I have a list of objects with various bits of data like position, colo
Able to code with Qt (Score:2)
An entry level programmer is someone who should know how to code but generally lacks experience with large scale projects. I'd be less focussed on whether they can define the word polymorphism but instead know the difference between delete and delete []
An entry level programmer should be focussed on gaining experience with developing professionally. A senior level developer should be able to plan fr
Required understanding (Score:2)
I was, by coincidence, on an interview panel for a developer position earlier this week. We were looking for someone with Java and C++ skills, but didn't fail them for specific gaps in their knowledge--general attitude, aptitude and competence were what we were really evaluating. Once they are on the team you can easily fill the gaps in with training, books, code review and team working. It's better to have someone competent you can work well with, but you need to be sure they are competent and capable o
Re: (Score:3)
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".
Re: (Score:2)
X is a mess of a protocol though. Too many extensions error.
Re: (Score:2)