What makes a good C/C++ programmer?

[E. Robert Tisdale]

What makes a good C/C++ programmer?

Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?
There isn't much difference in productivity, for example,
between a C/C++ programmers with a few weeks of experience
and a C/C++ programmer with years of experience.

You don't really need to understand the subtle details
or use the obscure features of either language
to write useful programs in your application domain.
Expert C and C++ programmers
are only marginally more effective than rookies.
What really helps is understanding the problem domain
and experience solving problems in that domain with computers.

So what should employers look for when hiring C/C++ programmers?
Well, it probably doesn't help to ask them questions
about syntax errors that compiler diagnostics would catch.
Nor would it help to query them about subtle details
or obscure features. The best thing to do is to ask them
for examples of programs that they have written
or to write a simple program for your application domain.

 

[Mario Rosario]

Are you a rookie or an expert C++ programmer?

Laughing,
Mario

 

[shez]

What makes a good C/C++ programmer?

Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?
There isn't much difference in productivity, for example,
between a C/C++ programmers with a few weeks of experience
and a C/C++ programmer with years of experience.

You don't really need to understand the subtle details
or use the obscure features of either language
to write useful programs in your application domain.
Expert C and C++ programmers
are only marginally more effective than rookies.
What really helps is understanding the problem domain
and experience solving problems in that domain with computers.

So what should employers look for when hiring C/C++ programmers?
Well, it probably doesn't help to ask them questions
about syntax errors that compiler diagnostics would catch.
Nor would it help to query them about subtle details
or obscure features. The best thing to do is to ask them
for examples of programs that they have written
or to write a simple program for your application domain.

Thanks for the tip.

-shez-

 

[Richard Tobin]

What makes a good C/C++ programmer?

Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?

[...]

Another rejection letter?

-- Richard

 

[David White]

So what should employers look for when hiring C/C++ programmers?
Well, it probably doesn't help to ask them questions
about syntax errors that compiler diagnostics would catch.
Nor would it help to query them about subtle details
or obscure features. The best thing to do is to ask them
for examples of programs that they have written
or to write a simple program for your application domain.

Yes, at our place we don't place a lot of emphasis on C++ knowledge when
interviewing for a C++ programming position. We are more interested in an
aptitude for programming in general and an ability to solve problems. Such a
person is unlikely to have difficulty picking up C++.

DW

 

[E. Robert Tisdale]

What makes a good C/C++ programmer?

Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?

[...]

Another rejection letter?

I used to have a file folder labeled "DROP DEAD".
It got to be quite large before I went to work.
I kept them for some time before discarding them.
Now, I keep my [pay stubs] in that file folder.
Persistence pays. It is a much larger file now.

I have been programming for a long time
and I've been programming in C++
almost as long as Bjarne Stroustrup.
I never applied for a job as a programmer
and I never intended to learn as much as I know
about C++ or any other computer programming language.

 

[Gianni Mariani]

What makes a good C/C++ programmer?

Knowledge of the language, algorithms, class design, math, logic and
experience.

Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?
There isn't much difference in productivity, for example,
between a C/C++ programmers with a few weeks of experience
and a C/C++ programmer with years of experience.

I doubt that.

You don't really need to understand the subtle details
or use the obscure features of either language
to write useful programs in your application domain.
Expert C and C++ programmers
are only marginally more effective than rookies.
What really helps is understanding the problem domain
and experience solving problems in that domain with computers.

So what should employers look for when hiring C/C++ programmers?
Well, it probably doesn't help to ask them questions
about syntax errors that compiler diagnostics would catch.
Nor would it help to query them about subtle details
or obscure features. The best thing to do is to ask them
for examples of programs that they have written
or to write a simple program for your application domain.

That's not always possible.

What do you think of these questions ?

a) Write a template class that counts the number of set bits in a
constant and provides a constant for any integer type.

template <typename T, T val>
struct NumBitsSet
{
static const unsigned m_value = *****; //what goes where the ***** is?
};

b) Explain what is wrong with this code:

#include "at_thread.h" // Austria C++ thread interface
#include <iostream>

class A
: public at::Task
{
public:

A()
{
Start();
}
};

class B
: public A
{
virtual void Work()
{
std::cout << "Hello World\n";
}
};

int main()
{
B b;
}

c) Explain what is happening and wrong with the following code and how
you would resolve this.

#include "at_lifetime.h" // Austria C++ smart pointer interface

struct M;

struct N
: at:trTarget_Basic
{
at:tr<M *> m;
};

struct M
: at:trTarget_Basic
{
void Do() {};
at:tr<N *> n;
};

at:tr<M *> F()
{
at:tr<M *> m=new M;
m->n = new N;
m->n->m = m;
return m;
}

int main()
{
F()->Do();
}

 

[Martin Ambuhl]

Are you a rookie or an expert C++ programmer?

ERT is comp.lang.c's most persistent troll. If he has as little
knowledge of C++ as he has of C, then he is quite experienced at writing
bad code.

 

[Alf P. Steinbach]

* Gianni Mariani:

What do you think of these questions ?

a) Write a template class that counts the number of set bits in a
constant and provides a constant for any integer type.

template <typename T, T val>
struct NumBitsSet
{
static const unsigned m_value = *****; //what goes where the ***** is?
};

Such templates are not very portable. A compiler may have a very strict
limit on recursive template instantion. Also, it's IME very seldom
a good idea to mix bit-level and high-level abstractions tools.

b) Explain what is wrong with this code:

From a technical point of view, that it does not #include the

#include "at_thread.h" // Austria C++ thread interface
#include <iostream>

class A
: public at::Task
{
public:

A()
{
Start();
}
};

class B
: public A
{
virtual void Work()
{
std::cout << "Hello World\n";
}
};

Presumably the interviewer wants the interviewee to answer "Gosh oh my,
that won't call B::Work", which would be introducing a number of
unwarranted assumptions. If that's the sought answer, then only by
demonstrating lack of clear thinking can the interviewee manage to give
an _impression_ of expertise. Ouch.

c) Explain what is happening and wrong with the following code and how
you would resolve this.

#include "at_lifetime.h" // Austria C++ smart pointer interface

struct M;

struct N
: at:trTarget_Basic
{
at:tr<M *> m;
};

Is the purpose of the question to ascertain whether the interviewee
knows the "Austria C++ smart pointer interface"?

Without knowing that it's impossible to say what could be wrong.

If OTOH e.g. std::auto_ptr was used that way there would be a clear
problem, and a number of clear solutions such as boost::shared_ptr.

The main thing undeniably wrong with the above code is a design level
issue: that class N lacks a constructor and offers a public data member.

Fix that.

 

[Alan Krueger]

You don't really need to understand the subtle details
or use the obscure features of either language
to write useful programs in your application domain.
Expert C and C++ programmers
are only marginally more effective than rookies.

You can cross a minefield much more quickly if you don't know it's a
minefield.

I've had to track down enough errors introduced by developers who knew
just enough C/C++ (particularly the latter) to be dangerous that I don't
buy this.

What really helps is understanding the problem domain
and experience solving problems in that domain with computers.

This is like claiming the same for creating legal contracts. If you
don't know the details of proper legalese, you may not be writing what
you intend, even if you have domain knowledge.

 

[E. Robert Tisdale]

Gianni Mariani wrote:

[snip]

What do you think of these questions?
[snip]

b) Explain what is wrong with this code:

austria-0.8/job> cat main.cc
#include <iostream>
#include "at_lifetime.h" // Austria C++ smart pointer interface

struct M; // foraward declaration

struct N: at:trTarget_Basic {
at:tr<M*> m;
};

struct M: at:trTarget_Basic {
at:tr<N*> n;
void Do(void) { std::clog << "M:o(void)" << std::endl; }
};

at:tr<M*> F(void) {
at:tr<M*> m = new M;
m->n = new N;
m->n->m = m;
return m;
}

int main(int argc, char* argv[]) {
F()->Do();
return 0;
}


After removing superfluous semicolons after namespace definitions,

austria-0.8/job> g++ -Wall -Wno-long-long -ansi -pedantic \
-I../src/austria/code -L../src/austria/code/work.gx86 \
-o main main.cc -laustria
austria-0.8/job> ./main
M:o(void)

it compiles and runs without complaint.
You need to explain an "Austria C++ smart pointer".
An astute candidate would *not* assume that it has the usual meaning.
But, if it has the usual meaning
and the candidate is familiar with smart pointers,
then you should expect the candidate to spot the error immediately.

I would say this *is* a good question
because the programmer cannot depend upon the compiler or testing
to reveal the bug. Of course,
we would expect that this bug would manifest itself eventually.

Evidently, smart pointers are important to you
and you should make sure that your programmers understand them.
But smart pointers are *not* a difficult concept to grasp
so any deficiency in understanding them is easily corrected
and I don't think that this question would do very much
to help you decide which candidate is the better C++ programmer.

 

[Erik de Castro Lopo]

What makes a good C/C++ programmer?

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?

Well it wouldn't be the first time you have been wrong.

Anybody who employs a person with poor or non-existant knowledge
of the programming language they will be using has to teach them
that language before they can start anything else.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo (e-mail address removed) (Yes it's valid)
+-----------------------------------------------------------+
"There are only two things wrong with C++: The initial concept and
the implementation." -- Bertrand Meyer

 

[E. Robert Tisdale]

You can cross a minefield much more quickly
if you don't know it's a minefield.

I've had to track down enough errors introduced by developers
who knew just enough C/C++ (particularly the latter) to be dangerous
that I don't buy this.

Besides a lot of very expert professional programmers,
we also have a lot of scientists and engineers
who know just enough about Fortran, C or C++ to be really dangerous.
They write their own codes because it's easier and cheaper
than training a professional programmer in the application domain
and having the professionals write these codes.
I don't know how you end up
tracking down errors introduced by "developers".
It seems to me that they should be tracking down their own errors.
Why do you feel compelled to contribute to their code development.

I don't mind helping and advising other programmers.
But I wish they would come to me sooner rather than later.

 

[E. Robert Tisdale]

Anybody who employs a person with poor or non-existant knowledge
of the programming language they will be using
[must] teach them that language
before they can start anything else.

So employers should select a candidate who is a "quick study?

 

[David White]

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

Yes, a CV that gives the applicant's C/C++ experience always looks
suspicious. It's as though the applicant believes that they are
interchangeable languages or that C experience can be passed off as C++.
They should always be treated separately.

Well it wouldn't be the first time you have been wrong.

Anybody who employs a person with poor or non-existant knowledge
of the programming language they will be using has to teach them
that language before they can start anything else.

Yes, but talented people don't need long to learn it. IMO, someone who's
memorized every nuance of C++ but can't solve the kinds of problems they'll
need to solve isn't going to be as productive after a few weeks as someone
who knows no C++ but is obviously a talented programmer.

DW

 

[Todd Shillam]

You can be a very knowledgeable programmer; however, without imagination I
don't think any programmer can truly be successful.

A good programmer can leverage their knowledge with their creative ability
(imagination if you prefer). Thus, a good programmer has the ability to
foresee how their knowledge can manifest into various actions in a given
environment to resolve problems or make productive change.

Just my two cents,

Todd

 

[David Hilsee]

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

The "/" is typically read as "or." Tisdale was simply commenting on both C
and C++ simultaneously, and that was obvious when you consider the rest of
his post. The "no such language" attack is getting a bit old, so it's best
to reserve it for when it is truly deserved.

 

[Joseph Turian]

ERT,

What makes a good C/C++ programmer?

Shouldn't we first discuss what makes someone a good human being,
before tackling more specific and complicated questions?

Joseph

 

[Gianni Mariani]

* Gianni Mariani:



Such templates are not very portable. A compiler may have a very strict
limit on recursive template instantion. Also, it's IME very seldom
a good idea to mix bit-level and high-level abstractions tools.

There is alot more to it than that.

The actual answer to the question is not as important as the process in
which the candidate goes through.

BTW - these are pre-interview questions.

From a technical point of view, that it does not #include the
header <ostream>, because operator<< is not defined by <iostream>.

I thought it was only std::endl that was not defined in ostream.

Presumably the interviewer wants the interviewee to answer "Gosh oh my,
that won't call B::Work", which would be introducing a number of
unwarranted assumptions. If that's the sought answer, then only by
demonstrating lack of clear thinking can the interviewee manage to give
an _impression_ of expertise. Ouch.

Not quite - you only got 50% of the answer. You got the gimme answer.

Is the purpose of the question to ascertain whether the interviewee
knows the "Austria C++ smart pointer interface"?

No. It's wether they can research it.

Without knowing that it's impossible to say what could be wrong.

If OTOH e.g. std::auto_ptr was used that way there would be a clear
problem, and a number of clear solutions such as boost::shared_ptr.

The main thing undeniably wrong with the above code is a design level
issue: that class N lacks a constructor and offers a public data member.

Fix that.

Describe why you think that is a problem.

BTW - there are still other issues.

The point is, it's a starting point for a dialogue.

 

[Gianni Mariani]

Gianni Mariani wrote: ....


After removing superfluous semicolons after namespace definitions,

austria-0.8/job> g++ -Wall -Wno-long-long -ansi -pedantic \
-I../src/austria/code -L../src/austria/code/work.gx86 \
-o main main.cc -laustria
austria-0.8/job> ./main
M:o(void)

it compiles and runs without complaint.
You need to explain an "Austria C++ smart pointer".
An astute candidate would *not* assume that it has the usual meaning.
But, if it has the usual meaning
and the candidate is familiar with smart pointers,
then you should expect the candidate to spot the error immediately.

Yep. This is a design issue. This should be somthing that someone with
experience should pick up.

I would say this *is* a good question
because the programmer cannot depend upon the compiler or testing
to reveal the bug. Of course,
we would expect that this bug would manifest itself eventually.

Evidently, smart pointers are important to you
and you should make sure that your programmers understand them.
But smart pointers are *not* a difficult concept to grasp
so any deficiency in understanding them is easily corrected
and I don't think that this question would do very much
to help you decide which candidate is the better C++ programmer.

You're right. Smart pointers are somthing that could be picked up
quickly. The point is that the questions were pre-interview, the "take
as long as you like to answer them" type and so if someone decided to,
they could find out with about 5 minutes of google and reading (if not
less).