Professional C__ - Marc Gregoire [506]
CHAPTER 26: BECOMING ADEPT AT TESTING
Potential employers value strong testing abilities. Because your resume probably doesn’t indicate your testing skills, unless you have explicit 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, regression testing and writing tests along with code
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. After you answer, this is a good question for you to ask the interviewer. It might start a conversation about testing and give you a better idea of the environment at your potential job.
CHAPTER 27: CONQUERING DEBUGGING
Engineering organizations look for candidates who are able to debug both 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 the bugs when they arrive.
Logs and debuggers are your best tools.
Asserts and the reason why you should avoid the standard assert() macro from How to use the C++11 static asserts 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, he or she should award just as many points to a candidate who properly discusses the sequence of steps to find the bug, as to a candidate who finds it right away. CHAPTER 28: INCORPORATING DESIGN TECHNIQUES AND FRAMEWORKS Each of the techniques presented in Chapter 28 makes a fine interview question. Rather than repeat what you already read in the chapter, we suggest that you skim back 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. CHAPTER 29: APPLYING DESIGN PATTERNS 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. 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 There are hundreds of patterns with often-conflicting names, so you and your interviewer may use different words for the same pattern. 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