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, but 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 the 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.
A technical interview will often include some basic C++ questions to weed out the candidates who put C++ on their resume 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.
for
loop, conditional statements, the conditional operator, and variablesconst
auto
keywordstd::vector
Basic C++ questions will often come in the form of a vocabulary test. The interviewer may ask you to define C++ terms, such as const
or static
. She may be looking for the textbook answer, but you can often score extra points by giving sample usage or extra detail. For example, in addition to saying that one of the uses of const
is to specify that a reference parameter cannot be changed, you can also say that a const
reference is more efficient than a copy when passing an object into a function or method.
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, you use streams instead of printf()
, and you know which standard headers to include.
Strings are very 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++.
std::string
and std::string_view
classesstd::string
class and C-style strings, including why C-style strings should be avoidedAn interviewer could ask you to explain how you can append two strings together. With this question, he wants to find out whether you are thinking as a professional 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 will handle all memory management for you automatically, and contrasting this to C-style strings.
Your interviewer may not ask specifically about localization, but you can show your worldwide interest by using wchar_t
instead of char
during the interview. 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 may also be asked about the general idea behind locales and facets. You probably 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 most likely 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 19, 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.
Anybody who’s coded in the professional world has had a co-worker who codes as if they learned C++ from the back of a cereal box. Nobody wants to work with someone who writes messy code, so interviewers sometimes attempt to determine a candidate’s style skills.
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 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. 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.
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 CodeGuru, CodeProject, and so on, are very useful. This tells the interviewer that you can not only write code, but also communicate to others how to use that code effectively. Of course, having a book title attached to your name is also a big plus.
If you are contributing to active open-source projects, for example on GitHub, you’ll 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 resume by certain employers.
Your interviewer will want to make sure that in addition to knowing the C++ language, you are skilled at applying it. You may 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 specific libraries on your resume, 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.
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 principle of abstraction.” 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 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 www.codeguru.com and www.codeproject.com for Windows libraries; www.boost.org and www.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, CodeGuru license, OpenBSD license, and so on, might score you extra credit.
Object-oriented design questions are used to weed out C programmers who merely know what a reference 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.
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:
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.
public
methods and no implementation detailsQuestions 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.
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.
new
, delete
, new[]
, delete[]
, malloc()
, free()
, and so on. Instead, use smart pointers.std::unique_ptr
by default, shared_ptr
for shared ownership.std::make_unique()
to create an std::unique_ptr
.std::make_shared()
to create an std::shared_ptr
.std::auto_ptr
; it has even been removed from C++17.new
, delete
, new[]
, and delete[]
instead of malloc()
and free()
.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 differences may be so tacit in your mind that the question catches 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 definitely 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.
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.
this
pointermutable
keywordconst
membersstatic
methods and data membersinline
keyword is just a hint for the compiler, which can ignore the hintpublic
methods, should be as stable as possible, and should not contain any data members or private
/protected
methods. Thus, interfaces can remain stable while implementations are free to change under them.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 may 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 these categories.
std::string
instead.Here’s a find-the-bug problem that demonstrates each of these areas:
class Buggy
{
Buggy(int param);
~Buggy();
double fjord(double val);
int fjord(double val);
protected:
void turtle(int i = 7, int j);
int param;
double* mGraphicDimension;
};
Buggy::Buggy(int param)
{
param = param;
mGraphicDimension = 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 corrected version for the answers:
#include <iostream> // Streams are used in the implementation.
#include <memory> // For std::unique_ptr.
class Buggy
{
public: // These should most likely be public.
Buggy(int param);
// Recommended to make destructors virtual. Also, explicitly
// default it, because this class doesn't need to do anything
// in it.
virtual ~Buggy() = default;
// Disallow copy construction and copy assignment operator.
Buggy(const Buggy& src) = delete;
Buggy& operator=(const Buggy& rhs) = delete;
// Explicitly default move constructor and move assignment op.
Buggy(Buggy&& src) noexcept = default;
Buggy& operator=(Buggy&& rhs) noexcept = default;
// int version won't compile. Overloaded
// methods cannot differ only in return type.
double fjord(double val);
private: // Use private by default.
void turtle(int i, int j); // Only last parameters can have defaults.
int mParam; // Data member naming.
std::unique_ptr<double> mGraphicDimension; // Use smart pointers!
};
Buggy::Buggy(int param) // Prefer using ctor initializer
: mParam(param)
, mGraphicDimension(new double)
{
}
double Buggy::fjord(double val)
{
return val * mParam; // Changed data member name.
}
void Buggy::turtle(int i, int j)
{
std::cout << "i is " << i << ", j is " << j << std::endl; // Namespaces.
}
You should explain why you should never use raw pointers that represent ownership, but smart pointers instead. You should also explain why you are explicitly defaulting the move constructor and move assignment operator, and why you opt to delete the copy constructor and copy assignment operator. Explain what impact it would have on the class if you do need to implement a copy constructor and a copy assignment operator.
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.
private
and protected
from a derived class point of viewvirtual
virtual
virtual
methods and abstract base classesfinal
keyword on classesoverride
and final
keywords on methodsMany 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. 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, and 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.
Many interviewers tend to focus on the more obscure cases because that way, experienced C++ programmers can demonstrate that they have conquered the unusual parts of C++. Sometimes interviewers have difficulty coming up with interesting questions and end up asking the most obscure question they can think of.
const
static
typedef
s workAsking a candidate to define const
and static
is a classic C++ interview question. Both keywords provide a sliding scale with which an interviewer can assess an answer. For example, a fair candidate will talk about static
methods and static
data members. A good candidate will give good examples of static
methods and static
data members. A great candidate will also know about static
linkage and static
variables in functions.
The edge cases 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& mCaversham;
};
Because mCaversham
is a reference, it needs to be bound to a variable when the class is constructed. To do that, you’d need to use a constructor initializer. The class could take the variable to be referenced as a parameter to the constructor:
class Gwenyth
{
public:
Gwenyth(int& i);
private:
int& mCaversham;
};
Gwenyth::Gwenyth(int& i) : mCaversham(i)
{
}
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 the interview knowing the basics.
typedef
sMany 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 int
s. Next, the class will need to grow to accommodate an arbitrary-sized array. Then, it will need 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.
Templates are more likely to be employed in the solution of another coding problem than to be asked about explicitly. You should brush up on the basics in case the subject comes up. However, most interviewers understand that the template syntax is difficult, and asking someone to write complex template code in an interview is rather cruel.
The interviewer might ask you high-level questions related to metaprogramming to find out whether or not 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.
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.
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++ skills, basic Standard Library, and basic I/O. Even if I/O is only a small part of the problem you’re working on, be sure to check for errors. If you don’t, you’re giving the interviewer an opportunity to say something negative about your otherwise perfect program.
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.
const
referencessetjmp()
and longjmp()
in C++Interviewers will be on the lookout to see how you report and handle errors. When you are asked to write a piece of code, make sure you implement proper error handling.
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 understand or appreciate exceptions. Some may even have a completely unfounded 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. That would be a good time to demonstrate your knowledge of nothrow
new
.
An interviewer can also ask questions in the form of “Would you use this?” One example question could be, “Would you use setjmp()
/longjmp()
in C++, as they are more efficient than exceptions?” Your answer should be a big no, because setjmp()
/longjmp()
do not work in C++ as they might bypass scoped destructors. The belief that exceptions have a big performance penalty is a misconception. On modern compilers, just having code that can handle potential exceptions has close to zero performance penalty.
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.
operator<=
can be written by complementing the result of operator>
)Let’s face it: operator overloading questions (other than the simple ones) can be cruel. Anybody who is asking such questions knows this and is going to be impressed when you get it right. It’s impossible to predict the exact question 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!
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.
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.
vector
, which is the most frequently used Standard Library classmap
unordered_map
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 lambda expressions, and their use with Standard Library algorithms.
This chapter describes a number of features and additional libraries from the C++ standard that don’t fit in other chapters, including some new C++17 features. An interviewer might touch on a few of those topics to see whether you are keeping up to date with the latest developments in the C++ world.
<random>
library as the preferred method of generating random numbersstd::optional
valuesstd::variant
and std::any
data typesstd::tuple
as a generalization of std::pair
You shouldn’t expect detailed questions about these topics. However, knowledge of the C++17 std::optional
, variant
, and any
classes will definitely score you extra points. You might also be asked to explain the basic ideas and concepts of the chrono and random number generation libraries, but without going into syntax details. If the interviewer starts focusing on random numbers, it is important to explain the differences between true random numbers and pseudo-random numbers. You should also explain how the random number generation library uses the concepts of generators and distributions.
Multithreaded programming is becoming more and more important with the release of multicore processors for everything from servers to consumer computers. Even smartphones have multicore processors. 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.
std::thread
to spawn threadsMultithreaded programming is a complicated subject, so you don’t need to expect detailed questions, unless you are interviewing for a specific multithreading 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. You may also be asked to explain the general concepts behind multithreaded programming. This is a very broad question, but it allows the interviewer to get an idea of your multithreading knowledge. You can also mention that with C++17, a lot of the Standard Library algorithms have an option to run in parallel.
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 or that they don’t care about it. Alternatively, they might not want to scare you away with their process behemoth. Another important aspect of any development process is Source Code Control.
Most of the time, you’ll get a chance to ask questions regarding the company. I suggest you consider asking about engineering processes and Source Code Control solutions as one of your standard 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 Scum/Agile as a skill these days. If the interviewer asks you about Scrum, he 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 he is interested based on the cues that he gives.
If you get a question regarding Source Code Control, it will most likely be a high-level question. You should explain the general principles behind Source Code Control solutions, mention the fact that there are commercial and free open-source solutions available, and possibly explain how Source Code Control was implemented by your previous employer.
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.
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 may 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 and what their benefits are.
Potential employers value strong testing abilities. Because your resume probably doesn’t indicate your testing skills, unless you have explicit quality assurance (QA) experience, you might face interview questions about testing.
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.
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.
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, he should award you just as many points if you properly discuss the sequence of steps to find the bug, as if you find the bug right away.
Each of the techniques presented in Chapter 28 makes a fine interview question. Rather than repeat what you already read in the chapter, I suggest that you skim over Chapter 28 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.
Because design patterns are very 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.
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.
Few programmers submit resumes 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++.
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 tradeoffs and make decisions based on them.
Cross-platform questions are more likely to be asked while discussing previous work. If your resume 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.