Good morning, Mr. Phelps. The title of this month's column is a typical entry taken from the help-wanted section of the local classified ads. Does it get your attention? Add your address and phone number to the ad, publish it in your local paper, and, depending on where you live, you will get lots of calls and mail. Headhunters will deluge you with resumes, every one of which has the token C++ somewhere near the top of the first page. Programmers who want to reap the harvest of the C++ demand will polish up their resumes to emphasize their C++ exposure and send them in.
Your mission, should you choose to accept it, is to find the best applicant, the one capable of filling the senior C++ programming position, from among the many.
Last month, I listed some questions that you can ask people who apply for a C++ programming job. This month I'll discuss what I think are good answers to those questions. I'm writing this column in June, and the August issue is not on the street yet, so, although I asked for your comments, you haven't had that opportunity. Once again, this technique is my own device, is influenced by my opinions, and needs polish. I'm eager to hear all comments and criticisms.
The questions are in three categories:
The first question you should ask is if the applicant is a devoted reader of this column. If so, you're on your own. The programmer has probably read and memorized these answers by now. Hire 'em. Readers of this column are always a good bet, I bet.
After that, the questions you ask are determined by how applicants represent their knowledge and experience. Anyone who really wants the job tries to match aspects of their experience with an interviewer's questions. It's a natural tendency.
There is an art to resume writing, too, that emphasizes work experiences to fit the job requirements no matter how trivial the experience was. Some headhunters are really good at it. Therefore, don't depend on the details of a resume to properly identify an applicant's abilities. But you do need to make that determination because if you ask too many questions that are beyond the scope of a programmer's knowledge, the interview deteriorates into a confrontation, and the applicant stops wanting to work for you. Consequently, the first three questions are designed to reveal how applicants want their skills to be regarded and should permit you to follow with the appropriate questions chosen from the three groups.
Questions to Qualify an Applicant
Q:Do you have a basic understanding of C and C++ and their similarities and differences?
A:Yes.
If the answer is "yes," proceed and plan to ask all the questions in the first group. If not, the interview for a C++ programmer's job should be over, and you should be talking about other employment opportunities.
Q:Have you participated in the design of C++ classes to support an application's problem domain?
A:Yes or No.
If the answer is "yes," plan to include the questions in the second group. Applicants usually want to describe the details of the systems they have designed. Pay attention if you understand the nature of the application. If not, pretend to pay attention. If they have not actually done any class design, ask if they think they understand it. If so, include the second set of questions.
Q:Do you keep up with what the ANSI C++ Standards committee is doing?
A:Yes or No.
Most people do not. Few people have the time. But occasionally there is that rare soul who reads all the magazines and books, owns a copy of the draft standard, and regularly tracks the C++ news groups on the net. If an applicant claims to be one of them, include the third group of questions in your interrogation.
With your applicants qualified as to how they represent themselves, ask the questions from the chosen three groups. Mix the questions and keep a light but detached attitude going if you can. As soon as you get into details, many people tighten up. They know they are being tested, and as they try to interpret the question to figure out what you want to hear, sometimes they lose sight of the objective, which is to expose what they know rather than what their intuition tells them is an acceptable answer.
Maintain your detachment. Be cordial, but don't get chummy just yet. Remember, if you hire this person to work with you on your typically understaffed, under- budget, overdue C++ programming project, the two of you are going to spend a lot of tense moments together. Observe how the applicant handles the pressure of the interview. If your shop is typical, the two of you will have to routinely deal with a lot more pressure than this.
Don't expect everyone to get everything right (unless they read this column, of course, and fibbed about the first question).
Here's the first group of questions and my opinions about what some acceptable answers would be. These questions do not cover C++ wall-to-wall, of course. I selected them as typical of the kind of knowledge that all C++ programmers should be expected to possess. There are five questions. Three correct answers is a good score.
Q:How do you link a C++ program to C functions?
A:By using the extern "C" linkage specification around the C function declarations.
Programmers should know about mangled function names and type-safe linkages. Then they should explain how the extern "C" linkage specification statement turns that feature off during compilation so that the linker properly links function calls to C functions. Another acceptable answer is "I don't know. We never had to do that." Merely describing what a linker does indicates that the programmer does not understand the issue that underlies the question.
Q:Explain the scope resolution operator.
A:It permits a program to reference an identifier in the global scope that has been hidden by another identifier with the same name in the local scope.
The answer can get complicated. However, it should start with "::". If the programmer is well into the design or use of classes that employ inheritance you might hear a lot about overriding member function overrides to explicitly call a function higher in the hierarchy. That's good to know, but ask specifically about global scope resolution. You're looking for a description of C++'s ability to override the particular C behavior where identifiers in the global scope are always hidden by like identifiers in a local scope.
Q:What are the differences between a C++ struct and C++ class?
A:The default member and base-class access specifiers are different.
This is one of the commonly misunderstood aspects of C++. Believe it or not, many programmers think that a C++ struct is just like a C struct, while a C++ class has inheritance, access specifiers, member functions, overloaded operators, and so on. Some of them have even written books about C++. Actually, the C++ struct has all the features of the class. The only differences are that a struct defaults to public member access and public base-class inheritance, and a class defaults to the private access specifier and private base-class inheritance. Getting this question wrong does not necessarily disqualify an applicant. Getting it right is a definite plus.
Saying, "I don't know" is definitely the wrong answer. I advance an unusual position about this. C++ programmers should at least believe that they know the differences, even when they are wrong about them. Getting it wrong is, therefore, right. You can explain the true difference in the interview and advance the programmer's knowledge. If they disagree vociferously, you have an opportunity to observe how they handle contentious debate when they are wrong and don't know it yet.
Q:How many ways are there to initialize an int with a constant?
A:Two.
There are two formats for initializers in C++ as shown in the example that follows. The first format uses the traditional C notation. The second format uses constructor notation.
int foo = 123;
int bar (123);
It's acceptable when a programmer does not know about the second notation, although they should certainly know about the first one. Many old-timer C programmers who made the switch to C++ never use the second idiom, although some wise heads of C++ profess to prefer it. If your applicant is quick with the right answer, that's a good sign.
Q:How does throwing and catching exceptions differ from using setjmp and longjmp?
A:The throw operation calls the destructors for automatic objects instantiated since entry to the try block.
Exceptions are in the mainstream of C++ now, so most programmers, if they are familiar with setjmp and longjmp, should know the difference. Both idioms return a program from the nested depths of multiple function calls to a defined position higher in the program. The program stack is "unwound" so that the state of the program, with respect to function calls and pushed arguments, is restored as if the calls had not been made. C++ exception handling adds to that behavior the orderly calls to the destructors of automatic objects that were instantiated as the program proceeded from within the try block toward where the throw expression is evaluated.
Applicants might think you want to hear about the notational differences between the two idioms. Let them proceed to explain the syntax of try blocks, catch exception handlers, and throw expressions. Then ask them specifically what happens in a throw that does not happen in a longjmp. Their answer should reflect an understanding of the behavior described in the previous answer.
One valid reason for not knowing about exception handling is that the applicant's experience is exclusively with older C++ compilers that do not implement exception handling. I would prefer that they have at least heard of exception handling, though. Another marginally acceptable reason is that their former supervisors and designers did not mandate and specify the use of exception handling in programs. In that case get the names of those supervisors and designers so that you can decline their applications if they should come a'knocking.
It is not unusual for C and C++ programmers to be unfamiliar with setjmp/
longjmp. Those constructs are not particularly intuitive. A C programmer who has written recursive descent parsing algorithms will certainly be familiar with setjmp/longjmp. Others might not, and that's acceptable. In that case, they won't be able to discuss how setjmp/longjmp differs from C++ exception handling, but let the interview turn into a discussion of C++ exception handling in general. That conversation will reveal a lot about a programmer's understanding of C++.
The second group of questions explores the applicant's knowledge of class design. There are eight questions. Five out of eight is a good score.
Q:What is your reaction to this line of code?
delete this;
A:It's not a good practice.
Many applicants will look at you like you are nuts. They've never heard of this usage, and it's never occurred to them. That's a very good answer. Perhaps they will try to explain the behavior of the statement. Ask them to contemplate its consequences. Two quite acceptable reactions are, "Don't do it," and "Don't do it unless you really know what you are doing and you are a masochist."
A good programmer will insist that you should absolutely never use the statement if the class is to be used by other programmers and instantiated as static, extern, or automatic objects. That much should be obvious.
The code has two built-in pitfalls. First, if it executes in a member function for an extern, static, or automatic object, the program will probably crash as soon as the delete statement executes. There is no portable way for an object to tell that it was instantiated on the heap, so the class cannot assert that its object is properly instantiated. Second, when an object commits suicide this way, the using program might not know about its demise. As far as the instantiating program is concerned, the object remains in scope and continues to exist even though the object did itself in. Subsequent dereferencing of the pointer can and usually does lead to disaster. I think that the language rules should disallow the idiom, but that's another matter.
In More Effective C++ (Addison-Wesley, 1996), Scott Meyers devotes one of his items to "delete this," implying that there are valid applications for the idiom and advancing contrived code kludges to make it seem to work better. A programmer who has read this otherwise very good book might think that the practice is acceptable. Experience leads me to disagree.
Q:What is a default constructor?
A:A constructor that has no arguments.
If you don't code one, the compiler provides one if there are no other constructors. If you are going to instantiate an array of objects of the class, the class must have a default constructor.
Q:What is a conversion constructor?
A:A constructor that accepts one argument of a different type.
The compiler uses this idiom as one way to infer conversion rules for your class. A constructor with more than one argument and with default argument values can be interpreted by the compiler as a conversion constructor when the compiler is looking for an object of your constructor's type and sees an object of the type of the constructor's first argument.
Q:What is the difference between a copy constructor and an overloaded assignment operator?
A:A copy constructor constructs a new object by using the content of the argument object. An overloaded assignment operator assigns the contents of an existing object to another existing object of the same class.
First, the applicant must know that a copy constructor is one that has only one argument of the same type as the constructor. The compiler invokes a copy constructor wherever it needs to make a copy of the object, for example to pass an argument by value. If you do not provide a copy constructor, the compiler creates a member- by-member copy constructor for you.
You can write overloaded assignment operators that take arguments of other classes, but that behavior is usually implemented with implicit conversion constructors. If you do not provide an overloaded assignment operator for the class, the compiler creates a default member- by-member assignment operator.
This discussion is a good place to get into why classes need copy constructors and overloaded assignment operators. If the applicant discusses these with respect to data member pointers that point to dynamically allocated resources, the applicant probably has a good grasp of the problem.
Q:When should you use multiple inheritance?
A:There are three acceptable answers: "Never," "Rarely," and "When the problem domain cannot be accurately modeled any other way."
There are some famous C++ pundits and luminaries who disagree with that third answer, but I will accept it.
Let's digress to consider this issue lest your interview turn into a religious debate. Consider an Asset class, Building class, Vehicle class, and CompanyCar class. All company cars are vehicles. Some company cars are assets because the organizations own them. Others might be leased. Not all assets are vehicles. Money accounts are assets. Real estate holdings are assets. Some real estate holdings are buildings. Not all buildings are assets. Ad infinitum. When you diagram these relationships, it becomes apparent that multiple inheritance is a likely and intuitive way to model this common problem domain. The applicant should understand, however, that multiple inheritance, like a chainsaw, is a useful tool that has its perils, needs respect, and is best avoided except when nothing else will do.
Q:What is a virtual destructor?
A:The simple answer is that a virtual destructor is one that is declared with the virtual attribute.
The behavior of a virtual destructor is what is important. If you destroy an object through a pointer or reference to a base class, and the base-class destructor is not virtual, the derived-class destructors are not executed, and the destruction might not be complete.
Q:Explain the ISA and HASA class relationships. How would you implement each in a class design?
A:A specialized class "is" a specialization of another class and, therefore, has the ISA relationship with the other class. An Employee ISA Person. This relationship is best implemented with inheritance. Employee is derived from Person. A class may have an instance of another class. For example, an employee "has" a salary, therefore the Employee class has the HASA relationship with the Salary class. This relationship is best implemented by embedding an object of the Salary class in the Employee class.
The answer to this question reveals whether the applicant has an understanding of the fundamentals of object- oriented design, which is important to reliable class design.
There are other relationships. The USESA relationship is when one class uses the services of another. The Employee class uses an object (cout) of the ostream class to display the employee's name on the screen, for example. But if the applicant gets ISA and HASA right, you don't need to go any further.
Q:When is a template a better solution than a base class?
A:When you are designing a generic class to contain or otherwise manage objects of other types, when the format and behavior of those other types are unimportant to their containment or management, and particularly when those other types are unknown (thus, the genericity) to the designer of the container or manager class.
Prior to templates, you had to use inheritance; your design might include a generic List container class and an application-specific Employee class. To put employees in a list, a ListedEmployee class is multiply derived (contrived) from the Employee and List classes. These solutions were unwieldy and error-prone. Templates solved that problem.
Questions for ANSI-Knowledgeable Applicants
There are six questions for those who profess knowledge of the progress of the ANSI committee. If you claim to have that much interest in the language, you should know the answers to all these questions.
Q:What is a mutable member?
A:One that can be modified by the class even when the object of the class or the member function doing the modification is const.
Understanding this requirement implies an understanding of C++ const, which many programmers do not have. I have seen large class designs that do not employ the const qualifier anywhere. Some of those designs are my own early C++ efforts. One author suggests that some programmers find const to be such a bother that it is easier to ignore const than to try to use it meaningfully. No wonder many programmers don't understand the power and implications of const. Someone who claims to have enough interest in the language and its evolution to keep pace with the ANSI deliberations should not be ignorant of const, however.
Q:What is an explicit constructor?
A:A conversion constructor declared with the explicit keyword. The compiler does not use an explicit constructor to implement an implied conversion of types. It's purpose is reserved explicitly for construction.
Q:What is the Standard Template Library?
A:A library of container templates approved by the ANSI committee for inclusion in the standard C++ specification.
A programmer who then launches into a discussion of the generic programming model, iterators, allocators, algorithms, and such, has a higher than average understanding of the new technology that STL brings to C++ programming.
Q:Describe run-time type identification.
A:The ability to determine at run time the type of an object by using the typeid operator or the dynamic_cast operator.
Q:What problem does the namespace feature solve?
A:Multiple providers of libraries might use common global identifiers causing a name collision when an application tries to link with two or more such libraries. The namespace feature surrounds a library's external declarations with a unique namespace that eliminates the potential for those collisions.
This solution assumes that two library vendors don't use the same namespace identifier, of course.
Q:Are there any new intrinsic (built-in) data types?
A:Yes. The ANSI committee added the bool intrinsic type and its true and false value keywords.
Other apparent new types (string, complex, and so on) are implemented as classes in the Standard C++ Library rather than as intrinsic types.
Don't ask the applicant to write a program on the spot. Many programmers, myself included, like to ponder a program for a while before writing any code. We would consider a one-hour deadline as a threat. We would be unwilling to let anyone see such a program. You'll get a far better understanding of the applicant's programming skills by asking a former employer about the programmer's ability to write reliable, extensible, maintainable, and timely code that fulfills the user's requirements.
Don't turn these questions into a written test. Some people don't take tests well, particularly when the answers involve narrative text. Many fine programmers are not articulate writers. Others simply hate tests and shut down mentally.
Case in point. My pal Bill Chaney was the highest-time student pilot I ever met. Over a period of several years, he accumulated close to 1000 hours on his student pilot's license. I would have trusted Bill to fly one of my children anywhere in that old Cessna 150 of his, but he was intimidated by the environment of the written examination and could not pass it. There's a happy ending: Several of us ganged up on Bill, crammed him on the written exam, saturated him with a positive mental attitude, and railroaded him through passage of the test. Bill is a legal pilot today.
There's another reason to avoid the written test, one that is driven by social changes in our culture. Last month I said, "For some reason, the Labor Department doesn't want you disqualifying anyone based on their inability to demonstrate that they can do the job." Now I'll expand on that statement, and perhaps stir a bit of controversy.
During my government client's quest for employees, she was questioned by the local EEO representative about her testing practices. They were particularly concerned about whether she was administering, and specifically, grading tests. There is a strong belief that certain segments of our society, like my pal Bill Chaney, do not take tests well, that those segments can be identified by ethnic divisions, and that testing them provides the potential for discrimination. That belief, or the fear of those who hold it, drives official policy.
The EEO is not consistent in this concern. You can't carry passengers in a 747 without proving your experience and ability and passing several of the government's oral and written graded tests. You don't get anywhere near my gall bladder, retirement account, or household wiring without a certificate on the wall proving that you have scored passing grades on a bevy of written tests. The potential to discriminate is overlooked when something important like our lives or our money is at stake.
My parents' generation was the last one that discriminated against ethnic and gender boundaries with the sanction of law to back them up. (My parents didn't do it, but their generation did and the law allowed it.) Many of my generation inherited and retained that bias even when the sanctions were removed through legislation and judicial decree. Most of the newer generation is free of that bias, I hope, at least intellectually if not emotionally. But the swing of the pendulum is not yet dead center. If you administer written tests to programmers, grade those tests, and use those grades to disqualify someone for employment, you might find yourself the object of a discrimination investigation.
So, ask those questions and take notes. But don't write grades on a score sheet. Or, in case you do, there is a device in our office named "Hillary." Get one. (It's also called a shredder.) As usual, if you or any of your interviewers are killed or captured, DDJ will disavow any knowledge of your activities.