Strcpy blues

Where do you set the notch for a C programmer declaring “good C/C++” in his/her resume? It’s “developpa” hiring time again at the company I work for, so I am conducting some technical interviews with junior programmers to find the best candidate.
Before this point we had many internal discussion about having the candidate to perform some coding during the interview or not, to the point I got a reputation of being the Bad One – a sort of a Torquemada of the C Language.
In fact I fairly agree with many others that if you are looking for a programmer (i.e. someone who writes code for a living) you should see how he/she actually writes code. Some colleagues felt embarrassed in asking this to an experienced programmer or were afraid of intimidating excessively the candidate.
Then we had a couple of hires whose skill claims weren’t exactly matched by their real skills, therefore we eventually agreed on proposing the candidate to write a few lines of code then using those as a base for more profound questions.
With the best intentions of making the candidate at ease we asked to write the implementation of a short standard library function, say memcpy, strcpy or strcmp. In order to have a common base for evaluation I focused my demand on strcpy.
Such functions should be famous enough not to scare anyone and easy enough to implement so that further discussion (improvement, optimization, pitfalls…) could be tackled to know better the candidate’s attitudes.

Well, I was wrong.

The first problem my candidates encountered was well before the implementation, in fact they had trouble in the definition of a string in C. Most of them opted for a function signature employing an undefined type “String”, someone opted for a pair of square brackets at the right end of the name.
That sheds an unsettling light on the candidate’s knowledge both of the standard library and the C string concept.
Anyway I didn’t say anything and left candidates going on. For all of them it was clear that a loop was needed, but most of them panicked on the string length. As I expected from the string type, no one of them was sure about what a C string is. One said that he expected a string length somewhere. So I pointed them in the right direction stating that a C string is more a convention that a language type, consisting in a sequence of characters terminated by 0.
Most of the candidates were able to use the array notation with an assignment. Notably one candidate failed to write the assignment operator pretending that it was the double equal (he said this twice, he was pretty emotional, but I am afraid he’s really convinced).
No one of them attempted the pointer way with post-increment. I am not a fan of the pointer notation, sometimes it is clearer, sometimes is not. For simple cases like this the optimizer is able to convert the source into the most optimized version. But I expected that a candidate could go the pointer way in order to impress the interviewer. Anyway it wasn’t the case. Worse a candidate had a doubt whether he should dereference or not the pointer with the array notation.
Well, we were looking for a junior C programmer, but I didn’t expect such low score in the C knowledge. Maybe in their experience they hadn’t chance of using the string part of the C standard library, but I would say that pointers were quite stranger to most of them.
Given the technical interview I underwent in my career and the technical interview I read about in Internet forums, I would say that in other countries programmers (even junior) are better prepared, while in Italy it seldom occurs in interviews to require the candidate to write lines of code.
I quite agree that the knowledge of the specific language is not everything for evaluating a candidate, but I think it says a lot about his/her interests, will to learn and to work as a programmer. For these reasons I tried to be flexible, ignoring details of C syntax rather focusing on the problem solving abilities. But the lack of a starting point (the code implementation) seriously hampered my options.
Also I recall that when I left the school anyone in my university friends circle could craft a strcpy in a matter of minutes (I would add blindfolded, but that would be an exaggeration). So have the times changed? Or it is my memories going wild? Should I lower the notch or changing entirely the kind of interview questions?

From the management point of view (as they told me) a junior programmer is expected not to be fluent in a programming language and I expect that a junior has no experience of medium/large code base and software engineering can be just abstract rubbish (at best) to him/her. So I have been instructed to look for learning skill and passion. I found a hard time in formulating questions for evaluating the learning skill of a candidate (well I had some ideas about mazes, food and electrical shocks, but they told me that can’t be done with humans… even if they are junior programmers).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.