Professional C__ - Marc Gregoire [497]
Things to Remember
The differences between the procedural and object-oriented paradigms
The differences 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 OO 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 they 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. Think aloud, brainstorm, engage the interviewer in a discussion, and 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, we recommend that your class diagrams take the form of inheritance trees with rough lists of methods 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 4: 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 only public methods and no implementation details
When to use templates and when to use inheritance
Types of Questions
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.
CHAPTER 5: CODING WITH STYLE
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.
Things to Remember
Style matters, even during interview questions that aren’t explicitly style related.
Well-written code doesn’t need extensive comments.
Comments