How do you define proficiency in C and C++?

[blytkerchan]

Thanks Dizzy, Lionel and Jeremy

Well, You are absolutely right in saying that real job is different and
is more demanding thus all your resons are valid. Jermey's example
shows a perfect analogy. Actually I need to put up the question more
clearly and I will do that now.

So as employers are more interested in their business and current
requirements than trying to judge the candidate on his abilities. I
would like to know What does it mean by " Proficient in C, C++" ? How
employers judge a person's capabilities and understanding of C, C++? I
am more interested in knowing about the pure technical aspects of C,
C++ programming, I mean symantics, syntax and programming skill test.

I appreciate your participation and hope I can know important topics to
know as a proficient C, C++ programmer.

When I hire a C++ programmer for my team, I look (in the first
screening) for experience in C++, avoiding recent experience in Java or
VB and trying to avoid "managed extentions". During the telephone
interview, I ask such questions as "who is Andrei Alexandrescu?" or
"who invented C++?" or "what is RAII?" to get a feeling of both how
literate the candidate is and how well he knows the basic concepts
("what is a virtual destructor good for?").
Finally, there's a technical examn (a rather difficult one, I might
add) during the first interview. No-body actually passes the examn but
it's a good opportunity to grill the candidates - see whether they can
think on their feet, can understand abstract notions (such as, for
example, the explanation of what a sequence point is) etc.

To be able to claim that you're proficient in C++, you'd have to at
least be able to explain a few of the basic notions of C++ (such as
RAII, RTTI, iterator concepts, etc.) as well as be able to read a bunch
of badly written code, comment it, tell me why it's badly written and
fix it.

I'm looking for programmers in the Quebec-city region, by the way, so
if you want to give my examn a show, you're quite welcome

 

[John A. Byerly]

When I hire a C++ programmer for my team, I look (in the first
screening) for experience in C++, avoiding recent experience in Java or
VB and trying to avoid "managed extentions". During the telephone
interview, I ask such questions as "who is Andrei Alexandrescu?" or

You are kidding, right?

"who invented C++?"
C'mon!

or "what is RAII?"

Hmm. 20 years experience in C++ and I have no idea.

to get a feeling of both how
literate the candidate is and how well he knows the basic concepts
("what is a virtual destructor good for?").

Are you interviewing for a historian or a developer? I can understand
asking about some specific technologies, but "Who invented C++?" Who cares?
You mean to tell me that if I didn't know the answer to that question, it
somehow made me inferior as a developer?

If I am hit with these types of questions, I am glad when the interview
process is over. The interview goes both ways, and being asked these types
of questions says to me that this is not a serious development shop.

Finally, there's a technical examn (a rather difficult one, I might
add) during the first interview. No-body actually passes the examn but
it's a good opportunity to grill the candidates - see whether they can
think on their feet, can understand abstract notions (such as, for
example, the explanation of what a sequence point is) etc.

What is a sequence point, by the way?

To be able to claim that you're proficient in C++, you'd have to at
least be able to explain a few of the basic notions of C++ (such as
RAII, RTTI, iterator concepts, etc.)

Is that right? These strike me as extensions to C++, not core C++ notions.
For instance, not every compiler supports RTTI (that is, if we are talking
about the same RTTI. This is another flag for me in interviews: Is the
interviewer trying to show his superiority by throwing around a bunch of
acronyms and jargon?).

Here are two things that are of concern when hiring a developer: 1) Does
the employee understand the problem domain, or can he demonstrate an ability
to quickly come up to speed? and 2) How proficient is the candidate in the
creation of software, which includes analysis, design, implementation, and
testing, independent of language? While there are certainly some language
issues, if the candidate doesn't understand the basic process, he is not
worth the trouble, even if he can tell you all you want to know about a
particular language. On the flip side, if you are interviewing prospects
and rejecting them because they don't understand all the jargon or know all
the acronyms, you are missing out on some great talent. Take it from
someone who doesn't understand all the jargon or know all the acronyms.

as well as be able to read a bunch
of badly written code, comment it, tell me why it's badly written and
fix it.

If this is the environment in which the candidate will be working, I
question the effectiveness of the interview process. Apparently, the people
who are being hired write bad code, in spite of knowing who invented C++.

JAB

 

[John A. Byerly]

I ask them to tell me what C++ or programming books they have read
recently, and we discuss a book or two. I also find that most C++
candidates have never heard of the standard template library. (!)

I have! In fact, it was where I checked out my most recent books on C++.

Okay, lame attempt at humor.

Just curious, though. What if someone doesn't read C++ or programming
books? Do you reject them as a candidate, or continue the interview? My
point is that there are more sources of knowledge than books. For instance,
where did the people who wrote the books get their knowledge?

JAB

 

[Victor Bazarov]

[..] What if someone doesn't read C++ or programming
books? Do you reject them as a candidate, or continue the interview?

I'd continue, just to amuse myself. Or maybe not, depending how much
stuff is on my "to do" list.

My point is that there are more sources of knowledge than books. For
instance, where did the people who wrote the books get their
knowledge?

They invented the stuff. *Seriously*, though, if somebody claims to be
a C++ programmer but never read any of C++ books, he's either mistaken
(about being a C++ programmer) or he's Dr. Stroustrup (or his immediate
colleagues at AT&T), and the year is 1985.

V

 

[Andre Kostur]

You are kidding, right?

I tend to phrase that a little differently, but same idea. Looking for
answers such as Andrei Alexandrescu, Scott Meyers, Nikolai Josuttis, Herb
Sutter. These guys have some good techinques to know. But if the prospect
doesn't know their names, it's not an immediate rejection, but does weigh
into the decision making process.

C'mon!

Yeah... this I don't worry about.

Hmm. 20 years experience in C++ and I have no idea.

"Resource Acquisition Is Initialization". _Very_ handy C++ programming
idiom. See:
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

Are you interviewing for a historian or a developer? I can understand
asking about some specific technologies, but "Who invented C++?" Who
cares? You mean to tell me that if I didn't know the answer to that
question, it somehow made me inferior as a developer?

No, but if one does not know about RAII (even after expanding the name and
a quick overview of what it is, just in case the person knows the concept,
but not the specific name) _does_ make one inferior as a _C++_ developer.
This would indicate a deficiency in common C++ idioms. Were I to hire such
a person, I'll have to teach them about these sorts of techinques.

If I am hit with these types of questions, I am glad when the
interview process is over. The interview goes both ways, and being
asked these types of questions says to me that this is not a serious
development shop.


What is a sequence point, by the way?

What's wrong with the code:

i = ++i + i++;

?

Is that right? These strike me as extensions to C++, not core C++
notions. For instance, not every compiler supports RTTI (that is, if
we are talking about the same RTTI. This is another flag for me in
interviews: Is the interviewer trying to show his superiority by
throwing around a bunch of acronyms and jargon?).

OK, what are you referring to when you say "RTTI". RTTI (Run-Time-Type-
Information) is core C++. Exactly how RTTI is implemented is not. Being
able to turn _off_ RTTI is a C++ extension. If your compiler doesn't
support RTII, then it's a non-standard conforming compiler (Assuming we're
talking about normal hosted environments. As I recall, the rules for non-
hosted environments are a little different and allow implementors to cut
certain corners.).

Here are two things that are of concern when hiring a developer: 1)
Does the employee understand the problem domain, or can he demonstrate
an ability to quickly come up to speed? and 2) How proficient is the
candidate in the creation of software, which includes analysis,
design, implementation, and testing, independent of language? While
there are certainly some language issues, if the candidate doesn't
understand the basic process, he is not worth the trouble, even if he
can tell you all you want to know about a particular language. On the
flip side, if you are interviewing prospects and rejecting them
because they don't understand all the jargon or know all the acronyms,
you are missing out on some great talent. Take it from someone who
doesn't understand all the jargon or know all the acronyms.

Yes, #1 is important. How well does the person learn. Also, has the
person been learning on their own? Have they been keeping up their own
skillset?

#2 is important as well, and is important as a pre-requisite. And if the
prospect doesn't know what RTTI is (for example), I'd expect them to ask
clarification questions. To which I'd rephrase the question to see if this
is simply a case of not knowing the specific term, or does the person not
know about RTTI at all.

You're missing #3. How proficient is the developer in the tools that your
shop uses. Who cares if the developer is fabulous in Lisp if you're a
Prolog shop. Now in my case, I don't necessarily reject them if they
don't know all of the jargon, but does clarify where they are along the
proficiency continuum so I can asses what sort of development work I can
expect from them. Can I count on them being about to write code consistent
with the rest of the codebase, or am I going to have to teach them C++
first?

 

[Alf P. Steinbach]

* Victor Bazarov:

[..] What if someone doesn't read C++ or programming
books? Do you reject them as a candidate, or continue the interview?

I'd continue, just to amuse myself. Or maybe not, depending how much
stuff is on my "to do" list.

My point is that there are more sources of knowledge than books. For
instance, where did the people who wrote the books get their
knowledge?

They invented the stuff. *Seriously*, though, if somebody claims to be
a C++ programmer but never read any of C++ books, he's either mistaken
(about being a C++ programmer) or he's Dr. Stroustrup (or his immediate
colleagues at AT&T), and the year is 1985.

Uhm, well. I think I'd be a pretty darn good C++ programmer. I don't
read any C++ books.

Cheers,

- Alf

 

[Victor Bazarov]

* Victor Bazarov:

[..] What if someone doesn't read C++ or programming
books? Do you reject them as a candidate, or continue the
interview?

I'd continue, just to amuse myself. Or maybe not, depending how much
stuff is on my "to do" list.

My point is that there are more sources of knowledge than books. For
instance, where did the people who wrote the books get their
knowledge?

They invented the stuff. *Seriously*, though, if somebody claims to
be a C++ programmer but never read any of C++ books,

I meant "read" in past tense. "Never *did* read any"

he's either

Uhm, well. I think I'd be a pretty darn good C++ programmer. I don't
read any C++ books.

Have you? You must have. If you don't (any more that is), then it
either means the books as written have no knew knowledge to offer you,
which is the case if you're really, really good, or it means that you
probably think you're good *enough* and have no time to read, in
which case you still _can_ be mistaken (about being good).

V

 

[John A. Byerly]

[..] What if someone doesn't read C++ or programming
books? Do you reject them as a candidate, or continue the interview?

I'd continue, just to amuse myself. Or maybe not, depending how much
stuff is on my "to do" list.

Wow, that is a shame!

They invented the stuff. *Seriously*, though, if somebody claims to be
a C++ programmer but never read any of C++ books, he's either mistaken
(about being a C++ programmer) or he's Dr. Stroustrup (or his immediate
colleagues at AT&T), and the year is 1985.

I used to work with a guy who thought the same way. A complete
pie-in-the-sky type. He could tell you all about the technology and how it
works, but he was not all that good at making it work.

Frankly, experience carries much more weight with me than books. If a
person does not read much, but observes a bunch, not only can he form
opinions as to which way is better in certain cases, but he has data to back
up his opinion.

I was about to say I have never read any books on programming or C++, but I
have read a few. Some that I have started (and are considered almost
"Bibles") were not worth my time. I learned much more by working with
people than by reading. But a few (Scott Meyers for C++, Booch for OO
design) were definitely worth the read. But I will put my experience up
against the size of someone else's library any day.

JAB

 

[IR]

Have you? You must have. If you don't (any more that is), then
it either means the books as written have no knew knowledge to
offer you, which is the case if you're really, really good, or it
means that you probably think you're good *enough* and have no
time to read, in which case you still _can_ be mistaken (about
being good).

IMHO there are plenty of other resources than books that can teach you
the very same techniques.

I really don't see the point insisting on _books_ as long as one
learns.


Cheers,

 

[Scott McPhillips [MVP]]

I have! In fact, it was where I checked out my most recent books on C++.

Okay, lame attempt at humor.

Just curious, though. What if someone doesn't read C++ or programming
books? Do you reject them as a candidate, or continue the interview? My
point is that there are more sources of knowledge than books. For instance,
where did the people who wrote the books get their knowledge?

I consider a candidate who has not read any C++ or programming books to
be quite weak: Apparently not trying to improve, somewhat out of touch,
probably a "coder" instead of a "software engineer." I believe that our
profession requires continuing study.

It is not a reason to terminate an interview but it will have a strong
effect on evaluating suitability and potential salary.

 

[John A. Byerly]

I tend to phrase that a little differently, but same idea. Looking for
answers such as Andrei Alexandrescu, Scott Meyers, Nikolai Josuttis, Herb
Sutter. These guys have some good techinques to know. But if the prospect
doesn't know their names, it's not an immediate rejection, but does weigh
into the decision making process.

Of the names you mention, I know only one. I probably know the techniques
they propose, but not the name. Isn't the technique more important anyway?

Yeah... this I don't worry about.


"Resource Acquisition Is Initialization". _Very_ handy C++ programming
idiom. See:
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

Thanks for the link. I read it. Okay, skimmed it. And yes, I practice it.
I just didn't know what it was called.

No, but if one does not know about RAII (even after expanding the name and
a quick overview of what it is, just in case the person knows the concept,
but not the specific name) _does_ make one inferior as a _C++_ developer.
This would indicate a deficiency in common C++ idioms. Were I to hire such
a person, I'll have to teach them about these sorts of techinques.

Actually, it makes him inferior as a developer, period. That concept is
valid in other languages, is it not? This is true with a lot of concepts.
That is why I think that focusing on the nitty-gritty of C++, especially
early in the interview process, is a mistake.

What's wrong with the code:

i = ++i + i++;

?

Other than the fact that it is unintelligible, you mean? Who writes stuff
like this? I would think the interviewer should be trying to weed out
people who write this kind of code, rather than select people to write it!

Early on in my career, I encountered people who would proudly boast writing
a whole program on one line in C++. Even cited that ability as a strength
(in programming skill, and in the C++ language for allowing it). What
nonsense! The true skill is to write functional, maintainable, usable, and
in a lot of cases, extensible code that solves the problem. In whatever
language. Too many times, these things are sacrificed at the expense of
whims of language wizards who code for their own edification.

OK, what are you referring to when you say "RTTI". RTTI (Run-Time-Type-
Information) is core C++. Exactly how RTTI is implemented is not. Being
able to turn _off_ RTTI is a C++ extension. If your compiler doesn't
support RTII, then it's a non-standard conforming compiler (Assuming we're
talking about normal hosted environments. As I recall, the rules for non-
hosted environments are a little different and allow implementors to cut
certain corners.).


Yes, #1 is important. How well does the person learn. Also, has the
person been learning on their own? Have they been keeping up their own
skillset?

How do you gauge this? As I said in another post, I don't read much. I
explore a lot. But I am never asked what applications I have written on my
own time. I am only asked what books I have read.

#2 is important as well, and is important as a pre-requisite. And if the
prospect doesn't know what RTTI is (for example), I'd expect them to ask
clarification questions. To which I'd rephrase the question to see if this
is simply a case of not knowing the specific term, or does the person not
know about RTTI at all.

I agree.

You're missing #3. How proficient is the developer in the tools that your
shop uses. Who cares if the developer is fabulous in Lisp if you're a
Prolog shop. Now in my case, I don't necessarily reject them if they
don't know all of the jargon, but does clarify where they are along the
proficiency continuum so I can asses what sort of development work I can
expect from them. Can I count on them being about to write code consistent
with the rest of the codebase, or am I going to have to teach them C++
first?

I certainly didn't mean to imply that knowledge of the specific language is
unimportant. It certainly is. But the post to which I responded made it
sound as if knowledge of C++ inside and out, even of the name of its
inventor, was key. It isn't. I know, and I forgot. And it hasn't affected
my performance in the least.

JAB

 

[John A. Byerly]

I consider a candidate who has not read any C++ or programming books to
be quite weak: Apparently not trying to improve, somewhat out of touch,
probably a "coder" instead of a "software engineer." I believe that our
profession requires continuing study.

Reading books is the only way to learn? It is a shame if you really believe
that to be the case. I hardly read at all, but I observe and explore a lot.
That is how I learn.

It is not a reason to terminate an interview but it will have a strong
effect on evaluating suitability and potential salary.

What a shame!

JAB

 

[Andre Kostur]

Reading books is the only way to learn? It is a shame if you really
believe that to be the case. I hardly read at all, but I observe and
explore a lot. That is how I learn.

No, but I would expect a potential candidate to elaborate on how they
perform their continuing study. What books do they read? Any trade
journals? Seminars?

 

[Victor Bazarov]

Reading books is the only way to learn?

Why fall into extremes? No, it isn't (and who said it was?) But
learning from books is the most effective way. Why would anybody in
their right mind not use the most effective way of doing something?

It is a shame if you really
believe that to be the case. I hardly read at all, but I observe and
explore a lot. That is how I learn.

And you waste a lot of your time. Supplement your exploration with
reading books and you're going to get much more done. Besides, by
following the paths already laid by others you're going to more much
smoother towards your goals. Also, information available in books
is usually structured better and layered for easier consumption than
anything you can simply observe.

What a shame!

You keep saying that. Why? Books are the most concentrated method
of delivering knowledge (aside from attending a class, where you'd
be given books to read anyway). If one for whatever reason discounts
books as the primary source of information, he's definitely confused
and I'd rather not hire a confused individual. Let them clear their
confusions first.

V

 

[Ian Collins]

Thanks for the link. I read it. Okay, skimmed it. And yes, I practice it.
I just didn't know what it was called.

Have you been programming in total isolation?

 

[Victor Bazarov]

IMHO there are plenty of other resources than books that can teach you
the very same techniques.

I really don't see the point insisting on _books_ as long as one
learns.

Nobody is insisting on anything (except John A. Byerly, who seems
to insist that books are unnecessary). Please feel free to learn
without reading books. If you can achieve the same result as
somebody who does read books, all the power to you. I'm yet to
meet somebody who managed to learn [programming] without books.

Undoubtedly there are activities fluency in which can be attained
by other means. Walking comes to mind.

V

 

[Andre Kostur]

Of the names you mention, I know only one. I probably know the
techniques they propose, but not the name. Isn't the technique more
important anyway?

They talk about a whole bunch of stuff. Sutter and Meyers talk about a
lot of good stuff (more than I can get into in a newsgroup post).
Josuttis has a good reference manual, and Alexandrescu does really good
stuff with templates. All of them are worth studying. I'd really
recommend getting the books from the library or something to at least
skim over the table of contents.

Thanks for the link. I read it. Okay, skimmed it. And yes, I
practice it. I just didn't know what it was called.

Excellent. A common set of jargon & terminology is handy to have among
praticioners, just to help with efficient communications.

Actually, it makes him inferior as a developer, period. That concept
is valid in other languages, is it not? This is true with a lot of
concepts. That is why I think that focusing on the nitty-gritty of
C++, especially early in the interview process, is a mistake.

Offhand I thought that RAII had problems being implemented in something
like Java since it doesn't have deterministic destructors (as far as I
know... but I only claim passing familiarity with Java). So if one is
intervewing a developer who has predominantly worked in Java, being weak
in RAII (or at least to my understanding of Java's capabilities) doesn't
make them necessarily a poor developer.... just a weaker C++ developer.

Other than the fact that it is unintelligible, you mean? Who writes
stuff like this? I would think the interviewer should be trying to
weed out people who write this kind of code, rather than select people
to write it!

This is a relatively common example code for illustration the admonishion
"A variable may only be modified once between sequence points.". There
is only only sequence point in that line of code, but i is modified 3
times, which invokes undefined behaviour. (But I do agree. That is
horrific code...)

Early on in my career, I encountered people who would proudly boast
writing a whole program on one line in C++. Even cited that ability
as a strength (in programming skill, and in the C++ language for
allowing it). What nonsense! The true skill is to write functional,
maintainable, usable, and in a lot of cases, extensible code that
solves the problem. In whatever language. Too many times, these
things are sacrificed at the expense of whims of language wizards who
code for their own edification.

I assure you... I don't advocate actually writing that sort of code.
However it serves as an example of undefined behaviour.

How do you gauge this? As I said in another post, I don't read much.
I explore a lot. But I am never asked what applications I have
written on my own time. I am only asked what books I have read.

Hence the last question. I'd start asking about books and trade
magazines, but if those questions don't pan out, I'd continue with the
open-ended question of how the person keeps up their skillset.

 

[Noah Roberts]

I tend to phrase that a little differently, but same idea. Looking for
answers such as Andrei Alexandrescu, Scott Meyers, Nikolai Josuttis, Herb
Sutter. These guys have some good techinques to know. But if the prospect
doesn't know their names, it's not an immediate rejection, but does weigh
into the decision making process.

I don't think knowing their names is that important. That they read is
and I have found that seems to be on the rare side
unfortunately...something I don't really understand, but there it is.
I think the concepts are more important. Of equal import are names
such as Martin and Fowler but again, the concepts are more important
than knowing the names. A person could have read all their books and
not know the names. I wouldn't give much weight to this.

BTW, you misspelled Nicolai.

 

[John A. Byerly]

IMHO there are plenty of other resources than books that can teach you
the very same techniques.

I really don't see the point insisting on _books_ as long as one
learns.

Nobody is insisting on anything (except John A. Byerly, who seems
to insist that books are unnecessary). Please feel free to learn
without reading books. If you can achieve the same result as
somebody who does read books, all the power to you. I'm yet to
meet somebody who managed to learn [programming] without books.

In the future, please allow me to insist for myself. I am certainly not
insisting that books are unnecessary. My point is this: You will not
impress me by listing the books you have read. Because simply reading books
does not a programmer make. If you disagree with this, then I would think
you should be happy hiring a well-read high school grad for a senior-level
position. No? Then why do you insist that books are the only way to learn
(as long as we are putting words in each other mouths)?

I have a very good friend who is a voracious reader. It has only increased
my respect for him. But I have also seen what he can do. This is in
contrast with another guy with whom I worked who was quick to tell me all
about the books he read, and belittled my experience because it did not
include a large library. This person was nowhere near the developer my
friend is. But he sure read a bunch of books. He is even in the
acknowledgements of one.

My original point was that the interviewer should not focus only on the
latest books the candidate has read. There are many talented developers who
simply do not read much, developers who are as passionate as anyone about
what they do.

Honestly, whenever I hear someone brag about the number of books they have
read, it makes me suspicious. In my experience, they are attempting to hide
a deficiency in their abilities.

JAB

 

[John A. Byerly]

Why fall into extremes? No, it isn't (and who said it was?) But
learning from books is the most effective way. Why would anybody in
their right mind not use the most effective way of doing something?

Now who is falling into extremes? Learning from books is the most effective
way for you. Not for me. It wasn't in high school, college, post grad
work, or now. Actually, the most effective way for me to learn was to
teach. I never really understood calculus until I tutored a high school
student. But short of tutoring, experience has been my best teacher.

And you waste a lot of your time.

Excuse me, do I know you? How in the world can you make that statement?

Supplement your exploration with
reading books and you're going to get much more done.

Actually, the reverse is true. I supplement my experience with a
well-placed book. Much more effective.

Besides, by
following the paths already laid by others you're going to more much
smoother towards your goals.

The path taken by the author was (supposedly) the best way for the author to
learn the subject. It may not be the best way for me to learn it.

Also, information available in books
is usually structured better and layered for easier consumption than
anything you can simply observe.

How in the world did you come to that conclusion?? If that is the case, why
are there a multitude of books written on the same subject. Every author
has a different perspective on the topic, which is subject to his
experience.

By the way, when I asked how the authors learned the subject, I think it was
you who responded that they invented the stuff. Please resolve that
statement with the fact that I can find 100 books on C++ programming. I
think it is more correct that the authors are writing about their
experience. They may present a new perspective, but only a fraction of
books actually contain a new invention.

You keep saying that. Why? Books are the most concentrated method
of delivering knowledge (aside from attending a class, where you'd
be given books to read anyway). If one for whatever reason discounts
books as the primary source of information, he's definitely confused
and I'd rather not hire a confused individual. Let them clear their
confusions first.

Books are a source of information, primary for some, secondary for others.

JAB