Parking Lot OOP Design round·Engineering·Hard·20 min

TCS Prime Software Engineer — Parking Lot OOP Design

20 min · 1 credit · scorecard at the end
Z
ZeroPitch Research Desk
Updated 2026-06-11 · Newly added · be among the first to take it
Field
Engineering
Company
Tata Consultancy Services
Role
Prime Software Engineer
Duration
20 min
Difficulty
Hard
Completions
New
Updated
2026-06-11

How to prepare

What this round tests, what strong and weak answers sound like, and the traps to sidestep.

What this round is about

  • Topic focus. You model a small real system, usually a parking lot, in object-oriented terms: classes, responsibilities, relationships, and how the design extends.
  • Conversation dynamic. The interviewer gives you a vague design X prompt, lets you think, then pushes one question at a time on every choice you make.
  • What gets tested. Whether you can identify entities, assign single responsibilities, choose composition versus inheritance, apply open-closed when a new type is added, and defend it all out loud.
  • Round format. Roughly twenty minutes on a shared whiteboard, with a design brief on a card; you sketch the class diagram and talk through it.

What strong answers look like

  • Clean decomposition. You name ParkingLot, ParkingSpot, Vehicle and Ticket quickly and give each a one-sentence responsibility without using the word and.
  • Defended relationships. You say this is composition because a lot has spots, not is a spot, when the interviewer asks why not inheritance.
  • Extension without edits. Asked to add an electric scooter or UPI payment, you add a new subclass behind an interface and name the existing class you do not touch.
  • Pattern with a reason. You place a factory or strategy only where it removes real duplication, and you can say a singleton is often a trap.

What weak answers look like (and how to avoid them)

  • The god class. One ParkingLot doing parking, payment, tickets and reports. Split responsibilities so each class has one reason to change.
  • Definitions without application. Reciting the four pillars but not pointing to where abstraction lives in your design. Always tie theory back to a class on the board.
  • Editing old code to extend. Adding a new vehicle type by changing a switch inside an existing class. Extend through an interface instead.
  • Over-engineering. Three factories and a strategy for a two-line problem. Keep the first cut simple and say where you would extend later.

Pre-interview checklist (2 minutes before you start)

  • Recall the core four. Have ParkingLot, ParkingSpot, Vehicle and Ticket ready as a starting skeleton.
  • Have a one-line responsibility per class. Be ready to describe each without the word and.
  • Think of one extension. Know how you would add a new vehicle type or payment mode without editing existing classes.
  • Identify your private fields. Be ready to say why a field is private and what breaks if it is public.
  • Pull up the whiteboard early. Plan to put boxes on the page in the first two minutes rather than narrating in the air.
  • Recall the last-slot case. Have a spot-level lock answer ready for two cars reaching the last spot at once.

How the AI behaves

  • Probes every claim. It asks you to defend each class split and relationship, not just name it.
  • No mid-interview praise. It will not say great answer; it acknowledges the specific choice you made, then pushes.
  • Interrupts on the god class and on over-engineering. It pushes back equally on one class doing everything and on too many classes for a tiny problem.
  • Adds requirements live. Once you have a design, it introduces a new type or a concurrency case to see how far your design stretches.

Common traps in this type of round

  • Coding before designing. Jumping into syntax before the classes and responsibilities exist on the board.
  • Responsibility soup. A class you can only describe using the word and, which signals it is doing too much.
  • Modify-to-extend. Editing an existing class to add a new vehicle type instead of adding a subclass behind an abstraction.
  • Pattern for its own sake. Forcing a factory or singleton where a plain class would do, to look advanced.
  • Silent thinking. Going quiet on a hard probe instead of narrating the tradeoff you are weighing.
  • Ignoring the edge case. Skipping invalid input or the two-cars-one-spot race when the interviewer raises it.

Sample problems you'll face

The problem below is the same one you'll work through in the live session — no surprises. Read the constraints carefully; the AI persona will refer you to the on-canvas card by problem number.

  1. 1Design a Parking Lot in Object-Oriented Terms

    Design a parking lot system using object-oriented design. Identify the core entities and model them as classes, decide the relationships between them, define the interfaces, and apply the SOLID principles so the design is clean and extensible. The lot has multiple spots of different sizes. Vehicles of different types arrive at an entry, are assigned a compatible free spot, receive a ticket, and pay on exit. The interviewer will ask you to extend the design (a new vehicle type, a new payment mode) without modifying existing classes, to justify why a field is private, to defend composition versus inheritance, and to say where a design pattern genuinely fits. The bar is a design you can defend out loud, not a perfect UML diagram.

    Example inputA car drives up to the entry gate; one compact spot and one large spot are free. Later, the operator asks you to also support an electric scooter that needs a charging-enabled spot, and to accept UPI payments in addition to cash.
    Example outputParkingLot holds a collection of ParkingSpot objects (has-a, composition). Vehicle is an abstract base with Car, Motorcycle and Truck subclasses (is-a). assignSpot returns a compatible ParkingSpot and issues a Ticket. To add ElectricScooter, add a new Vehicle subclass and a charging-capable spot type without editing ParkingLot; to add UPI, add a new implementation behind a PaymentProcessor interface. The last free spot is protected by a spot-level lock so two cars cannot both claim it.
    • Identify the entities and model them as classes; give each class a single responsibility you can state in one sentence without using the word and.
    • Decide each relationship explicitly as has-a (composition or aggregation) or is-a (inheritance), and be ready to defend the choice.
    • Apply SOLID: especially single responsibility, and open-closed so a new vehicle type or payment mode can be added without modifying existing classes.
    • Encapsulate internal state behind methods; be ready to justify why each exposed field is public and each hidden field is private.
    • Use a design pattern (factory, strategy, observer) only where it removes real duplication or coupling; do not force a pattern, and treat singleton with caution.
    • Handle the concurrency edge case where two vehicles reach the last free spot at the same time by protecting the allocation step.
    • On the whiteboard, draw the class diagram: one labelled box per class, and label every connecting line as has-a or is-a so the relationships are readable without narration.
Reference

The full breakdown

How you're scored, the questions candidates ask most, and the research this interview is built on. Skim it — or just start the interview.

Interview framework

You will be scored on these 6 dimensions. The full rubric with definitions is below.

Class Decomposition
How cleanly you break the system into classes that each own one responsibility, named before you write any code.
22%
Relationship Reasoning
Whether you correctly choose and defend has-a versus is-a, composition over inheritance, with reasons tied to the design.
20%
Open-closed Extensibility
How well you add a new vehicle type or payment mode through an abstraction without editing classes you already wrote.
22%
Encapsulation Defense
How convincingly you justify private fields and access, naming what breaks if internal state is exposed.
14%
Pattern Judgment
Whether you place factory, strategy or observer only where they earn their keep, and avoid forcing patterns or singletons.
12%
Design Self-awareness
Whether you can name where your own design is weakest and where it would break first under change or load.
10%

What we evaluate

Your final scorecard breaks down across these dimensions. The full rubric and tier criteria are revealed inside the interview itself.

  • Class Decomposition Clarity22%
  • Relationship Modelling Reasoning20%
  • Open-Closed Extension Handling22%
  • Encapsulation Defense Depth13%
  • Pattern Placement Judgment12%
  • Design Tradeoff Self-Awareness11%

Common questions

What does the TCS Prime OOP and low-level design round actually test?
It tests whether you can turn a vague design a parking lot ask into named classes, clear responsibilities and an extension story, defended out loud. The interviewer checks that you identify entities like ParkingLot, ParkingSpot, Vehicle and Ticket, decide relationships such as composition versus inheritance, and apply SOLID principles, especially single responsibility and open-closed. You will be pushed on why a field is private, where a factory or strategy pattern fits, and a light touch of concurrency. The bar is a clean, extensible design you can justify, not a perfect UML diagram. It is the design layer Prime adds on top of the Digital coding set.
How should I structure my answer in a low-level design interview?
Start by clarifying scope in one or two questions, then name the core classes before writing any code. For each class say in one sentence what it is responsible for; if you need the word and to describe it, it is probably doing too much. Sketch the classes and their relationships on the whiteboard, mark has-a versus is-a, and only then add behaviour like spot allocation or fee calculation. Keep it simple first and call out where you would extend later. Narrate every decision out loud, because the interviewer is grading the reasoning, not the diagram.
What are the most common mistakes candidates make in this round?
The biggest one is the god class: a single ParkingLot that parks cars, takes payment, prints tickets and runs reports, which couples everything together. The opposite failure is over-engineering, adding three factories and a strategy pattern for a two-line problem. Other frequent misses are reciting the four pillars of OOP as definitions without applying them to the actual design, rewriting existing classes when asked to add a new vehicle type instead of extending through an interface, and going silent instead of narrating tradeoffs. Ignoring the case where two cars reach the last slot at once also loses credibility.
How is this AI interviewer different from a real TCS interviewer?
It behaves like Arjun, a Prime technical panel member: it gives you the design prompt, lets you think, then probes one question at a time and pushes for specifics. The difference is it never breaks character, never praises mid-interview, and is perfectly consistent across attempts, so you can rehearse the same pressure repeatedly. It scores your design reasoning, never your accent or fluency, which matters for first-time interviewers from across India. Unlike a real panel it produces a written, transcript-backed scorecard afterwards naming the exact choices you could and could not defend.
How is the round scored?
You are scored on applied design ability, not memorised theory. The dimensions include how cleanly you decompose classes and assign single responsibilities, how you justify relationships like composition over inheritance, whether you can add a new vehicle type or payment mode without editing existing classes, how well you defend encapsulation choices, and whether you place design patterns where they genuinely help rather than forcing them. A light concurrency probe and your ability to narrate tradeoffs out loud also count. Reciting definitions without applying them, and over-engineering a simple problem, both pull your score down.
What should I do in the first two minutes of the round?
Do not start coding. Spend the first minute clarifying scope: ask whether it is a single multi-floor lot, what vehicle types matter, and whether payment is in scope. Then list the handful of core classes out loud, ParkingLot, ParkingSpot, Vehicle, Ticket, and say one responsibility for each. Pull up the whiteboard early and put boxes on the page so the interviewer can point at them. Signalling that you design before you code, and that you keep the first cut simple, sets the tone the Prime panel is looking for.
How do I answer when the interviewer says add a new vehicle type without touching the existing classes?
This is the open-closed test. The right shape is an abstraction, an interface or abstract Vehicle base class, that existing code depends on, so you add a new ElectricScooter subclass without editing the classes you already wrote. Avoid editing a switch or if-else chain inside an existing class, because that is exactly the modification the question forbids. Say explicitly which existing class stays untouched and which new class you add. The same pattern applies to a new payment mode like UPI through a payment interface, so you can name one principle that covers both asks.
What does a strong answer sound like in this interview?
A strong candidate names four or five classes quickly, gives each a one-sentence responsibility, and defends a split when challenged: this is composition because a lot has spots, not is a spot. When asked to extend, they reach for an interface and add a subclass rather than editing old code. They can say why a field is private and what breaks if it is public, and they place a factory or strategy only where it removes real duplication, while noting a singleton is often a trap. They handle the two-cars-one-spot case with a spot-level lock, and they keep narrating their reasoning throughout.
Which design patterns should I know for a TCS Prime low-level design round?
Focus on a small, well-understood set rather than memorising the whole catalogue. Know the factory pattern for object creation, the strategy pattern for swappable behaviour such as different fee or pricing rules, and the observer pattern for notifications like a freed-up spot alerting a waiting queue. Understand why a singleton is often considered a trap, since it hides global state and complicates testing. The interviewer cares less about you naming a pattern and more about you placing it where it genuinely reduces coupling or duplication, so be ready to say why this pattern, here.
Is the parking lot the only system they ask about?
No. The parking lot is the most common prompt, but the elevator or lift controller, the vending machine, a library management system, an ATM and a Splitwise-style expense splitter all share the same skeleton: identify entities, assign responsibilities, choose relationships, and design for extension. If you have clearly over-rehearsed one system, the interviewer may switch you to another to see whether you understand the method or just memorised one answer. Practising the underlying approach, entities then responsibilities then extension, transfers across all of them better than rote-learning a single design.

Sources this interview is built on

Real candidate-report URLs (Glassdoor / AmbitionBox / PrepInsta / GeeksforGeeks / Medium) reviewed when authoring the questions, persona, and rubric. Verify the realism yourself.