How the Interview Runs

The interviewer says one sentence. "Design a parking lot." Then they stop talking and wait.

Nothing about that sentence tells you what to do first. It does not say how many classes they want. It does not say whether to write code. It does not say how long you have. That silence is the hard part of this round, and it is the part this chapter removes.

This lesson describes what the round is, what the interviewer is judging, and how to spend the time.

What this round is called

You are asked to design one application and show how it is built from classes. This is an object oriented design interview. Some companies call it low level design, or LLD. Some call it a machine coding round, which is the same interview with working code required at the end.

All three names mean one thing. Take a small product, name the classes inside it, define what each class is responsible for, and show how they connect.

This is not the system design interview. A system design interview asks how a product survives millions of users. It talks about servers, databases, caches and queues. An object oriented design interview stays inside one application. It talks about classes, fields, methods and relationships.

Same product, different level of detail. Preparing for one does not prepare you for the other.

The five steps

Every question in this course is answered in the same five steps.

1. Clarify the requirements. Turn one sentence into a short list of things the system must do.
2. Find the actors and use cases. Name who uses the system and what each of them does.
3. Find the classes. Turn the requirements into classes, and give each one a responsibility.
4. Connect the classes. Decide how each pair relates, and record it in a class diagram.
5. Write the code. Write the classes and the two or three methods that implement the main flows.

The order matters more than the speed. Each step feeds the next one. If you skip step one, step three has nothing to work from, and you end up inventing classes that no requirement asked for.

The rest of this chapter covers the steps that decide the answer. One lesson bounds the requirements, and it covers actors and use cases too. One finds the classes. One connects them. Two more cover the ideas that keep the model honest, which are the SOLID checks and the patterns worth knowing by name. Step five, writing the code, is what the case studies practise.

How to spend forty five minutes

A typical round is forty five minutes to an hour. Here is a budget that fits the shorter one.

Two numbers in that table surprise people. The first is that the two opening steps take up to a quarter of the hour and name no classes at all. The second is that code takes the largest single block, and it still only covers two or three methods.

You will not finish the whole product. Nobody does. The design is judged on the part you chose to build, not on how much of it you covered.

What the interviewer is actually judging

The interviewer is not counting classes. They are watching for five things.

• Did you bound the problem? A design for a bounded set of requirements is worth more than a broad design for an unbounded one.
• Does each class have one job you can state in a sentence? A class you cannot describe in one sentence is usually two classes.
• Are the relationships right? Whether a class holds another one, owns it, or extends it changes the design, and the wrong choice is visible immediately.
• Does the code match the diagram? A method in the code that has no home in the diagram means one of the two is wrong.
• Can you explain a trade off? Every design has a choice you made and an alternative you rejected. Saying both out loud is worth more than either one alone.

Notice what is missing from that list. Nobody is checking whether your notation is correct, or whether you used every diagram type. The model is the answer. The notation is only how you show it.

A worked example of size

Take the parking lot. Twelve requirements produce about twelve classes. Those twelve classes have about fifteen relationships between them. Three of them implement the main flows. One hands out a ticket, one holds a vehicle, and one prices the stay.

You write those three properly. You name the other nine and describe them in a sentence each. That is a complete answer inside forty five minutes.

The mistake that costs the most time is writing all twelve classes at the same level of detail. It looks thorough and it leaves no time to show a single flow working end to end.

Key Takeaways

• Object oriented design, low level design and LLD are three names for one round. Machine coding is the same round with running code required.
• The round stays inside one application. Classes, fields, methods and relationships, not servers and databases.
• Five steps, always in the same order: requirements, actors and use cases, classes, relationships, code.
• Spend up to a quarter of the time on requirements and actors before naming a class.
• You are judged on bounding the problem, single responsibilities, correct relationships, code that matches the diagram, and one trade off you can explain.
• Build two or three flows properly rather than twelve classes shallowly.

The five steps are the whole method. Once the order is fixed, the question stops being "where do I start" and becomes a set of smaller questions with known answers. The next lesson takes the first one, which is turning a single sentence into a list of requirements you can design against.