Is there any way for a C++ programmer with 1,5 years of experience to have no idea that null-terminated strings exist as a concept and are widely used in a variety of applications? Is this a sign that he is potentially a bad hire?
views:
1208answers:
17Is there any way for a C++ programmer with 1,5 years of experience to have no idea that NULL-terminated strings exist as a concept and are widely used in a variety of applications?
No. What have he/she been doing for these 1,5 years?
Is this a sign that he is potentially a bad hire?
Yes. Knowledge of C should be mandatory for a C++ programmer.
What does he use -- std::string only? Does he know about string literals? What is his take on string literals?
There's too little detail to tell you if he's a bad hire, but he sounds like he needs a bit more talking to than most.
NULL-terminated strings don't exist, so I guess he might be a good hire.
Update: null-terminated and terminating '\0' appear in the C++ standard, according to some of the comments. Instead of deleting my answer, I turn it into wiki, to preserve the interesting part of the debate.
not knowing that they exist - a really bad sign hardly using them - IMO not really a bad sign. Back in the days when I was programming C++ I avoided null terminated strings for everyting except for string literals.
std::strings (or CStrings) were used instead.
Is this a sign that he is potentially a bad hire?
Definitely, C++ programmer must understand what happens behind all cool STL stuff.
Unfortunately there are too many substandard C++ programmers on the market.
BTW: The are not NULL terminated, but rather zero terminated.
NUL-terminated strings (aka ASCIIZ) aren't even a C construct, I think a good programmer should at least know there are different ways to store a string (terminating with 0, prefixing with length...).
Perhaps you won't ever need this, but for me it feels like using your computer without ever opening it and have a look what's in there just to understand it a bit better.
I won't say that someone who doesn't know about it is potentially a bad hire, but note that if you use NUL-terminated strings in your project, he'll have to learn the concept and might stumble about the common mistakes in this field (not increasing the array sizes by 1 to store the additional 0 etc.) which a programmer that knows about NUL-terminated string wouldn't.
I'd say it depends on what you want to hire them for, and what their purpose in your organization will be.
Somebody who understands C++ but not C (which is easy to do, nowadays), will fall into this type of category. They can, potentially, be a fine employee. However, I would say this is a warning, so depending on their resume, this would be one mark against them in my book.
However, if they are going to be working on fairly straightforward projects, and not be required to design and develop critical parts of your code base (at least early on), they might be fine.
I would not, however, hire somebody to do design or to work on critical systems who did not understand the basic concepts like this one. Any developer I hire who will be working on C++ projects at a high level needs to understand memory management, basic concepts of C and C++, templates and generic programming, and all of the fundamentals, at least to a reasonable degree, of the language they will be using.
Not understanding the concepts of how string literals work would be a big disadvantage - even if they will be using std::string or the like, I want them to understand how it works underneath, at least to some degree, and also the other options out there. Understanding the concepts helps to understand the rationale behind the newer, nicer technologies, but also to understand the compromises being made when they are used. It also helps to understand the design decisions made there, and apply them to your own projects.
In the work we do at my company, and I guess that is the case for many other places, you must know about NULL-terminated (or zero terminated) strings. Yes, we use C++ and we try to use std::string where we can. But we have code that was developed years ago that uses C-style strings, sprintf and this kind of stuff. Then you have external code and APIs, how can you call even Windows API without knowing about these C concepts?
So will he be a bad hire? Well, what you don't know you can learn... But it is definitely not a good sign.
IMHO, I'd expect a competent programmer to have the basic curiosity to wonder how things like the STL containers actually work. I wouldn't expect them to necessarily be prepared to implement one, mind you.
But the NUL terminated string is a fundamental data type of both C and C++. Given the chance to avoid the messy details with a container is a luxury. You still have to appreciate what the container is doing for you.
Consider the coursework in any C/C++ based undergrad coursework. There has to be a data structures course s/he must have taken and this course must have had an assignment wherein they have to implement a string type from scratch. Obviously, nobody expects all functionality of std::string but they must have implemented a string class and when they did that they must have explored this matter, in depth.
No hire.
It means they have never opened a file forv input or output. The standard library has no means of specifying a file name via a std::string - you have to use a zero-terminated one.
This reminds me of Shlemiel the painter from Joel's post Back to Basics.
People say and do all sorts of weird things while being interviewed. Have you seen this person do any coding?
1.5 years is not very much time, but experience means squat if the hire can't think properly. So I'd note it as a warning flag and dig deeper. If the interviewing stage is over and you have to make a decision, it sounds to me like your answer should be NO HIRE.
I'd say that it depends on what you are looking for. If you're looking for a relatively inexperiences (and therefore presumably cheap) programmer that you can mold to fit your organization, he might be OK. You've just found out that he has no idea how C does things, and that you'll have to explain a whole lot of C concepts to him when they come up.
At this point the important thing is to figure out if he's just uneducated (he's never come across the need before) or if he's he kind of guy who never learns ANYTHING he doesn't immediately need, or if he's an idiot. If #1, then you can consider hiring him, if he knows enough to be useful. If #2 then I'd take a pass, but perhaps you can make use of a 9-5er. If #3, show him the door.
And I wouldn't take not knowing about C stuff TOO seriously, I've met people who've programmed in C for 15 years who didn't know about __FILE__
and __LINE__
. And they were good, they just never came across it before I showed it to them. This guy could be the same way – he's only ever seen the STL way of doing things, so he doesn't know anything else.
Well, I heard from a friend in German SAP they they hired someone as a developer and then later discovered he had always thought 1KB = 1000 Bytes. Looks like they discovered it when he made some kind of bug. They were shocked then moved him to do customer support.
Compared to that, your newly hired developer could be a genius. If seriously, he could have just started making his experience when high-level languages occupied the majority of the market and just didn't skim the era of low-level programming (C++ or something).
Does not necessarily mean he is bad. Just belongs to the new pepsi-generation of developers.
It sounds like this is a programmer who didn't start out as a programmer. I took C++ classes in college and even read a few books on the language. Every book within the first 3 chapters will explain how a string, which is an array of characters, knows that it ends, by using the "/0" identifier. This is basic knowledge of C++.
This programmer sounds like a business user who wanted to cut costs by learning "programming" in order to create software for the company without getting a properly educated and experienced developer.
Sorry if that sounded harsh. I take my profession very seriously and consider it an art form of sorts.
In your hiring decision, you should consider whether or not he will be able to learn the important pieces of information over whether or not he knows them now. A year and a half is hardly any time at all as far as business experience goes. As others have mentioned, dig deeper, try to find the boundaries of his programming knowledge, and try to figure out how hard it will be to push those boundaries outward. This will depend a lot on personal habits and character. If he's a good learner and a good communicator, he's a good hire. If technical learning is beyond him, programming probably isn't the best career for him.