Grokking the Object Oriented Design Interview
Vote

0% completed

How to Use This Course

The parts of a case study lesson

Where to stop

Reading the diagrams

Reading the code

The two sections at the end

Practising with a timer

If you are stuck, ask

Key Takeaways

There are two ways to work through twenty two case studies.

The first is to read them. It is comfortable, it is fast, and it produces almost nothing. A finished design always looks obvious once someone has drawn it for you. That feeling is not the same as being able to produce the design under pressure.

The second is to attempt each one first, then compare. It is slower and it feels worse. It is also the only version that changes what you can do in an interview.

This lesson explains how a case study lesson is built. Knowing that, you can choose the second method on purpose instead of the first by accident.

The parts of a case study lesson

Image

Every case study follows that order. Once you have done one, you always know what is coming next. That lets you decide in advance where you will stop and think.

Where to stop

Three stopping points matter most.

Stop after the question. Before reading our requirement list, write your own. Aim for eight to twelve lines, and include a line saying what is out of scope. Then compare. Where your list is shorter than ours, the cause is usually not missing knowledge. It is not asking the interviewer enough questions.

Stop after the requirements. Write down the classes you would create, one line each, with a responsibility sentence for each one. Then read our stage 1 and stage 2 diagrams. Most people find their list is close but two classes short. The two missing ones are usually the same kind: the thing that keeps a record, and the thing that decides a rule.

Stop at each stage of the class diagram. The diagram is revealed in stages on purpose. At the end of each stage, say out loud what you think the next stage has to add. Being wrong here costs you nothing, and it is the fastest way to learn what an experienced designer expects.

Reading the diagrams

Every diagram is drawn in standard UML. The grey boxes in a staged diagram are classes you have already seen. The boxes with the darker outline are the ones this stage adds.

If a symbol is unfamiliar, chapter 2 has one lesson per diagram type. You do not have to read that chapter before the case studies. Many people find it easier to see a symbol in a real design first, then read the lesson about it.

Reading the code

Every case study contains the same program in Python, Java and C++. The three versions are not translations of a general idea. They are the same design, and they print exactly the same output line for line. Each one was compiled and run before it went into the lesson.

Read one language. Reading all three teaches you nothing about design and costs you three times the time.

One habit appears throughout the code and is worth copying in an interview. Time is passed into a method rather than read from a system clock, so the same input always produces the same output. That one choice is what makes a design testable, and interviewers notice it.

The newer designs also count money in whole cents rather than in decimals, which removes every rounding question before it is asked.

The two sections at the end

The patterns in this design. Where a case study uses a named design pattern, the lesson names it and says why it fits. Not every design uses one. Where the honest answer is that plain classes were enough, the section is absent, and that is deliberate. Inventing a pattern name for a design that does not use one is a common way to lose credibility in this round.

What we left out. This is the most useful section in every lesson and the one most people skip. It lists the simplifications the design makes and the trade off behind each one. Interviewers ask about exactly these. Say "I merged those two responsibilities to save time, and here is how I would split them". That answer is worth much more than hoping nobody would ask.

Practising with a timer

Once you have worked through six or seven case studies, change the exercise. Pick a question you have already done, set a timer for forty five minutes, and produce the whole answer from a blank page.

You will not finish. Nobody finishes. You are measuring two things. Did you spend your first ten minutes on requirements and actors? Did you reach running code on at least one flow before the time ended? Those two facts predict the result of the real interview better than the number of classes you drew.

If you are stuck, ask

Every lesson has a discussion area at the bottom. If a design decision does not make sense, or you think one is wrong, post it. Several of the designs in this course have been improved because a learner disagreed with them in public.

Key Takeaways

  • Reading a finished design is comfortable and teaches very little. Attempt first, then compare.
  • Stop at three points: after the question, after the requirements, and at each stage of the class diagram.
  • Read one language. The three versions are the same design and print the same output.
  • "What we left out" is the section interviewers ask about. Do not skip it.
  • After six or seven case studies, switch to timed runs from a blank page.

You now know what the course contains and how to work through it. What remains is how much of it to do, and in what order, given the time you actually have before your interview. The next lesson gives three plans for three different amounts of time.

On This Page

The parts of a case study lesson

Where to stop

Reading the diagrams

Reading the code

The two sections at the end

Practising with a timer

If you are stuck, ask

Key Takeaways