Related
I am totally new to programming as though I have my PhD as a molecular biologist for the last 10 years. Can someone please tell me: Would it be too hard to handle if I enrolled simultaneously in C++ and python? I am a full time employee too. Both courses start and finish on the same dates and is for 3 months. For a variety of complicated reasons, this fall is the only time I can learn both languages. Please advise.
GillingsT
Update:
A little more detail about myself: as I said I did a PhD in Molecular Genetic. I now wish to be able to obtain programming skills so that I can apply it to do bioinformatics- like sequence manipulation and pathway analysis. I was told that Python is great for that but our course does not cover basics for beginners. I approached a Comp Sci Prof. who suggested that I learn C++ first before learning Python. So I got into this dilemma (added to other logistics).
You'll get holes in the head.
Python's data structures and memory management are radically different from C++.
Whichever language you "get" first, you'll love. The other you'll hate. Indeed, you'll be confused at the weird things one language lacks that the other has. One language will be reasonable, logical, unsurprising. The other will be a mess of ad-hoc decisions and quirks.
If you learn one all the way through -- by itself -- you'll probably be happier.
I find that most folks can more easily add a language to a base of expertise.
[Not all, however. Some folks are so mired in the first language they ever learned that they challenge every feature of a new language as being nonsensical. I had a guy in a Java class who only wanted to complain about the numerous ways that Java wasn't Fortran. All the type-specific stuff in Java gave him fits. A lot of discussions had to be curtailed with "That's the way it is. If you don't like it, take it up with Gosling. My job isn't to justify Java; my job is to get you to be able to work with java. Can we move on, now?"]
If you are new to programming, I would say start with the C++ class. If you get the hang of it and enjoy programming, you can always learn Python later. There are a wealth of good books and Internet resources on pretty much any programming language out there that you should be able to teach yourself any language in your spare time. I would recommend learning that first language in a formal classroom, however, to help make it easier to learn the general concepts behind programming.
Edit: To clarify the point I was trying to make, my recommendation is to take whichever course is geared more towards beginning programmers. The important things to learn first are the basic fundamentals of programming. These apply towards almost any language. Thanks to the wealth of resources available online or in your bookstore/library, you can teach yourself practically any programming language that you want to learn. First, however, you must grasp the basics, and intro C/C++ classes typically (in my experiences, at least) do a good job of teaching programming fundamentals as well as the language itself.
Since you are a beginning programmer, I would not recommend trying to learn two languages at once (especially if you are trying to learn fundamentals at the same time). That's a lot of very similar (yet very different) information to keep track of in your head, almost like trying to learn two brand new spoken languages at the same time. You may be able to handle it perfectly fine but at least for most programmers that I know, it is much easier to get a good grasp on one language first and then start learning the second.
I think that given the circumstances (fulltime employee, etc) studying one language will be hard enough. Pick one, then study another. You'll learn basics from either language.
As for "which language to pick"... I specialize in C++, and know a bit of python. C++ is much more difficult, more flexible, and more suitable for making "traditional" executables.
I'd recommend to start with C++. You'll learn more concepts (some of them doesn't exist in python), and learning python after C++ won't be a problem.
edit:
From your comment on this question, it appears the Python course is not geared towards beginner programmers. They'll probably be covering some of the more advanced topics of programming without touching on the basics of program flow which are really essential. So if the C++ course is geared towards beginners, then I would recommend that you take the C++ course and teach yourself Python on the side.
There is a wealth of Python tutorials out there. The official one is also really good. You don't have to wait to learn Python, of course, you can do it right now by going to any of those tutorials. The first tutorial I linked, by Alan Gauld, is geared towards non-programmers and is really high quality. He's also a regular contributor/moderator of the python tutor list. If you want to really learn Python, subscribe to that list and ask questions when you have them and do your best to answer questions that are posed - that's how I learned Python and I credit that process with much of my knowledge and understanding. As a PhD you've probably seen countless times that teaching someone else helps you retain your knowledge better and forces you to really understand the concepts.
When you do start learning, there's a great package of Python tools called Python (X,Y) that is designed for doing scientific type computing. It has all sorts of great tools packaged with it.
If you've had any experience programming, then you should easily be able to handle both course loads. What I mean is that if you can understand the following two programs, you should be able to easily perform the course loads.
Python:
elements = ['Sn', 'Pb', 'Au', 'Fr', 'F', 'Xe', 'H']
for element in elements:
if element == 'Sn':
print 'Tin'
elif element == 'Pb':
print 'Lead'
elif element == 'Au':
print 'Gold'
else:
print 'Other'
C++
#include <stdio>
#include <string>
using namespace std;
int main(){
string name;
int age = 0;
cout << "Please enter your name: ";
cin >> name;
cout << "Please enter your age: ";
cin >> age;
cout << "Hello " << name << "! You are " << age << " years old!" << endl;
return 0;
}
Even if you don't know exactly what's going on, in the programs, if you kind of have an idea, you should do just fine. These are typical programs that you'd expect to see in the first few weeks of class, and if you can look at them and figure out what's going on you're probably at least better off than the average student.
If you look at both of these programs and think, "What in the...??? I'm so confused!", then you should only take the Python course. Python makes it a lot easier to grasp the concepts (and write programs) than C++. The knowledge you gain in either language easily translates to the other, but you have to be exposed to a lot more in C++ than Python. For example, that C++ program looks like this in python:
name = raw_input("Please enter your name: ")
age = raw_input("Please enter your age: ")
print "Hello", name, "! You are", age, "years old!"
You can usually focus on one concept at a time without having to worry about possible bugs being introduced by other language features.
But if you can guess what's going on in both programs within 5 minutes, I'd go ahead and take both classes - as a molecular biologist you've had to do plenty of logical thinking which is essential to programming (not so essential to being a high-schooler).
Good luck!
I think it all depends on the level or difficulty of the of the class and that the languages in and of themselves really don't make that much of a difference.
To me, programming is 95% logical and about 5% dealing with syntax and the actual language. I started programming in high school and up through college (a senior a Computer Eng Currently) the focus was all about understanding the mindset of things and learning how to logically think through a problem and then develop a solution. Very few of our classes were a C++ or Java or Python based class. Of course there were some that focused on the more obscure languages such as x86 Assembly, but even then the idea was more of learning how to attack a problem. As a MCB person you should be fine with that.
For the other 5%, which is the actual language, taking two classes in two different languages will lead to crossovers. Of course a lot of what you learn in both can be applied to the others such as loops, conditionals, classes etc. However syntax is what is going to mess you up. You'll find yourself writing the syntax for the other language when you don't mean to. Simple things such as an if statement
Python:
if x > y
C++:
if (x > y)
But other than syntax issues, I really think all languages are pretty much the same. Sure people are going to disagree and that yes different languages are better at things than others but if you're not taking a graduate level class and these are both pretty basic intro classes what you learn could actually complement the other class you're taking.
But of course the biggest question for you to consider is time. Even being a full time student taking multiple heavy programming classes is not smart. Often times assignments are longer than expected or more difficult than first realized. So if you're going to have multiple long involved projects dealing with coding you may want to pick just one class. Especially seeing as a lot of what you learn in one can easily be translated to the other and vice-versa.
I think you pretty much answered this question yourself:
I was told that Python is great for that but our course does not cover basics for beginners.
In other words, the Python course is not an introductory course -- it assumes you already know how the basics of programming. That's probably why the professor suggested you take the C++ course first.
I come from a computational maths background, and have written sizeable (commercial and accademic) programs in both C++ and python. They are very different languages and I would probably learn one first (or only one).
Which one would depend on what you want to be able to do with the language.
If you want to build something useful with your language that is not (overly) compute or data heavy, go with python, you'll get something useful quicker.
If you need to do something useful that is either compute heavy or data heavy, then you'll probably need to go with C++. But it will take you longer to get to something to do what you need --- It will take a while to learn C++, then additional time to code data-heavy or compute-heavy code effectively.
Now some will say that python can handle data/compute heavy jobs well enough.. but in molecular biology "heavy" can mean very heavy.
Having said this, my suggestion is go with python if you can.
You've got to find out what people in your field are programming with so you can leverage existing libraries/APIs/projects. It won't do you any good re-inventing the wheel in C++ or Python if there's some wicked-cool FORTRAN library out there that is standard in your field. (And, if that is the case, God help you, I'm sorry.) Anyway, the CS prof you talked to might not have any idea what computational molecular geneticists use.
For reasons I will spare you, I have two weeks to learn some C++.
I can learn alone just fine, but I need a good source. I don't think I have time to go through an entire book, and so I need some cliff notes, or possibly specific chapters/specialized resources I need to look up.
I know my Asm/C/C# well, and so anything inherited from C, or any OOP is not needed.
What I do need is some sources on the following subjects(I have a page that specifies what is needed, this is basically it, but I trimmed what I know):
new/delete in C++ (as opposed to C#).
Overloading cin/cout.
Constructor, Destructor and MIL.
Embedded Objects.
References.
Templates.
If you feel some basic C++ concept that is not shared with C/C# is not included on this list, feel free to enter those as well. But the above subjects are the ones I'm supposed to roughly know in two week's time.
Any help would be appreciated, thanks.
Edit: I want to clarify - I don't expect to study for two weeks and then go and write Quake.
I need to get to a level where given some code and a while to think about it, I can understand it. nuances like ++X vs X++ don't matter as much as knowing what the main keywords are, etc.
This site is your best bet. Although its a great reference anyway, the way the questions are phrased and organised you'll be able to get up to speed quicker:
http://www.parashift.com/c++-faq-lite/
I will be honest with you. In 2 weeks, you won't be able to learn the whole C++.
Let me rephrase that, because no one will ever know everything about C++ (it is very huge and yet it's still growing), you won't be able to learn everything you need to become an expert C++ programmer.
However, if you do have some good programming background, many concepts in C++ will sound familiar to you. This will help you learn complex concepts quicker than novice programmers.
I would suggest you to go to C++ FAQ Lite
because it is the site that lists all the main concepts of C++.
Don't expect to program something enterprisy after going through the site, because that ability comes after you have coded some extensive systems in C++. However, the site will definitely help you to understand what C++ looks like and other people deal with in C++.
GOOD LUCK :)
Thinking in C++, Volume II. Free, well written and available online.
http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html
I know you said you didn't want to read a book but "Accelerated C++" is probably what you want. It was actually was used in like a 2 week crash course at Stanford from what I remember to get people up to speed on C++.
If you do not have time to go through an entire book, you may try an online tutorial such as the one at http://www.cplusplus.com/doc/tutorial/.
However, it will be useful to go into more depth about common pitfalls and good practice in C++. A good online resource for this is the C++ FAQ lite, at http://www.parashift.com/c++-faq-lite/ .
If you decide to buy or borrow a book, "Effective C++" by Scott Meyers would be a good choice. You do not need to read it front to back, as each chapter is dedicated to a specific problem you are likely to encounter when writing C++ code, and can be read separately.
If you need quick explanations of specific sections of the language, http://www.learncpp.com/ is also a good resource. The caveat is that their webserver is dog slow most of the time (which is unfortunate, because they have some really good explanations).
I have to interview some C++ candidates over the next few weeks and as the most senior programmer in the company I'm expected to try and figure out whether these people know what they are doing.
So has anybody got any suggestions?
Personally I hate being left in a room to fill out some C++ questions so I'd rather do a more complex test that I can chat with the interviewee about their approaches and so forth as we go along. ie it doesn't matter whether they get the right answers or not its how they approach the problem that interests me. I don't care whether they understand obscure features of the language but I do care that they have a good solid understanding of pointers as well as understanding the under lying differences between pointers and references. I would also love to see how they approach optimisation of a given problem because solid fast code is a must, in my opinion.
So any suggestions along these lines would be greatly appreciated!
I wouldn't make them write code. Instead, I'd give them a couple of code snippets to review.
For example, the first would be about design by contract: See if they know what preconditions, postconditions and invariants are. Do a couple of small mistakes, such as never initializing an integer field but asserting that it is >= 0 in the invariant, and see if they spot them.
The second would be to give them bool contains(char * inString, char c). Implement it with a trivial loop. Then ask whether there are any mistakes. Of course, your code here does not check for null in the input parameter inString (even if the very previous question talked about preconditions!). Also, the loop finishes at character 0. Of course, the candidate should spot the possible problems and insist on using std::string instead of this char * crap. It's important because if they do complain, you'll know that they won't add their own char *'s to new code.
An alternative which addresses containers: give them a std::vector<int> and code which searches for prime numbers or counts the odd numbers or something. Make some small mistake. See if they find any issues and they understand the code. Ask in which situation a std::set would be better (when you are going to search elements quite systematically and original order of entrance doesn't matter.).
Discuss everything live, letting them think a couple minutes. Capture the essence of what they say. Don't focus on "coverage" (how many things they spot) because some people may be stressed. Listen to what they actually say, and see if it makes any sense.
I disagree with writing code in interviews. I'd never ask anyone to write code. I know my handwritten code would probably suck in a situation like that. Actually, I have seldom been asked to do so, but when I have, I haven't been hired.
This one is a great complex task, even though it is looking quite harmless.
I believe that a C++ programmer needs more than just generic programming skills, because...
In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg.
Writing bug-free, maintainable C++ code places a much higher demand on a few areas than most languages.
One thing I'll call "pedanticness". You know how some people can spot spelling errors in something at a glance? A C++ programmer needs to be able to spot simple bugs while they read or write code (whether the code is their own or not). A programmer who relies on the "compile and test" technique just to get rid of simple bugs is incompatible with the C++ language, because those bugs don't always lead to immediate failure in C++.
C++ programmers also need a good knowledge of low-level stuff. Pointers, memory allocators, blocking, deadlocks. And "nitty gritty" C++ issues, like multiple inheritance and method hiding and such, particularly if they need to maintain other people's code.
Finally, C++ programmers need to be able to write code that's easy for other people to use. Can they design stuff well?
A good test for the first two areas is "Here's some C++ code I got off the internet. Find the bugs, and identify the unneccessary bits." (There's lots of really bad C++ code available on the internet, and often the programmer does unnecessary things due to a faulty understanding of how to be "safe" in C++.)
The last area you can test with more generic interview questions.
A few questions can allow you to know a lot about a candidate:
Differences between a pointer and a reference, when would you use each?
Why would you make a destructor virtual?
Where is the construction order of a class attributes defined?
Copy constructor and operator=. When would you implement them? When would you make them private?
When would you use smart pointers? what things would you take into account to decide which?
Where else have you seen RAII idiom?
When would you make a parameter const? when a method?
When would you make an attribute mutable?
What is virtual inheritance?
What is template specialization?
What are traits?
What are policies?
What is SFINAE?
What do you know about C++Ox standard?
What boost libraries have you used?
What C++ books have you read? (Sutter? Alexandrescu?)
Some short exercises (no more than 10 minutes) about STL containers, memory management, slicing, etc. would also be useful. I would allow him to do it in a computer with a ready environment. It's important to observe the agility.
Checkout Joel's Guerrilla guide to interviewing. Seems a lot like what you are looking for.
"Write a program that receives 3 integers in the range of 0..2^32-1, and validates if they represent valid edges of a triangle".
It seems to be a simple question. The input is considered valid if the sum of any two edges is greater than the third edge. However, there are some pitfalls, that a good programmer will handle:
The correct type to use should be unsigned long. Many "programmers" will fail here.
Zero values should be considered as non-valid.
Overflow should be avoided: "if (a+b <= c) return false" is problematic since a+b may cause an overflow.
if (a <= c-b) is also bad solution since c-b may be negative. Not a good thing for unsigned types.
if (c > b) { if (a <= c-b) return false; } else { if (a <= b-c) return false; } This looks much better, but it will not work correctly if (a >= b+c).
A good programmer must be detail oriented. This simple exercise will help checking if he is.
Depending on what your organisation's pre-screening is like, assume that the person knows nothing at all about C++ and has just put in on their CV because it makes them look supertechnical. Seriously. Start with something simple, like reversing a string. I have had candidates who couldn't even write a function prototype for this !!
Do not forget to also test for code bigotry. I know I don't want anyone working for or with me that isn't a flexible and consequently practical programmer both in their attitude to the programming language, but also in their approach to problem solving.
Denying any type of preconceptions
Understanding the value of the
exceptions in any Best Practices
Being capable of refusing long term
habits in favor of something else if
the need arises
These are characteristics dear to me. The manner of testing for these is not ideal if the interviews aren't lengthy or don't involve presenting code. But showing code snippets with purposely debatable techniques while offering a use case scenario and asking the candidate how they feel about the solution is one way.
This article offers some general ideas that are relevant regardless of what language you're working with.
Don't test only the C++ and overall technical skills! Those are of course important, but they are nothing if people don't listen, don't answer properly or don't follow the commitments they made.
Check at most for the ability to clearly communicate. If people cant tell you what roughly they did in their former jobs within a few minutes, they will also be unable to report about their work at your place etc.
In a recent company we invited people for interviews in groups of about 3 people together. They were surprised, but nobody was angry about that. It was very interesting, because people had to communicate not only with us, but also with others in the same position. In case we were interested further, we arranged a second interview.
You can choose potentially problematic task and see how they approach it. Ask them to write a smart pointer for example, you'll see if they understand pointers, references and templates in one step :) Usually they are stressed so they will do mistakes, those mistakes might help you find out how good they problem solving skills are, what paths would they use to fix a mistake and so on. The only problem with this approach is that sometimes interviewee just don't know anything about the task and you would have to quickly figure out something easier. If they do perfect code you can discuss their choices but when there's nothing to look at it is depressing for both of you.
Here is my answer to a similar question geared towards C#, but notice that my answer is language agnostic. My interview question is, in fact, in C. I rarely interview a person with the goal of finding out if they can program. I want to find out if they can think, problem solve, collaborate, communicate, understand something new, and so on. In the meantime, I circle around trying to see if they "get it" in terms of the big picture of software engineering. I use programming questions because that's a common basis and an easy ruse.
Get Codility.com to screen out non-programming programmers, this will get you a limited number of mostly reasoable candidates. Sit for an hour with each of them and try to build something together (a micro web server, a script for processing some of your data, a simple GUI). Pay attention to communication skills, i.e. how much effort does it take to understand the candidate. Ask the candidate for recommendation of books related to the subject (C++ software development in your case). Follow Guerilla Guide to Interviewing, i.e. answer yourself honestly, if the person is smart and gets things done. Good luck.
Check 10 C++ Interview Questions by Tests4Geeks.
It's an addition to their pre-interview C++ test and it has really usefull questions. Many people have been working on these interview questions so it's quite balanced and has no tricky or syntax questions.
Idea is quite simple - first you weed out incompetent candidates using the test, then you use article questions in real-life interview.
Whatever you do, pairing would be a good idea. Come up with a good program and pair with the guy and work towards solving the problem. IMHO, that a very good idea
So has anybody got any suggestions?
I'd recommend getting a copy of this:
http://www.amazon.co.uk/Programming-Interviews-Exposed-Secrets-Programmer/dp/047012167X/ref=sr_1_1?ie=UTF8&s=books&qid=1252499175&sr=8-1
ie it doesn't matter whether they get the right answers or not its how they approach the problem that interests me
You could ask the candidate to come up with a UML design to a common problem. If they show you a design pattern, then you can talk through the pros/cons of the pattern. You could then ask them to produce some code for one of the classes.
This would help you determine their technical knowledge level and their communication abilities.
I do care that they have a good solid understanding of pointers as well as understanding the under lying differences between pointers and references
Linked list problems are good for determining whether a candidate has a solid grasp of pointers.
As for references, you could show them some code that does not use references correctly, and ask them to describe the problem.
e.g show them a class definition that contains a reference member variable, and the implementation of the constructor with the reference initialization missing.
I would also love to see how they approach optimisation of a given problem because solid fast code is a must, in my opinion.
I'd start off simple...
Show them a code example that passes strings to a function by value. (the strings should not be modified in the function). You should check they correct the code to pass the strings by const reference.
After this, you could show a constructor that uses assignment instead of initialization (for objects). Ask them to improve it.
Lastly, ask them simple questions about data structure selection.
e.g. When they should use a list rather than a vector.
If you feel they have a grasp of the fundamentals you could either ask how they approach optimization problems (discuss profilers etc), or ask them to optimize something less obvious.
Take a look into this C++ test. They have a questions about differences between pointers and references as you require.
Here is full list of topics:
Fundamentals: References & Pointers, Const Correctness, Explicit
Standard Library
Class Design, Overloading
Virtual Functions, Polymorphism, Inheritance
Memory Management, Exception Safety
Miscellaneous: Perfect Forwarding, Auto, Flow Control, Macros
These guys are really serious about their questions, they also made the great list of C++ interview question which you might ask your candidates:
https://tests4geeks.com/cpp-interview-questions/
I'm about to take a C++ test. But I only get one crack at it to get over 85%. If I don't push over that, then I don't get the job.
The problem with these tests are that they typically target generic C++, and depending on what libraries you use your definition of generic may differ. STL and Boost may seem logical to some (and should be part of most) but I worked with MFC for years before ever using templates. Why use >vector> when you've got access to CArray? (retorical question)
If you've worked with dialogs you've not used stdio. If you've worked with Borland products you've not used MFC. If you've worked with Palm, you've not used the file system, and you've definitely not used CFile.
OK, so here's the question...
Given that I'd like to pass the 85%, I'm taking online tests of "generic" C++. So... Is there a place I could go to find tests? The more the better. Correct answers are also good, either during or after the test. As long as I can learn from my mistakes.
EDIT: If your answer doesn't have a link to a test, some C++ questions, or some interview questions... You missed the point of Is there a place I could go to find tests?
Great example.. I've just found this question.
What does the following code fragment print? cout << setw(6) << setfill('#') << "Hello";
I've been coding for 9 years. And never used cout, setw or setfill once. Not since university.
Erase all the MFC from your head for now. Go pick up a book like The C++ Programming Language, and try to learn the concepts front to back. You should be fine. If they are asking for more than this, I don't want to know what their definition of "generic" is.
The few times I've been "tested" (well "interviewed"), folks were far more concerned with questions like:
What is Object Oriented Programming? OOA (analysis)? OOD (design)? UML?
When should you inherit from a class? When should a class be aggregated?
What are virtual methods? What are pure virtual methods? What is the vtable?
Sibling cast problem. class C : public A, public B; C c; B * b = & c; How to cast object b (type B*) to an A*?
What does the stack look like as a simple program executes?
Differences between heap/stack?
How does new() differ from malloc()?
etc.
There's lots of previous discussion on C++ interviewing questions here on StackOverflow and elsewhere:
https://stackoverflow.com/questions/240212/
what-is-the-difference-between-newdelete-and-mallocfree
https://stackoverflow.com/questions/347793/
c-areas-you-look-for-during-interview
https://stackoverflow.com/questions/365823/
what-kinds-of-interview-questions-are-appropriate-for-a-c-phone-screen
http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
Just to add my two cents here: If they are looking for graphic details... To see if you've memorized the entire C++ spec... Well I know the economy stinks right now but it is improving, there are other jobs out there, and you NEED to find one of them. Interviews are a two-way street. If they are into nit-picking details, this is NOT a place you want to work.
You might try Herb Sutter's book Exceptional C++; it contains items organized like questions and is, in my opinion, very clear and very well written. I don't know if it will be directly useful for the interview, but it makes you think about aspects of the language you had never considered before.
It's been a long time since I last visited it, but you might also try this site with interview questions: geekinterview.com - take a look in particular at the C++ section.
All the best for your interview :)
What does the following code fragment print? cout << setw(6) << setfill('#') << "Hello";
It prints the following sentence to standard output:
Please do not work for us. We have no clue about what it means to be a
good software developer.
I found these.
http://www.acuit.com/_vti_bin/shtml.dll/Test_C++.htm
http://www.acetheinterview.com/questions/cats/index.php/algorithm
http://www.faqs.org/faqs/C-faq/faq/
http://www.coolinterview.com/type.asp?iType=41
http://www.radiussg.com.au/Candidate%20Interview%20Guide.pdf
http://www.eecs.utoledo.edu/~ledgard/oop/left.html
Some questions in FAQ's might work as tests.
IF you are going to give tests for job then brainbench tests may help.
I guess C++ tests are free and you can get some idea of what kind of questions you can get.
Good luck for tests!
During interviews I bother about the candidate being able to show me that he/she understands what he's/she's doing and that he's/she's leaning toward "modern" C++ (i.e. template intensive).
He/she also needs to understand some subtilities of the languages, but not the most arcane. I don't ask tricky question that are based on the oddities of the language. Why?
STL mastery is a pre-requisite. I see knowing nothing about Boost as a bad sign.
If I were to write a test, I would make it quite easy just to filter the really bad programmers that don't master the syntax and the logic of C++. I however prefer a one hour one-to-one interview to filter candidates.
If you find yourself fighting against a very hard written C++ test : run away.
I hope this helps.
Edit : if you really want tests and questions, check this out : http://www.gotw.ca/gotw/
There are a few free tests here and they have explanation videos on youtube for a few of the questions.
I'm a programmer with 2 years experience, I worked in 4 places and I really think of myself as a confident, and fluent developer.
Most of my colleagues have CS degrees, and I don't really feel any difference! However, to keep up my mind on the same stream with these guys, I studied C (read beginning C from novice to professional), DataStructures with C, and also OOP with C++.
I have a reasonable understanding of pointers, memory management, and I also attended a scholarship which C, DataStructures, and C++ were a part of it.
I want to note that my familiarity with C and C++ does not exceed reading some pages, and executing some demos; I haven't worked on any project using C or C++.
Lately a friend of mine advised me to learn C, and C++ extensively, and then move to OpenGL and learn about graphics programming. He said that the insights I may gain by learning these topics will really help me throughout my entire life as a programmer.
PS: I work as a full-time developer mostly working on ASP.NET applications using C#.
Recommendations?
For practical advancement:
From a practical sense, pick a language that suites the domain you want to work in.
There is no need to learn C nor C++ for most programming spaces. You can be a perfectly competent programmer without writing a line of code in those languages.
If however you are not happy working in the exact field you are in now, you can learn C or C++ so that you may find a lower level programming job.
Helping you be a better programmer:
You can learn a lot from learning multiple languages though. So it is always good to broaden your horizons that way.
If you want more experience in another language, and have not tried it yet, I would recommend to learn a functional programming language such as Scheme, Lisp, or Haskell.
First, having a degree has nothing to do with knowing C++. I know several people who graduated from CS without ever writing more than 50 lines of C/C++. CS is not about programming (in the same sense that surgery is not about knives), and it certainly isn't about individual languages. A CS degree requires you to poke your nose into several different languages, on your way to somewhere else. CS teaches the underlying concepts, an understanding of compilers, operating systems, the hardware your code is running on, algorithms and data structures and many other fascinating subjects. But it doesn't teach programming. Whatever programming experience a CS graduate has is almost incidental. It's something he picked up on the fly, or because of a personal interest in programming.
Second, let's be clear that it's very possible to have a successful programming career without knowing C++. In fact, I'd expect that most programmers fall into this category. So you certainly don't need to learn C++.
That leaves two possible reasons to learn C++:
Self-improvement
Changing career track
#2 is simple. If you want to transition to a field where C++ is the dominant language, learning it would obviously be a good idea. You mentioned graphics programming as an example, and if you want to do that for a living, learning C++ will probably be a good idea. (however, I don't think it's a particularly good suggestion for "insights that will help throughout your live as a programmer". There are other fields that are much more generally applicable. Learning graphics programming will teach you graphics programming, and not much else.)
That leaves #1, which is a bit more interesting. Will you become a better programmer simply by knowing C++? Perhaps, but not as much as some may think. There are several useful things that C++ may teach you, but there also seems to be a fair bit of superstition about it: it's low-level and has pointers, so by learning C++, you will achieve enlightenment.
If you want to understand what goes on under the hood, C or C++ will be helpful, sure, but you could cut out the middle man and just go directly into learning about compilers. That'd give you an even better idea. Supplement that with some basic information on how CPU's work, and a bit about operating systems as well, and you've learned all the underlying stuff much better than you would from C++.
However, some things I believe are worth picking up from C++, in no particular order:
(several of them are likely to make you despair at C#, which, despite adopting a lot of brilliant features, is still missing out some that to a C++ programmer seems blindingly obvious)
Paranoia: Becoming good at C++ implies becoming a bit of a language lawyer. The language leaves a lot of things undefined or unspecified, so a good C++ programmer is paranoid. "The code I just wrote looks ok, and it seems to be have ok when I run it - but is it well-defined by the standard? Will it break tomorrow, on his computer, or when I compile with an updated compiler? I have to check the standard". That's less necessary in other languages, but it may still be a healthy experience to carry with you. Sometimes, the compiler doesn't have the final word.
RAII: C++ has pioneered a pretty clever way to deal with resource management (including the dreaded memory management). Create an object on the stack, which in its constructor acquires the resource in question (database connection, chunk of memory, a file, a network socket or whatever else), and in its destructor ensures that this resource is released. This simple mechanism means that you virtually never write new/delete in your top level code, it is always hidden inside constructors or destructors. And because destructors are guaranteed to execute when the object goes out of scope, even if an exception is thrown, your resource is guaranteed to be released. No memory leaks, no unclosed database connections. C# doesn't directly support this, but being familiar with the technique sometimes lets you see a way to emulate it in C#, in the cases where it's useful. (Obviously memory management isn't a concern, but ensuring that database connections are released quickly might still be)
Generic programming, templates, the STL and metaprogramming: The C++ standard library (or the part of it commonly known as the STL) is a pretty interesting example of library design. In some ways, it is lightyears ahead of .NET or Java's class libraries, although LINQ has patched up some of the worst shortcomings of .NET. Learning about it might give you some useful insights into clever ways to work with sequences or sets of data. It also has a strong flavor of functional programming, which is always nice to poke around with. It's implemented in terms of templates, which are another remarkable feature of C++, and template metaprogramming may be beneficial to learn about as well. Not because it is directly applicable to many other languages, but because it might give you some ideas for writing more generic code in other languages as well.
Straightforward mapping to hardware: C++ isn't necessarily a low level language. But most of its abstractions have been modelled so that they can be implemented to map directly to common hardware features. That means it might help provide a good understanding of the "magic" that occurs between your managed .net code and the CPU at the other end. How is the CLR implemented, what do the heap and stack actually mean, and so on.
p/invoke: Let's face it, sometimes, .NET doesn't offer the functionality you need. You have to call some unmanaged code. And then it's useful to actually know the language you might be using. (if you can get around it with just a single pinvoke call, you only need to be able to read C function signatures on MSDN so you know which arguments to pass, but sometimes, it may be preferable to write your own C++ wrapper, and call into that instead.
I don't know if you should learn C++. There are valid reasons why doing so may make you a better programmer, but then again, there are plenty of other things you could spend your time on that would also make you a better programmer. The choice is yours. :)
Experience is the best teacher.
While you can read about things like memory management, data structures (and their implementations), algorithms, etc., you won't really get it until you've had a chance to put it in to practice. While I don't know if it's truly necessary to use C or C++ to learn these things I would put some effort into actually writing some code that manages its own memory and implements some common data structures. I think you'll learn things that will help you to understand your code better; to know what's really going on under the hood, so to speak. I would also recommend reading up on computer organization and operating systems, computer security, and boolean logic. On the other hand, I've never really found a need to do any OpenGL programming, though I did do some X Windows stuff once upon a time.
Having degree has got nothing to do with C/C++ actually. Now, stuff like big O() estimation, data structures or even mathematical background. For example linear algebra results very useful, even in context that seemingly have nothing to do (eg. search engines).
For example typical error that a good coder, but without any theoretical knowledge, might commit is to try to solve NP-complete problems by exact algorithm, rather than approximation.
Now, why in universities they teach you C/C++? Because it let's you see how it's all working "under the hood". You get opportunity to see how call stack works, how memory management works, how pointers work. Of course you don't need that knowledge to use most modern languages. But you need that to understand how their "magic" works. Eg. you can't understand how GC works, if you got no idea about pointers and memory allocation.
I've often asked this question (to myself). I think the more general version is, "how can I call myself a programmer if I don't know how to kick around a language that doesn't have automatic garbage collection, with pointers and all that 'complex' stuff'?" I've never learned C++ except to do a few HelloWorlds, so my answer is limited by that lack:
I think that the feeling that you need to learn C++ (or assembler, really) comes from the feeling that you're always working on someone else's abstractions: the "rocket scientists" who write the JVM, CLR, whatever. So if you can get to a lower level language, you'll really know what you're talking about. I think this is quite wrong. One is always building on a set of abstractions: even Assembler is translated into binary, which can be learned as well. And beyond that, you still couldn't make a computer out of firewood, even if you had a pair of pliers and a bit of titanium.
In my experience as a corporate trainer in software dev (in Java, mostly), the best people were not those who knew C++, but rather those that took the language that they are working in as an independent space for "play." Although memory management comes up all the time in C# and Java, you never have to think about anything beyond freeing your object from references (and a few other cliche places, like using streams instead of throwing around huge objects in memory). Pointers and all that stuff do not help you there, except as a right of passage (and a good one, I'm sure).
So in summary, work in the language you're in and branch out into as many relevant things as possible. These days I find myself dipping into Javascript though the APIs are supposed to make this unecessary, and doing some stuff in Fireworks while I mess with CSS by hand. And this is all in addition to the development I'm really doing in RoR, PHP and Actionscript. So my point is: focus on abstractions that you need, because they're more likely to be relevant than the lower-level stuff that underlies your platform.
Edit: I made some slight changes in response to jalf's comments, thanks.
I have a 1st class Software Engineering degree and work for a large console manufacturer developing a game engine in a team of programmers all of whom program across a wide range of languages from Asm to C++ to C# to LUA and know the hardware inside out.
I would say that 5% of my degree was useful and that by far and away the most important trait to furthering my career has been enthusiam and self development.
In fact many of the colleagues I've worked with haven't had a degree and on average have probably been the better ones.
I'd say this is because they've had to replace that piece of paper from a university degree with actual working code that they've developed in thier own spare time learning the skills off thier own back rather than being spoon fed it.
My driving instructor use to tell me that I would only start learning how to drive after I pass my test ie you only really learn from the practical application of the basics. A CS degree gives you the basics which if you've had a job programming any of the major languages for 6 months you will already have. A degree just opens up doors that you may not have otherwise - it doesn't help that much once inside the door.
Knowing how the software interacts with the hardware by the sounds of it is the most important area for you at the moment only then does the 'mystery' or 'magic' really disappear and you can be confident of what your talking about else where. Learning C and C++ will undoubtedbly help in this respect as will knowing an API like OpenGL.
But I'd say the most important thing is to find something you have interest in and code that. If you have real enthusiam for it you will naturally learn more low level information and become a better programmer, if indeed that is what your definition of being a better programmer is!
I've been working as a developer with no degree for almost 15 years now. I started with Ada and moved quickly into C/C++, but it's been my experience that there will always be some language that you "have to learn." If it's not C++, it will be C# or C or Java or Lisp. My advice is make sure you're solid on the basics that apply to any language(my best friend as a dev with no degree was the CLR book), and you should be able to move relatively easily between languages and frameworks.
You don't absolutely have to learn C/C++, but both languages will teach you to think about how your software interacts with the underlying OS and hardware, which is a essential skill. You say that you already know about pointers, memory management and so on, which is great. Many programmers without a CS degree lack this important knowledge.
Another good reason to learn C/C++ is that there's a lot of code written in these languages and a good way to learn more about programming is to read other people's code. If you're interested in writing low level code like drivers, OS, file systems and the like C/C++ is pretty much the only way to go.
Do you have to learn it extensively? I expect not.
However it's best to always be learning things that help you look at programming from a different perspective. Learning C or C++ are worth it for the insight into how things work at a lower level. For C and C++ programmers the same thing might be accomplished by learning assembly. Most people won't use assembly in a project, but knowing how it works can be very helpful from time to time.
My recommendation is always to learn as much as you can. If you're not working on a C++ project in the near future I wouldn't be too worried about learning the ins and outs, but it's always good to be able to look at problems from another angle and learning new languages is one way to do that.
Today for the majority of applications, C and C++ can be viewed as an academic exercise: "How can we write programs without garbage collection?"
The answer is: you can, but it's a mostly painful experience. Most of the details of best practices in C++ are related to the lack of garbage collection.
Given the brilliant performance of modern GCs, and the general increase in computing power, even cell phones have GCs these days. And in a platform with a GC, you can always code in such a way as to limit the pressure you put on the GC.
Listen or read SO podcast 44, where Joel plays his favorite song Write in C
Spolsky: Yeah, it's not paying the proper royalties to the Beatles anyway. We'll link to that from the shownotes. Awesome song, Write in C.
Atwood: That's right, Joel's favourite song. Write everything in C, because Joel does in fact write everything in C, don't you, Joel?
Spolsky: I started using a little bit of C99, the latest version of C, which let you declare variables after you written some statements.
...
Without a professional reason (other than the good practice of self-improvement) to learn C or C++, then you should have a passionate side project planned out that you could write in C or C++. Once the going gets tough on the side project, you'll need your enthusiasm and curiosity to take you over the hump (since on a side project, you naturally don't have the motivation of pay or de-motivation of a superior looming over you).
Also, most CS degrees are using Java as their language of choice now. This just proves the point that experience gained in the language of choice and exposure to some of the theory involved in the other classes in the degree is the main benefit for people with CS degrees, and not so much the specific language (though I think the higher they go up the abstraction scale, the worse it is for the students in the long run).
Without a practical reason for learning a programming language it is pretty hard going.
If you can think of particular problems or a specific task which the language is suit for - Then the learning experience is driven by needs, rather than simple academics.
I only just recently switched from VB to C# (1 month ago) while not as significantly different as a switch from C# to C, because I switch for a particular reason I found it much easier to learn. I had dabbled previous without a specific problem to solve, needless to say I switched back
If you have a different style of learning as in self-taught then my recommendation to be a better programmer is to research topics regarding your domain. From bottom to top, slowly climb up the ladder.There is a fairly amount of different programmers, no one will excel in all, so don't start off with that context in mind.
Best of luck to you.
C++ is just a programming language. What you don't have that other students (if they paid attention in class) have is the deeper understanding that comes through studying concepts.
Being a programmer is not and should not be the end goal of any CS graduate. However it is as far as most people get without such a degree.
Here is an analogy: An engineer and an architect both at some point learn to draft buildings using CAD. Also, someone completely untrained can come in and start work using CAD and be very effective. This is a good career and it pays well, but for both the engineer and the architect it is not where you want to be when you are 30.
One value of knowing C is that many other languages including C#, Java, C++, JavaScript, Python, and PHP have their roots in C syntax.
Another value, and arguably more important, is that it will build your confidence. Programmers are a confident group and very optimistic (you have to be confident to think that you can write the equivalent of a 1000 page book without a single spelling or grammatical error). And confidence in your ability to learn and effectively use any language will grow considerably with a pure C application or two under your belt.
So write a non trivial program in C; something that at least reads and writes files, allocates and deallocates memory, and manages a data structure like a queue or binary tree.
Your confidence will thank you.