• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

What level of a C++ programmer am I?

invidia

Platinum Member
A vague question, what separates a beginner/intermediate/pro C++ programmer?

I have a firm grasp of control functions, polymorphism, inheritance, and classes/functions. Actually used them in programming too.

Just wondering because a friend asked me and I didn't know how to answer except give # of years I've used C++.
 
A professional programmer gets paid for his programming. So that's an easy one to figure out.

I think a better term in your case would be beginner/intermediate/advanced, but I don't think that's a really a fair way to represent someones skills. Those concepts you named apply much more to general programming then to C++. A programming language is just a language, you can know the grammar of the language but if you don't know how to manipulate that grammar to create useful programs you might as well not know it. I would expect an advanced programmer to be able to demonstrate all of those concepts in wide array of applications and design patterns with little thought to the actual language(provided it's a common language and not something obscure). I wouldn't expect them to know all possible languages obviously, but I would expect them to have very little trouble overcoming a new language.

On top of all of that, I would also expect an advanced programmer to be knowledgeable about multi-threading. A couple of years ago I wouldn't have made that statement, but with the recent changes going on in the CPU/GPU market knowing how to properly design a multi-threaded application is becoming more and more a necessity.
 
My distinction would go something like this.

1. Beginner.
Code is all in one file. Syntax is "OK" but not great. There are either too few or too many comments everywhere. Functions aren't descriptive of what they do, error checking is very weak to non-existent.

2. Intermediate
Modular files are taking root. Syntax is near perfect. Comments are near perfect. The developer is mostly concerned with learning new libraries and APIs and not so much what an API is. They might be able to work on a team of developers, then again, they might not. Concepts of OOP should be down pat. Should understand some of the basics of whats going on behind compiling.

3. Advanced.
As Crusty said, they should have a good understanding of advanced concepts and be able to implement them (Multithreading ect). They should be able to contribute to most major open source projects out there it a helpful way. They know how to debug their code. When they program, it is usually pretty optimal, however they know when to optimize and when to simplify.

Advanced should have a good knowledge of 1 or more OS's of their choice (like windows or linux) and how to make application specific programs for both. They will know some ASM for those delicate math operations that they sometimes have to do. Advanced has pretty good knowledge of their compiling environment. They know of specific bugs and work arounds for them.

The advanced programmer knows how to design good code, optimize it, and fix major bugs. They write code that is easily maintainable by anyone and yet very elegant in its own regard, these are the people that truly understand the art of programming.

By those measurements I place myself at intermediate starting towards advanced.

By what you have said, it sounds like you have basic concepts down. I would place you (totally arbitrarily, I really don't know where you are at and you very well could be higher) at a late stage beginner to early stage intermediate. The reason for that is because you mention pretty basic concepts as your qualification.
 
Because this question is inherently subjective, you're better off not using "beginner/intermediate/pro" as a distinction. Number of years is the way to go, followed by an interview to figure out what the programmer knows, and if it's enough for the task at hand.

Edit: I mean that the conversation should start with number of years, not that the number of years tells you more about a programmer's proficiency than the interview.
 
Back
Top