C++ Interviews

interviewer stopped him and told him he passed. The question wasn’t about the algorithm; it was just a red herring to see how well he named his variables. More commonly, you may be asked to submit code that you’ve written or simply to give your opinions on style.

You need to be careful when a potential employer asks you to submit code. You probably cannot legally submit code that you wrote for a previous employer. You also have to find a piece of code that shows off your skills without requiring too much background knowledge. For example, you wouldn’t want to submit your master’s thesis on high-speed image rendering to a company that is interviewing you for a database administration position.

If the company gives you a specific program to write, that’s a perfect opportunity to show off what you’ve learned in this book. How many other candidates will include unit tests with their program or extensive comments? Even if the potential employer doesn’t specify the program, you should consider writing a small program specifically to submit to the company. Instead of selecting some code you’ve already written, start from scratch to produce code that is relevant to the job and highlights good style.

Chapters 8 and 9: Classes and Objects

There are no bounds to the types of questions you can be asked about classes and objects. Some interviewers are syntax-fixated and might throw some complicated code at you. Others are less concerned with the implementation and more interested in your design skills.

Things to Remember

Basic class definition syntax

Access specifiers for methods and data members

The use of the “this” pointer

Object creation and destruction

Cases when the compiler generates a constructor for you

Initializer lists

Copy constructor and assignment operator

The mutable keyword

Method overloading and default parameters

Friend classes

Types of Questions

Questions such as, “What does the keyword mutable mean?” make great phone screening questions. A recruiter may have a list of C++ terms and will move candidates to the next stage of the process based on the number that they get right. You may not know all of the terms that are thrown at you, but keep in mind that other candidates are facing the same questions and it’s one of the few metrics available to a recruiter.

789

Appendix A

The find the bug style of question is popular among interviewers and course instructors alike. You will be presented with some nonsense code and asked to point out its flaws. Interviewers struggle to find quantitative ways to analyze candidates, and this is one of the few ways to do it. In general, your approach should be to read each line of code and voice your concerns, brainstorming aloud. The types of bugs can fall into these categories:

Syntax errors. These are rare — interviewers know you can find compile-time bugs with a compiler.

Memory problems. These include problems such as leaks and double deletion.

“You wouldn’t do that” problems. This category includes things that are technically correct but have an undesirable outcome.

Style errors. Even if the interviewer doesn’t count it as a bug, point out poor comments or variable names.

Here’s a find the bug problem that demonstrates each of these areas:

class Buggy

{

Buggy(int param); ~Buggy();

double fjord(double inVal); int fjord(double inVal);

protected:

void turtle(int i = 7, int j); int param;

double* graphicDimension;

};

Buggy::Buggy(int param)

{

param = param; graphicDimension = new double;

}

Buggy::~Buggy()

{

}

double Buggy::fjord(double inVal)

{

return inVal * param;

}

int Buggy::fjord(double inVal)

{

return (int)fjord(inVal);

}

void Buggy::turtle(int i, int j)

790

C++ Interviews

{

cout << “i is “ << i << “, j is “ << j << endl;

}

Take a careful look at the code, and then consult the following corrected version for the answers:

#include <iostream> // Streams are used in the implementation.

class Buggy

{

public: // These should probably be public or else the class is pretty useless.

Buggy(int inParam); // Parameter naming ~Buggy();

double fjord(double inVal); // int version won’t compile

//(overloaded methods differ only

//in return type). It’s also useless

//because it just returns the argument

//it’s given.

protected:

void turtle(int i, int j); // Only last arguments can have defaults.

int mParam; // Data member naming double* graphicDimension;

};

Buggy::Buggy(int inParam) : mParam(inParam) // Avoid name ambiguity.

{

graphicDimension = new double;

}

Buggy::~Buggy()

{

delete graphicDimension; // Avoid memory leak.

}

Buggy::Buggy(const Buggy& src)

{

graphicDimension = new double; *graphicDimension = *(src.graphicDimension);

}

Buggy& Buggy::operator=(const Buggy& rhs)

{

if (this == &rhs) { return (*this);

}

delete graphicDimension; graphicDimension = new double;

791

Appendix A

*graphicDimension = *(rhs.graphicDimension); return (*this);

}

double Buggy::fjord(double inVal)

{

}

void Buggy::turtle(int i, int j)

{

std::cout << “i is “ << i << “, j is “ << j << std::endl; // Namespaces

}

Chapter 10: Discovering Inheritance

Techniques

Questions about inheritance usually come in the same forms as questions about classes. The interviewer might also ask you to implement a class hierarchy to show that you have worked with C++ enough to subclass without looking it up in a book.

Things to Remember

The syntax for subclassing a class

The difference between private and protected from a subclass point of view

Method overriding and virtual

Chained constructors

The ins and outs of upcasting and downcasting

The principle of polymorphism

Pure virtual methods and abstract base classes

Multiple inheritance

Runtime Type Identification (RTTI)

Types of Questions

Many of the pitfalls in inheritance questions are related to getting the details right. When you are writing a base class, don’t forget to make the methods virtual. If you mark all methods virtual, be prepared to justify that decision. You should be able to explain what virtual means and how it works.

Similarly, don’t forget the public keyword before the name of the parent class in the subclass definition (e.g., class Foo : public Bar). It’s unlikely that you’ll be asked to perform nonpublic inheritance during an interview.

792