C++ Interviews

Reading this book will surely give your C++ career a kick-start, but employers will want you to prove yourself before they offer the big bucks. Interview methodologies vary from company to company, yet many aspects of technical interviews are predictable. A thorough interviewer will want to test your basic coding skills, your debugging skills, your design and style skills, and your problem-solving skills. The set of questions you might be asked is quite large. In this appendix, you’ll read about some of the different types of questions you may encounter and the best tactics for landing that high-paying C++ programming job you’re after.

This appendix iterates through all chapters of the book, discussing the aspects of each chapter that are likely to come up in an interview situation. Each section also includes a discussion of the types of questions that could be designed to test those skills, and the best ways to deal with those questions.

CHAPTER 1: A CRASH COURSE IN C++ AND THE STANDARD LIBRARY

A technical interview will often include some basic C++ questions to weed out the candidates who put C++ on their résumé simply because they’ve heard of the language. These questions might be asked during a phone screen, when a developer or recruiter calls you before bringing you in for an in-person interview. They could also be asked via e-mail or in person. When answering these questions, remember that the interviewer is just trying to establish that you’ve actually learned and used C++. You generally don’t need to get every detail right to earn high marks.

Things to Remember

• Use of functions
• Uniform initialization
• Basic use of modules
• Use of the standard named module std (C++23)
• How to print text to the screen using the modern std::print() and println() functions (C++23)
• How to print text to the screen using std::cout
• Use of namespaces and nested namespaces
• Language basics, such as loop syntax, including the range-based for loop, conditional statements, the conditional operator, and variables
• Use of the three-way comparison operator
• Enumerations
• The difference between the stack and the free store
• The many uses of const
• What pointers and references are and their differences
• The need for references to be bound to a variable when they are declared and that the binding cannot be changed
• The advantages of pass-by-reference over pass-by-value
• Structured bindings
• The auto keyword, and its use with structured bindings and to deduce the type of an expression or a function’s return type
• Basic use of Standard Library containers such as std::array and vector
• Using std::pair and optional
• How type aliases and typedefs work
• The general idea behind attributes

Types of Questions

Basic C++ questions will often come in the form of a vocabulary test. The interviewer may ask you to define C++ terms, such as auto or enum class. She may be looking for the textbook answer, but you can often score extra points by giving sample usage or extra detail. For example, when asked to define the auto keyword, you can score extra points by not only explaining the use of auto to define variables, but also its use with function return type deduction and structured bindings.

The other form that basic C++ competence questions can take is a short program that you write in front of the interviewer. An interviewer may give you a warm-up question, such as, “Write Hello, World in C++.” When you get a seemingly simple question like this, make sure that you score all the extra points you can by showing that you are namespace-savvy and up-to-date with the latest standards; i.e., you use the modern std::print() and println() functions instead of the C-style printf() function, and you know that a single import of std gives access to the entire Standard Library. However, upgrading a code base with every new C++ standard takes time, so a lot of companies don’t always use the latest C++ standard. That means you still need to know how to do things using older standards. For the “Hello, World” program, you should also demonstrate that you can write it using std::cout and #include instead of std::println() and import.

Asking a candidate to define const is a classic C++ interview question. The keyword provides a sliding scale with which an interviewer can assess an answer. For example, a fair candidate will talk about const variables. A good candidate will explain const member functions and pass-by-reference-to-const and explain why this can be more efficient than pass-by-value. A great candidate might talk about the relationship of const to thread-safety (discussed in Chapter 27, “Multithreaded Programming with C++”), show how to define static const data members (discussed in Chapter 9, “Mastering Classes and Objects”), or differentiate const from constexpr (see Chapter 9).

Certain topics described in this chapter also come in find-the-bug type problems. Be on the lookout for misuse of references. For example, imagine a class that contains a reference as a data member:

class Gwenyth
{
    private:
        int& m_caversham;
};
int main()
{
    Gwenyth g;
}

The statement in main() won’t compile, and the compiler will spit out an error saying that it attempts to reference a deleted function. Because m_caversham is a reference, it needs to be bound to a variable when the class is constructed. The compiler-generated default constructor cannot do that, so the compiler implicitly deletes the default constructor of Gwenyth. You need to provide a constructor and initialize the reference in the constructor initializer. The class could take the variable to be referenced as a parameter to the constructor:

class Gwenyth
{
    public:
        explicit Gwenyth(int& i) : m_caversham { i } { }
    private:
        int& m_caversham;
};

CHAPTERS 2 AND 21: WORKING WITH STRINGS AND STRING VIEWS, AND STRING LOCALIZATION AND REGULAR EXPRESSIONS

Strings are important and are used in almost every kind of application. An interviewer will most likely ask at least one question related to string handling in C++.

Things to Remember

• The std::string and string_view classes
• To prefer const string& or string as function return type instead of string_view
• Differences between the C++ std::string class and C-style (char*) strings, including why C-style strings should be avoided
• Conversion of strings to numeric types such as integers and floating-point numbers, and vice versa
• String formatting using std::format()
• String printing using std::print() and println() (C++23)
• How to format and print entire ranges at once (C++23)
• Raw string literals
• The importance of localization
• Ideas behind Unicode
• The high-level concepts of locales and facets
• What regular expressions are

Types of Questions

An interviewer could ask you to explain how you can append two strings together. With this question, the interviewer wants to find out whether you are thinking as a C++ programmer or as a C programmer. If you get such a question, you should explain the std::string class and show how to use it to append two strings. It’s also worth mentioning that the string class handles all memory management for you automatically, and contrasting this to C-style strings.

Most interviewers won’t ask specific details about localization. If you do receive a question about your experience with localization, be sure to mention the importance of considering worldwide use from the beginning of the project.

You might also be asked about the general idea behind locales and facets. Most likely, you will not have to explain the exact syntax, but you should explain that they allow you to format text and numbers according to the rules of a certain language or country.

You might get a question about Unicode, but almost certainly it will be a question to explain the ideas and the basic concepts behind Unicode instead of implementation details. So, make sure you understand the high-level concepts of Unicode and that you can explain their use in the context of localization. You should also know about the different options for encoding Unicode characters, such as UTF-8 and UTF-16, without specific details.

As discussed in Chapter 21, regular expressions can have a daunting syntax. It is unlikely that an interviewer will ask you about little details of regular expressions. However, you should be able to explain the concept of regular expressions and what kind of string manipulations you can do with them.

CHAPTER 3: CODING WITH STYLE

Anybody who’s coded in the professional world has had a co-worker who writes messy code. That is something companies don’t want, so interviewers sometimes attempt to determine a candidate’s style skills.

Things to Remember

• Style matters, even during interview questions that aren’t explicitly style related.
• Well-written code doesn’t need extensive comments.
• Comments can be used to convey meta information.
• Decomposition is the practice of breaking up code into smaller pieces.
• Refactoring is the act of restructuring your code, for example to clean up previously written code.
• Naming techniques are important, so pay attention to how you name your variables, classes, and so on.

Types of Questions

Style questions can come in a few different forms. A friend of mine was once asked to write the code for a relatively complex algorithm on a whiteboard. As soon as he wrote the first variable name, the 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 to give your opinions on style.

You need to be careful when a potential employer asks you to submit a code sample. 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. If the potential employer doesn’t specify the program, you could 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.

If you have documentation that you have written and that can be released, meaning it is not confidential, use it to show your skills to communicate; it will give you extra points. Websites you have built or maintained, and articles you have submitted to places like Stack Overflow (stackoverflow.com), CodeGuru (codeguru.com), CodeProject (codeproject.com), and so on, are useful. This tells the interviewer that you can not only write code, but also communicate to others how to use that code effectively.

If you are contributing to active open-source projects, for example on GitHub (github.com), you can score extra points. Even better would be if you have your own open-source project that you actively maintain. That’s the perfect opportunity to show off your coding style and your communication skills. Profile pages on websites such as GitHub are taken as part of your résumé by certain employers.

CHAPTER 4: DESIGNING PROFESSIONAL C++ PROGRAMS

Your interviewer will want to make sure that in addition to knowing the C++ language, you are skilled at applying it. You might not be asked a design question explicitly, but good interviewers have a variety of techniques to sneak design into other questions, as you’ll see.

A potential employer will also want to know that you’re able to work with code that you didn’t write yourself. If you’ve listed third-party libraries on your résumé, then you should be prepared to answer questions about them. If you didn’t list specific libraries, a general understanding of the importance of libraries will probably suffice.

Things to Remember

• Design is subjective. Be prepared to defend design decisions you make during the interview.
• Before the interview, recall the details of a design you’ve done in the past in case you are asked for an example.
• Be prepared to sketch out a design visually, including class hierarchies.
• Be prepared to tout the benefits and disadvantages of code reuse.
• Understand the concept of libraries.
• Know the tradeoffs between building from scratch and reusing existing code.
• Know the basics of big-O notation, or at least remember that O(n log n) is better than O(n2).
• Understand the functionality that is included in the C++ Standard Library.
• Know the high-level definition of design patterns.

Types of Questions

Design questions are hard for an interviewer to come up with; any program that you could design in an interview setting is probably too simple to demonstrate real-world design skills. Design questions may come in a fuzzier form, such as “Tell me the steps in designing a good program” or “Explain the fundamental rule of code reuse.” They can also be less explicit. When discussing your previous job, the interviewer may ask, “Can you explain the design of that project to me?” Be careful not to expose intellectual property from your previous jobs, though.

If the interviewer is asking you about a specific library, he will probably focus on the high-level aspects of the library as opposed to technical specifics. For example, you may be asked to explain what the strengths and weaknesses of the Standard Library are from a library design point of view. The best candidates talk about the Standard Library’s breadth and standardization as strengths and its sometimes-complex usage as a drawback.

You may also be asked a design question that initially doesn’t sound as if it’s related to libraries. For example, the interviewer could ask how you would go about creating an application that downloads MP3 music from the web and plays it on a local computer. This question isn’t explicitly related to libraries, but that’s what it’s getting at; the question is really asking about process.

You should begin by talking about how you would gather requirements and do initial prototypes. Because the question mentions two specific technologies, the interviewer would like to know how you would deal with them. This is where libraries come into play. If you tell the interviewer that you would write your own web classes and MP3-playing code, you won’t fail the test, but you will be challenged to justify the time and expense of reinventing these tools.

A better answer is to say that you would survey existing libraries that perform web and MP3 functionality to see if one exists that suits the project. You might want to name some technologies that you would start with, such as libcurl (curl.haxx.se) for web retrieval in Linux or the Windows Media library for music playback in Windows.

Mentioning some websites with free libraries, and some ideas of what those websites provide, might also get you extra points. Some examples are codeguru.com and codeproject.com for Windows libraries, boost.org and github.com for platform-independent C++ libraries, and so on. Giving examples of some of the licenses that are available for open-source software, such as the GNU General Public License, Boost Software License, Creative Commons license, MIT license, OpenBSD license, and so on, might score you extra credit.

CHAPTER 5: DESIGNING WITH CLASSES

Object-oriented design questions are used to weed out C programmers who merely know what a class is, from C++ programmers who actually use the object-oriented features of the language. Interviewers don’t take anything for granted; even if you’ve been using object-oriented languages for years, they may still want to see evidence that you understand the methodology.

Things to Remember

• The differences between the procedural and object-oriented paradigms
• The difference between a class and an object
• Expressing classes in terms of components, properties, and behaviors
• Is-a and has-a relationships
• The tradeoffs involved in multiple inheritance

Types of Questions

There are typically two ways to ask object-oriented design questions: you can be asked to define an object-oriented concept, or you can be asked to sketch out an object-oriented hierarchy. The former is pretty straightforward. Remember that examples might earn you extra credit.

If you’re asked to sketch out an object-oriented hierarchy, the interviewer will usually provide a simple application, such as a card game, for which you should design a class hierarchy. Interviewers often ask design questions about games because those are applications with which most people are already familiar. They also help lighten the mood a bit when compared to questions about things like database implementations. The hierarchy you generate will, of course, vary based on the game or application they are asking you to design. Here are some points to consider:

• The interviewer wants to see your thought process. It is very important to think aloud, brainstorm, and engage the interviewer in a discussion. Don’t be afraid to erase and go in a different direction!
• The interviewer may assume that you are familiar with the application. If you’ve never heard of blackjack and you get a question about it, ask the interviewer to clarify or change the question.
• Unless the interviewer gives you a specific format to use when describing the hierarchy, it’s recommended that your class diagrams take the form of inheritance trees with rough lists of member functions and data members for each class.
• You may have to defend your design or revise it to take added requirements into consideration. Try to gauge whether the interviewer sees actual flaws in your design, or whether she just wants to put you on the defensive to see your skills of persuasion.

CHAPTER 6: DESIGNING FOR REUSE

Interviewers rarely ask questions about designing reusable code. This omission is unfortunate because having programmers on staff who can write only single-purpose code can be detrimental to a programming organization. Occasionally, you’ll find a company that is savvy on code reuse and asks about it in their interviews. Such a question is an indication that it might be a good company to work for.

Things to Remember

• The principle of abstraction
• The creation of subsystems and class hierarchies
• The general rules for good interface design, which are interfaces with no implementation details and no public data members
• When to use templates for polymorphism and when to use inheritance

Types of Questions

The interviewer might ask you to explain the principle of abstraction and its benefits and to give some concrete examples.

Questions about reuse will almost certainly be about previous projects on which you have worked. For example, if you worked at a company that produced both consumer and professional video-editing applications, the interviewer may ask how code was shared between the two applications. Even if you aren’t explicitly asked about code reuse, you might be able to sneak it in. When you’re describing some of your past work, tell the interviewer if the modules you wrote were used in other projects. Even when answering apparently straight coding questions, make sure to consider and mention the interfaces involved. As always, be careful not to expose intellectual property from your previous jobs, though.

CHAPTER 7: MEMORY MANAGEMENT

You can be sure that an interviewer will ask you some questions related to memory management, including your knowledge of smart pointers. Besides smart pointers, you will also get more low-level questions. The goal is to determine whether the object-oriented aspects of C++ have distanced you too much from the underlying implementation details. Memory management questions will give you a chance to prove that you know what’s really going on.

Things to Remember

• Know how to draw the stack and the free store; this can help you understand what’s going on.
• Avoid using low-level memory allocation and deallocation functions. In modern C++, there should be no calls to new, delete, new[], delete[], malloc(), free(), and so on. Instead, use smart pointers.
• Understand smart pointers; use std::unique_ptr by default, shared_ptr for shared ownership.
• Use std::make_unique() to create a unique_ptr.
• Use std::make_shared() to create a shared_ptr.
• Never use auto_ptr; it has been removed since C++17.
• If you do need to use low-level memory allocation functions, use new, delete, new[], and delete[], never malloc() and free().
• If you have an array of pointers to objects, you still need to allocate memory for each individual pointer and delete the memory—the array allocation syntax doesn’t take care of pointers.
• Be aware of the existence of memory allocation problem detectors, such as Valgrind, to expose memory problems.

Types of Questions

Find-the-bug questions often contain memory issues, such as double deletion, new/delete/new[]/delete[] mix-up, and memory leaks. When you are tracing through code that makes heavy use of pointers and arrays, you should draw and update the state of the memory as you process each line of code.

Another good way to find out if a candidate understands memory is to ask how pointers and arrays differ. At this point, the question might catch you off guard for a moment. If that’s the case, skim Chapter 7 again for the discussion on pointers and arrays.

When answering questions about memory allocation, it’s always a good idea to mention the concept of smart pointers and their benefits for automatically cleaning up memory and other resources. You should also mention that it’s much better to use Standard Library containers, such as std::vector, instead of C-style arrays, because the Standard Library containers handle memory management for you automatically.

CHAPTERS 8 AND 9: GAINING PROFICIENCY WITH CLASSES AND OBJECTS, AND MASTERING CLASSES AND OBJECTS

There is no limit 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 member functions and data members.
• The use of the this pointer.
• How name resolution works.
• Object creation and destruction, both on the stack and the free store.
• Cases when the compiler generates a constructor for you.
• Constructor initializers.
• Copy constructors and assignment operators.
• Delegating constructors.
• The mutable keyword.
• Member function overloading and default arguments.
• const members.
• Friend classes and member functions.
• Managing dynamically allocated memory in classes.
• static member functions and data members.
• Inline member functions and the fact that the inline keyword is just a hint for the compiler, which can ignore the hint.
• The key idea of separating interface and implementation classes, which says that interfaces should only contain public member functions, should be as stable as possible, and should not contain any data members or private/protected member functions. Thus, interfaces can remain stable while implementations are free to change under them.
• In-class member initializers.
• Explicitly defaulted and deleted special member functions.
• The difference between rvalues and lvalues.
• Rvalue references.
• Move semantics with move constructors and move assignment operators.
• The copy-and-swap idiom and what it is used for.
• The rule of zero versus the rule of five.
• Basic operator overloading syntax.
• The three-way comparison operator for classes.
• What explicit object parameters are (C++23).
• What constexpr and consteval functions and classes are.

Types of Questions

Questions such as “What does the keyword mutable mean?” are great for phone screening. A recruiter may have a list of C++ terms and will move candidates to the next stage of the process based on the number of terms that they get right. You might not know all of the terms 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.

The find-the-bug style of questions 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 several 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 are not recommended. For example, you wouldn’t use C-style character arrays; you would use std::string instead.
• 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();
        void turtle(int i = 7, int j);
    protected:
        double fjord(double val);
        int fjord(double val);
        int param;
        double* m_graphicDimension;
};

Buggy::Buggy(int param)
{
    param = param;
    m_graphicDimension = new double;
}

Buggy::˜Buggy()
{
}

double Buggy::fjord(double val)
{
    return val * param;
}

int Buggy::fjord(double val)
{
    return (int)fjord(val);
}

void Buggy::turtle(int i, int j)
{
    cout << "i is " << i << ", j is " << j << endl;
}

Take a careful look at the code, and then consult the following improved version:

import std; // Import the Standard Library functionality.

class Buggy final // Mark as final, or provide a virtual destructor.
{
    public: // These should most likely be public.
        explicit Buggy(int param);  // Constructor should be explicit.

        // Destructor not necessary as there's nothing to clean up.

        void turtle(int i, int j); // Only last parameters can have defaults.
    private: // Use private by default.
        // int version won't compile. Overloaded member functions
        // cannot differ only in return type.
        double fjord(double val);
        int m_param; // Data member naming.
        double m_graphicDimension; // Use value semantics!
};

Buggy::Buggy(int param)
    : m_param{ param } // Prefer using constructor initializer.
{
}

void Buggy::turtle(int i, int j)
{
    // Namespaces + use std::println().
    std::println("i is {}, j is {}", i, j);
}

double Buggy::fjord(double val)
{
    return val * m_param; // Changed data member name.
}

You should explain why you changed m_graphicDimension from a double* pointer to a double value. If you do need to use pointers, you should explain why you should never use raw pointers that represent ownership but smart pointers instead.

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 write derived classes without looking it up in a book.

Things to Remember

• The syntax for inheritance
• The difference between private and protected from the derived class’s point of view
• Member function overriding and virtual
• The difference between overloading, overriding, and hiding
• The reason why base-class destructors should be virtual
• Chained constructors
• The ins and outs of upcasting and downcasting
• The different types of casts in C++
• The principle of polymorphism
• Pure virtual member functions and abstract base classes
• Multiple inheritance
• Run-time type information (RTTI)
• Inherited constructors
• The final keyword on classes
• The override and final keywords on member functions

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 member functions virtual. If you mark all member functions virtual, be prepared to justify that decision. You should be able to explain what virtual means and how it works. Also, don’t forget the public keyword before the name of the parent class in the derived class definition (for example, class Derived : public Base). It’s unlikely that you’ll be asked to perform nonpublic inheritance during an interview.

More challenging inheritance questions have to do with the relationship between a base class and a derived class. Be sure you know how the different access levels work, especially the difference between private and protected. Remind yourself of the phenomenon known as slicing, when certain types of casts cause a class to lose its derived class information.

CHAPTER 11: MODULES, HEADER FILES, AND MISCELLANEOUS TOPICS

This chapter is mostly focused on modules, but it also discusses header files, linkage, feature test macros for core language features, the static keyword, C-style variable-length argument lists, and preprocessor macros.

Things to Remember

• The many uses of static
• What modules are and why their use is preferred over using header files
• Header file syntax and #include
• The concept of preprocessor macros and their disadvantages
• The use of #define and #pragma once
• The different types of linkage: no linkage, external linkage, internal linkage, and module linkage
• Why you shouldn’t use C-style variable-length argument lists

Types of Questions

Asking a candidate to define static is a classic C++ interview question. Because the keyword has several uses, it can be used to assess the breadth of your knowledge. You should definitely talk about static member functions and static data members and give good examples of them. You’ll get extra points if you also explain static linkage and static function-local variables.

Modules are the perfect way to make code reusable and bolster clear separation of responsibilities. Be sure to know how to consume modules and how to author a basic module.

CHAPTERS 12 AND 26: WRITING GENERIC CODE WITH TEMPLATES, AND ADVANCED TEMPLATES

As one of the most arcane parts of C++, templates are a good way for interviewers to separate the C++ novices from the pros. While most interviewers will forgive you for not remembering some of the advanced template syntax, you should go into an interview knowing the basics.

Things to Remember

• How to use a class or function template
• How to write a simple class or function template
• The abbreviated function template syntax
• Function template argument deduction
• Class template argument deduction (CTAD)
• Alias templates and why using is better than typedef
• The ideas behind concepts, and their basic use
• What variadic templates and fold-expressions are
• The ideas behind template metaprogramming
• Type traits and what they can be used for

Types of Questions

Many interview questions start out with a simple problem and gradually add complexity. Often, interviewers have an endless amount of complexity that they are prepared to add, and they simply want to see how far you get. For example, an interviewer might begin a problem by asking you to create a class that provides sequential access to a fixed number of ints. Next, the class will need to grow to accommodate an arbitrary number of elements. Then, it will need to work with arbitrary data types, which is where templates come in. From there, the interviewer could take the problem in a number of directions, asking you to use operator overloading to provide array-like syntax or continuing down the template path by asking you to provide a default type for the template type parameters or to put type constraints on them. However, most interviewers understand that the template syntax can be difficult and will forgive you for syntactical errors.

The interviewer might ask you high-level questions related to template metaprogramming to find out whether you have heard about it. While explaining, you could give a small example such as calculating the factorial of a number at compile time. Don’t worry if the syntax is not entirely correct. As long as you explain what it is supposed to do, you should be fine.

CHAPTER 13: DEMYSTIFYING C++ I/O

If you’re interviewing for a job writing GUI applications, you probably won’t get too many questions about I/O streams, because GUI applications tend to use other mechanisms for I/O. However, streams can come up in other problems, and as a standard part of C++, they are fair game as far as the interviewer is concerned.

Things to Remember

• The definition of a stream
• Basic input and output using streams
• The concept of manipulators
• Types of streams (console, file, string, and so on)
• Error-handling techniques
• The existence of a standard filesystem API

Types of Questions

I/O may come up in the context of any question. For example, the interviewer could ask you to read in a file containing test scores and put them in a vector. This question tests basic C++, Standard Library, and I/O skills.

CHAPTER 14: HANDLING ERRORS

Managers sometimes shy away from hiring recent graduates or novice programmers for vital (and high-paying) jobs because it is assumed that they don’t write production-quality code. You can prove to an interviewer that your code won’t keel over randomly by demonstrating your error-handling skills during an interview.

Things to Remember

• Syntax of exceptions
• Catching exceptions as references-to-const
• Why hierarchies of exceptions are preferable to a few generic ones
• The basics of how stack unwinding works when an exception gets thrown
• How to handle errors in constructors and destructors
• How smart pointers help to avoid memory leaks when exceptions are thrown
• The std::source:location class as a replacement for certain C-style preprocessor macros
• The std::stacktrace class to get a stack trace at any moment during the execution of a program and to inspect individual stack frames (C++23)

Types of Questions

Be prepared to discuss error handling if the interviewer brings it up. But don’t try to shoehorn error handling into the discussion yourself and force the interviewer to talk about it if they’re really trying to focus the interview on something else, like data structures or algorithms.

Interviewers might ask you about different error handling strategies. Additionally, you might be asked to give a high-level overview of how stack unwinding works when an exception is thrown, without implementation details.

Of course, not all programmers appreciate exceptions. Some may even have a bias against them for performance reasons. If the interviewer asks you to do something without exceptions, you’ll have to revert to traditional nullptr checks and error codes.

Knowledge of the source:location and stacktrace classes and their most important use cases will score you extra points.

An interviewer can also ask you whether you would avoid using exceptions because of their performance impact. You should explain that with modern compilers, throwing an exception might possibly have a performance penalty, but just having code that can handle potential exceptions has close to zero performance penalty.

CHAPTER 15: OVERLOADING C++ OPERATORS

It’s possible, though somewhat unlikely, that you will have to perform something more difficult than a simple operator overload during an interview. Some interviewers like to have an advanced question on hand that they don’t really expect anybody to answer correctly. The intricacies of operator overloading make great, nearly impossible questions because few programmers get the syntax right without looking it up. That means it’s a great area to review before an interview.

Things to Remember

• Overloading stream operators, because they are commonly overloaded operators, and are conceptually unique
• What a functor is (a callable object) and how to create one
• What the benefit is of making a class’s function call operator static (C++23)
• Choosing between a member function operator and a global function
• How some operators can be expressed in terms of others (for example, operator<= can be written by negating the result of operator>)
• The multidimensional subscript operator and what it can be used for (C++23)
• The fact that you can define your own user-defined literals, but without the syntactical details

Types of Questions

It’s impossible to predict the exact questions that you’ll get, but the number of operators is finite. As long as you’ve seen an example of overloading each operator that makes sense to overload, you’ll do fine!

One possible question is to write a simple class, for instance, a Fraction class to store mathematical fractions. The interviewer might then ask you to add support for some operators such as addition and subtraction. If you’re unsure how to add or subtract fractions, ask the interviewer as that’s not the point of the question; the point is writing overloaded operators.

Besides asking you to implement an overloaded operator, you could be asked high-level questions about operator overloading. A find-the-bug question could contain an operator that is overloaded to do something that is conceptually wrong for that particular operator. In addition to syntax, keep the use cases and theory of operator overloading in mind.

CHAPTERS 16–20 AND 25: THE STANDARD LIBRARY

As you’ve seen, certain aspects of the Standard Library can be difficult to work with. Few interviewers would expect you to recite the details of Standard Library classes unless you claim to be a Standard Library expert. If you know that the job you’re interviewing for makes heavy use of the Standard Library, you might want to write some Standard Library code the day before to refresh your memory. Otherwise, recalling the high-level design of the Standard Library and its basic usage should suffice.

Things to Remember

• The different types of containers and their relationships with iterators
• Use of vector, which is the most frequently used Standard Library class
• The span class and why you should use it
• What an mdspan is (C++23)
• Use of associative containers, such as map
• The differences between associative containers, e.g., map, unordered associative containers, e.g., unordered_map, and flat associative container adapters (C++23), e.g., flat_map
• How to work with function pointers, function objects (callable objects), and lambda expressions
• What transparent operator functors are
• The purpose of Standard Library algorithms and some of the built-in algorithms
• The use of lambda expressions in combination with Standard Library algorithms
• The remove-erase idiom
• The fact that a lot of Standard Library algorithms have an option to execute them in parallel to improve performance
• The ways in which you can extend the Standard Library (details are most likely unnecessary)
• What ranges, projections, views, and range factories are
• The expressiveness of the Ranges library
• Your own opinions about the Standard Library

Types of Questions

If interviewers are dead set on asking detailed Standard Library questions, there really are no bounds to the types of questions they could ask. If you’re feeling uncertain about syntax, though, you should state the obvious during the interview: “In real life, of course, I’d look that up in Professional C++, but I’m pretty sure it works like this …” At least that way, the interviewer is reminded that he should forgive the details, as long as you get the basic idea right.

High-level questions about the Standard Library are often used to gauge how much you’ve used the Standard Library without making you recall all the details. For example, casual users of the Standard Library may be familiar with associative and non-associative containers. A slightly more advanced user would be able to define an iterator, describe how iterators work with containers, and describe the remove-erase idiom. Other high-level questions could ask you about your experience with Standard Library algorithms, or whether you’ve customized the Standard Library. An interviewer might also gauge your knowledge about function objects and lambda expressions, and their use with Standard Library algorithms. When talking about lambda expressions, you can score extra points if you explain the use of the auto keyword to define generic lambda expressions.

You might also be asked to explain the benefits of using the ranges library. Remember, it basically allows you to write code that describes what you want to do instead of how you want to do it.

CHAPTER 22: DATE AND TIME UTILITIES

The C++ Standard Library provides the chrono library, which allows you to work with dates and times. It is unlikely that an interviewer will ask detailed questions about this functionality, but she might gauge whether you’ve heard about this part of the Standard Library.

Things to Remember

• Compile-time rational numbers
• What durations, clocks, and time points are
• What dates and calendars are
• The possibility of converting dates and times between different time zones

Types of Questions

Instead of asking you any detailed questions about the chrono library, an interviewer might explain a problem involving dates and times and ask you how you would tackle it. If you explain that you would implement your own classes to work with dates and times, be prepared to explain why. A better approach is to explain that you would use the functionality provided by the chrono library. Remember, reuse of code is an important programming paradigm.

CHAPTER 23: RANDOM NUMBER FACILITIES

Generating good random numbers in software is a complex topic, and interviewers know this. They will not ask any syntactical details about it, but you need to know the basics and concepts behind the <random> library, which is part of the C++ Standard Library.

Things to Remember

• Using the <random> library as the preferred technique of generating random numbers
• How random number engines and distributions work together to generate random numbers
• What seeding means and why it is important

Types of Questions

An interviewer might show you a piece of code that is using the C functions rand() and srand() to generate random numbers and ask you to comment on the code snippet. You should explain that those C functions are not recommended anymore and why it’s better to use the functionality provided by <random>.

In the context of questions related to random numbers, it is important to explain the differences between true random numbers and pseudorandom numbers. You will score extra points if you explain that you can use a random_device to generate a truly random seed for a pseudorandom number generator, as well as why you would use a pseudorandom number generator instead of just using a random_device all the time.

CHAPTER 24: ADDITIONAL VOCABULARY TYPES

This chapter discusses a few additional vocabulary types provided by the C++ Standard Library. An interviewer might touch on a few of these topics to get an idea of the breadth of your Standard Library knowledge.

Things to Remember

• The std::variant and any vocabulary data types, and how they complement optional
• std::tuple as a generalization of pair
• What the std::expected vocabulary type is and how to use it (C++23)
• What monadic operations for optional and expected are (C++23)

Types of Questions

You might be asked what the use cases are for the variant, any, and tuple data structures. While explaining variant and any, you can also contrast these with the optional vocabulary type from Chapter 1.

You will impress the interviewer if you can explain the C++23 expected data type and show its use with a small example.

CHAPTER 27: MULTITHREADED PROGRAMMING WITH C++

Almost any system, from servers to laptops and even cellphones, has processors with multiple cores these days. Multithreaded programming is crucial to harness the power of all those cores. An interviewer might ask you a couple of multithreading questions. C++ includes a standard threading support library, so it’s a good idea to know how it works.

Things to Remember

• What race conditions and deadlocks are and how to prevent them
• std::jthread to spawn threads, and why it can be better than using std::thread
• The atomic types and atomic operations
• The concept of mutual exclusion, including the use of the different mutex and lock classes, to provide synchronization between threads
• Condition variables and how to use them to signal other threads
• The concepts of semaphores, latches, and barriers
• Futures and promises
• Copying and rethrowing of exceptions across thread boundaries
• What coroutines are, including a high-level overview of how they work
• The standard std::generator awaitable (C++23)

Types of Questions

Multithreaded programming is a complicated subject, so you don’t need to expect detailed questions, unless you are interviewing for a specific multithreaded programming position.

Instead, an interviewer might ask you to explain the different kinds of problems you can encounter with multithreaded code: problems such as race conditions, deadlocks, and tearing. She might ask you to explain the need for atomic types and atomic operations. You may also be asked to explain the general concepts behind multithreaded programming. This is a broad question, but it allows the interviewer to get an idea of your multithreading knowledge. Explaining the concepts of mutexes, semaphores, latches, and barriers will earn you extra points. You can also mention that a lot of the Standard Library algorithms have an option to run in parallel to improve their performance.

Writing your own coroutines is complicated, but since C++23, the Standard Library comes with a standard std::generator type. If you can explain how generator works with a small example, you will earn extra points.

CHAPTER 28: MAXIMIZING SOFTWARE ENGINEERING METHODS

You should be suspicious if you go through the complete interview process with a company and the interviewers do not ask any process questions—it may mean that they don’t have any process in place or that they don’t care about it. Alternatively, they might not want to scare you away with their process behemoth.

Having a well defined process in place is important. Similarly, version control should be mandatory for any project of any size.

Most of the time, you’ll get a chance to ask questions regarding the company. I suggest you consider asking about the company’s engineering processes and version control solution as one of your standard questions.

Things to Remember

• Traditional life-cycle models
• The trade-offs of different models
• The main principles behind Extreme Programming
• Scrum as an example of an agile process
• Other processes you have used in the past
• What version control is

Types of Questions

The most common question you’ll be asked is to describe the process that your previous employer used. Be careful, though, not to disclose any confidential information. When answering, you should mention what worked well and what failed, but try not to denounce any particular methodology. The methodology you criticize could be the one that your interviewer uses.

Almost every candidate is listing Scrum/Agile as a skill these days. If the interviewer asks you about Scrum, she probably doesn’t want you to simply recite the textbook definition—the interviewer knows that you can read the table of contents of a Scrum book. Instead, pick a few ideas from Scrum that you find appealing. Explain each one to the interviewer along with your thoughts on it. Try to engage the interviewer in a conversation, proceeding in a direction in which she is interested based on the cues that she gives.

If you get a question regarding version control, it will most likely be a high-level question. You should explain why it should be used and what its benefits are. You could also explain the difference between local, client/server, and distributed solutions, and possibly explain how version control was implemented by your previous employer.

CHAPTER 29: WRITING EFFICIENT C++

Efficiency questions are quite common in interviews because many organizations are facing scalability issues with their code and need programmers who are savvy about performance.

Things to Remember

• Language-level efficiency is important, but it can only go so far; design-level choices are ultimately much more significant.
• Algorithms with bad complexity, such as quadratic algorithms, should be avoided.
• Reference parameters are more efficient because they avoid copying.
• Object pools can help avoid the overhead of creating and destroying objects.
• Profiling is vital to determine which operations are really consuming the most time, so you don’t waste effort trying to optimize code that is not a performance bottleneck.

Types of Questions

Often, the interviewer will use her own product as an example to drive efficiency questions. Sometimes the interviewer will describe an older design and some performance-related symptoms she experienced. The candidate is supposed to come up with a new design that alleviates the problem. Unfortunately, there is a major problem with a question like this: what are the odds that you’re going to come up with the same solution that the company did when the problem was actually solved? Because the odds are slim, you need to be extra careful to justify your designs. You might not come up with the actual solution, but you could still have an answer that is correct or even better than the company’s newer design.

Other types of efficiency questions may ask you to tweak some C++ code for performance or iterate on an algorithm. For example, the interviewer could show you code that contains extraneous copies or inefficient loops.

The interviewer might also ask you for a high-level description of profiling tools (such as gprof or Visual C++), what their benefits are, and why you should use them.

CHAPTER 30: BECOMING ADEPT AT TESTING

Potential employers value strong testing abilities. Because your résumé probably doesn’t indicate your testing skills, unless you have explicit quality assurance (QA) experience, you might face interview questions about testing.

Things to Remember

• The difference between black-box and white-box testing
• The concept of unit testing, integration testing, system testing, and regression testing
• Techniques for higher-level tests
• Testing and QA environments in which you’ve worked before: what worked and what didn’t?

Types of Questions

An interviewer could ask you to write some tests during the interview, but it’s unlikely that a program presented during an interview would contain the depth necessary for interesting tests. It’s more likely that you will be asked high-level testing questions. Be prepared to describe how testing was done at your last job and what you liked and didn’t like about it. Again, be careful not to disclose any confidential information. After you’ve answered the interviewer’s questions about testing, a good question for you to ask the interviewer is to ask how testing is done at their company. It might start a conversation about testing and give you a better idea of the environment at your potential job.

CHAPTER 31: CONQUERING DEBUGGING

Engineering organizations look for candidates who are able to debug their own code as well as code that they’ve never seen before. Technical interviews often attempt to size up your debugging muscles.

Things to Remember

• Debugging doesn’t start when bugs appear; you should instrument your code ahead of time, so you’re prepared for bugs when they arrive.
• Logs and debuggers are your best tools.
• You should know how to use assertions.
• The symptoms that a bug exhibits may appear to be unrelated to the actual cause.
• Object diagrams can be helpful in debugging, especially during an interview.

Types of Questions

During an interview, you might be challenged with an obscure debugging problem. Remember that the process is the most important thing, and the interviewer probably knows that. Even if you don’t find the bug during the interview, make sure that the interviewer knows what steps you would go through to track it down. If the interviewer hands you a function and tells you that it crashes during execution, she should award you just as many points or even more if you properly discuss the sequence of steps to find the bug, as if you find the bug right away.

CHAPTER 32: INCORPORATING DESIGN TECHNIQUES AND FRAMEWORKS

Each of the techniques presented in Chapter 32 makes a fine interview question. Rather than repeat what you already read in the chapter, I suggest that you skim over Chapter 32 prior to an interview to make sure that you are able to understand each of the techniques.

If you are being interviewed for a GUI-based job, you should know about the existence of frameworks such as MFC, Qt, and possibly others.

CHAPTER 33: APPLYING DESIGN PATTERNS

Because design patterns are popular in the professional world (many candidates even list them as skills), it’s likely that you’ll encounter an interviewer who wants you to explain a pattern, give a use case for a pattern, or implement a pattern.

Things to Remember

• The basic idea of a pattern as a reusable object-oriented design concept
• The patterns you have read about in this book, as well as others that you’ve used in your work
• The fact that you and your interviewer may use different words for the same pattern, given that there are hundreds of patterns with often-conflicting names

Types of Questions

Answering questions about design patterns is usually a walk in the park, unless the interviewer expects you to know the details of every single pattern known to humankind. Luckily, most interviewers who appreciate design patterns will just want to chat with you about them and get your opinions. After all, looking up concepts in a book or online instead of memorizing them is a good pattern in itself.

CHAPTER 34: DEVELOPING CROSS-PLATFORM AND CROSS-LANGUAGE APPLICATIONS

Few programmers submit résumés that list only a single language or technology, and few large applications rely on only a single language or technology. Even if you’re only interviewing for a C++ position, the interviewer may still ask questions about other languages, especially as they relate to C++.

Things to Remember

• The ways in which platforms can differ (architecture, integer sizes, and so on)
• The fact that you should try to find a cross-platform library to accomplish a certain task, instead of starting to implement the functionality yourself for different kinds of platforms
• The fact that C++ can interoperate with other languages, such as C#, Java, scripting languages, and so on

Types of Questions

The most popular cross-language question is to compare and contrast two different languages. You should avoid saying only positive or negative things about a particular language, even if you really love or hate that language. The interviewer wants to know that you are able to see trade-offs and make decisions based on them.

Cross-platform questions are more likely to be asked while discussing previous work. If your résumé indicates that you once wrote C++ applications that ran on a custom hardware platform, you should be prepared to talk about the compiler you used and the challenges of that platform.