Puzzle: How can employer test C++ programming ability?
 

Most of job descriptions include C/C++ programming experience. However, a cpp program includes head/source code. Both of them are large and inconvenient to write or describe in a short time. So, how does the interviewer test the candidate's C++ programming ability?

The interviewer doesn't test for programming ability, objectively that is. His/her entire motivation is political (corporate political) under those circumstances.

A simple phone interview from an experienced programmer and some well asked questions can see right through bogus applicants...

KC

Yeah, I believe experienced programmer can judge bogus applicants at a glance-:).
The questions is: What are instances of those well asked questions?

A warning about phone interviews. You never know who is at the other end. Once interviewing an international candidate for a job we conducted a phone interview only (because of money) and we believe that the person at the other end was a different person, but we had no proof. However we walked away from it much wiser ;)

Graemef: Show us some tips-:)

I've done a lot of technical interviewing, and been interviewed a lot myself.

One good idea is to get your best guys to talk to any prospect. Each of these "best guys" has some aspect of his personality and skill set that cause him to see the world in a particular way. By getting a reasonably broad understanding of the candidate by having him spend a few hours with several people it's extremely unusual to be fooled. Just like open source is usually good source, because of many eyes, this principle applies to most things.

I don't really approve of "testing" people with written tests, so I don't do it. But if that's your thing, debugging a memory leak is a good indicator of whether the guy can solve problems- under pressure. If he can do it sitting in a cube in a new office during interview conditions he'll probably kick a$$ on your staff. Another thing when possible is to ask him to bring source code. A lot of times this is impossible because of non-disclosures (at least in the world I live in) so not being able to do so should not raise any red flags.

When you are looking at a developer, problem solving has many faces. It could be debugging, or choosing the best algorithm given the constraints. Your best guys will be able to ask questions that don't have simple yes/no answers and so you can really understand how the candidate thinks. I could go on and on (and I probably already did :p) but the key is having technical people talk to the guy and not hiring anyone just on the basis of some manager who never coded in his life. Those kind of hires will drag your company down every time.

Some of the places I've been have not hired anyone unless everyone in the group approved. Even the manager couldn't crowbar someone onto the staff unless all the techies were satisifed. And we had some good teamwork because of that.

The last thing I would say is that unless you are very short-sighted, you should be looking for a lot more than "experience." I don't care of a guy has ten years of working as a developer with technology x if he's not passionate about what he does and comes across as not being smart. I'll take a smart guy with no experience who loves coding and wants to learn everything before I'll take someone with experience on paper who doesn't love coding every time. And we've made some real good devs out of the former. I'm not saying experience doesn't count- good experience is better than almost anything. But just because someone survived as a coder doesn't mean much if he doesn't live for coding.

Everyone has their own style. I tend to ask questions to find out what the person is comfortable with and then go into more and more detail until I reach a point where the person doesn't know or is unsure of the answer. For example:

I might start with asking if they could explain to me what they understand OO programming to be. From there I will pick something up, maybe inheritance, maybe polymorphism and follow that with a line of attack. How do you have class inheritance in C++? What is the effect of a protected modifier in inheritance? When would a private modifier be used, as in class B : private class A? When might you have a private constructor? What is the difference between inheritance and association? Essentially their answer will trigger off my next question, sometimes I need to rephrase it so that they understand my question and occasionally I'll go off at a tangent but I want to understand their depth of understanding.

That sounds like a good approach. Another thing I try to do is not to sound like I'm quizzing someone. That usually doesn't work so well. I try to ask questions that make the person show me how he thinks about solving problems. And I can tell from his approach whether or not he knows what he's talking about.

And here is most of the problem of the corporate workplace in a nutshell. Pressure stifles creativity and creativity is definitely needed in programming.

Nothing tricks but read books completely and grasp the principle in practice.

You're right but there are a few different environments: there is R&D where people dream stuff up and then figure out if what they're trying to do is even possible. (I'm talking about heavy-duty software shop- this phase doesn't exist in applications development since applications present organization challenges that are known to be possible to overcome.) This sector is relatively free of pressure in the short term, but they have to deliver prototypes or eventually they won't have jobs.

Then there's development, where good first and second-line managers should keep the heat off the tech staff and be a force-field against management from below. That's probably the hardest job in IT, when done right, and it hardly ever is. There are still schedules to be kept, because the marketing and pubs guys need to have something to do also.

The support guys have to solve the memory leaks under pressure, but the majority of software support organizations are nothing more than glorified telephone operators, so this stuff gets thrown back on the devs. It's counterproductive for everyone. When it's done right, and you have really capable support staff, you will find that the quality of development output is unusually high, as you alluded to the converse in your comment. It's hardly even done right, though, so this is what I was thinking of when I gave the example.

Then again, when some company pays a half million bucks for a piece of software, there is going to be pressure on the whole supply chain, from the worthless sales guy all the way down to the guy who writes the bugfix.

I couldn't agree more. However, I would like to add that: (1) your statement here is proof positive of what I stated above, namely that interviewers are controlled by corporate politics and are not objective; and (2) that the pressure arising from having paid a half million for a piece of software ultimately derives from the people having paid for the software wanting, perhaps even unconsciously, to get revenge for having had to pay. Speaking of revenge, many interviewers, beyond being political, also seek out revenge, and are looking for candidates, who, if hired, would be easy targets to be repeatedly dumped on (yuck!).

No, the way you understand what I said is not what I meant; and, I don't agree with your conclusions:

> (1) namely that interviewers are controlled by corporate
> politics and are not objective;

In companies that I've worked for and with that have been big enough to charge a half million dollars (and sometimes much more) for software, the developers (and even many managers) are very far from corporate politics. These guys are certainly objective, perhaps to a fault; they don't care if the company stays in business another day- all they care about is that they don't have to work with some idiot or do-nothing "developer" who doesn't know or want to learn anything. It's quite interesting and effective that their own selfish concerns actually work towards the greater good which is that when good guys get hired, everybody wins.

I agree that as one proceeds up the ladder politics play an ever-increasing and harmful role, but this does not (at least not in my experience) affect technical staffing in the least. Senior management is most certainly chosen on the basis you mention, but technical staff- I haven't seen it happen.

> (2) that the pressure arising from having paid a half million
> for a piece of software ultimately derives from the people
> having paid for the software wanting, perhaps even
> unconsciously, to get revenge for having had to pay.

Again, no. The people writing the cheques are indeed far removed from the users of the software. The end-users and programmers in the company who bought the product have no idea of the terms under which the applications and software they use were obtained; and they certainly make every effort to establish friendly relations with the support and dev people of their vendors in order that their problems would be handled expeditiously.

I suppose that there are circumstances unlike what I've experienced so perhaps if you have a particular case that you've witnessed you might care to point it out if it bears on the interviewing question.

I don't disagree with you, if what you are trying to bring out is the tremendous pressure and harmful effects of greed in the corporate world as they apply to the software business. I've seen many lives ruined from stress-related illnesses including strokes, heart failure, and all kinds of other woes. But I think in terms of technical staffing, this is a self-healing area, for the reasons I mentioned above. The one pleasant side of all the ugly politics and greed is that the technical people often develop a kind of comeraderie as a result of the awful conditions.