Possible C/C++ Interview Questions

• Why would you use: public/private/protected inheritance?
• Why does the language not define static virtual functions
• Can you make a destructor virtual?
• Why would you want a virtual destructor?
• How would you print the first 10 characters of a string?
• When would you use private inheritance?
• How and why would you implement a '<<' operator for a String class?
• When would you use a reference?
• Why do you want to have virtual member functions? How was "it" done before vmf's came into existence? What was wrong with it?
• Why is "protected" as bad as "public"?
• Give one example use of a static member.
• Why did new (a new expression) have to be a language-level construct while malloc could be a library function?
• What are the advantages and disadvantages of templates over plain old inheritance and heterogenous containers?
• What are the problems with a tree-style hierarchy?
• Why is iostream better than stdio? (There are umpteen reasons, I'm just talking about the type-safe answer...)
• Why would someone want to have RTTI when there are virtual functions? Doesn't that sound contradicting in purpose? Discuss one situation where RTTI could be useful, if you think so.
• Aren't templates glorified macros?
• If you know exceptions, aren't you worried that they could turn out to be the modern "goto"? Why isn't it that bad in C++?
• I would settle for "Why use const instead of #define?" as a question.
• What's the difference between a declaration and a definition?
• What's the difference between a struct and a class?
• Describe for me in 100 words or less how to simulate a virtual table using C.
• What is the difference between delete[] and delete?
• I need to write Wombat objects to an ostream. Describe two ways to accomplish this and one way that won't work.
• What's an initializer list?
• Can you think of a 5 letter word to describe the following?

      class {
        int n;
        public:
        void setN(int);
        int getN() const;
        };

  (One possible answer: "struct"...)

• describe how you extend stdio to access streams that the original implementation never heard of (socket stream, etc.).
• describe how you extend printf to support a new (user defined) type.
• Question: could you describe the system you previously worked on and what your responsiblities were.

  Candidate: normally they get up on the white board and at least attempt to describe this.

  What I am looking for:

  1. Does the candidate have knowledge of design of the system he worked on? (if not be concerned)
  2. Does the candidate understand the design trade offs in the current system he is working on? (if not he won't understand yours either)
• Questions: How did you implement this or that part of the system.
  (Encourage the candidate to draw a high level diagram etc...)

  What I am looking for:

  1. Now is the time to ask questions which expose his knowledge of the language. (if he makes a mistake, don't be overly concerned many folks under the pressure of an interview will screw up)
  2. Does the candidate understand the design tradeoffs for the items he implemented. (This is a great time to discuss inheritance, polymorphism,registration... etc in the context of what he has done and is familiar with.)

  I have found at this point his knowledge and your comfort level will come to the surface. If someone cannot explain what they have worked on and the design trade-offs they might not be the candidate for the job. Also, be real concerned about people who draw great architectual pictures on the board but have not implemented there design. Unless you are going to sell architectures....

• Question:Why would you want a NON-virtual destructor?

  Answer:E.g. in a simple class which only stores a pointer and has no virtual function (e.g. auto_ptr) you might want or need a destructor. Still you want to save the overhead involved when you have any virtual function (the additional memory needed and the indirect call).

  Non-virtual destructors are useful especially for classes which are not intended for derivation and thus have no virtual function: if no class is derived there is no need for a virtual destructor. Although the destructor is non-virtual it is still expected that the destructor of the mostly derived class is called. Since pointers to objects of classes without virtual function are not very useful if they point at a base class, it is unlikely that someone deletes an object through a base class pointer. The opposite is true for classes with virtual destructors.

General hints

Again, be prepared to discuss; there is no one right answer, and you will learn more about the candidate from how he defends his answer than from the answer itself.

BINGO! We tend not to trust a designer/developer who cannot rationally defend a technical position... unless it is an entry level position, where we STILL prefer someone who has strong, well-thought-out technical opinions and are able to defend them.

Discussion of principles, as pointed out elsewhere, should be the primary focus for interview questions. As it turns out, iostreams can be discussed at quite a few levels. Many are stuck on the notion that cout simply replaces printf. Others digress and talk about efficiency, ugly/beautiful syntax, etc., again in the context of file or console I/O. Still others, a precious few, are comfortable with iostream's use as an abstraction, and can talk to its impact on the code that uses them. Fewer still are those who understand and can discuss the important design elements that are evident in the library.

It is not so much iostreams in particular that I am interested in. Rather, I'm hoping for an understanding of design abstractions, coherence and coupling, and everything else you need to consider in putting together a class category that invites re-use. Iostreams is one of the more common libraries that exhibits those qualities.

Like other innocent sounding question, this one is an important barometer on the applicant's level of understanding beyond "C versus C++". Syntax is the least of my concerns. If you understand the library, you won't talk much about printf, and you won't moan "What! Again?!" when asked.