Event listener infrastructure : The next question is who will forward events to the controller. We have vehicle sensors at multiple points of entry and exit. These sensors are able to scan a vehicle's props such as plate, height, type etc. and notify entry and exit event listeners about entry and exit. Note that this enables a real time feel and reduces waiting for vehicles (as spots can be made async available) if slots are full.Sensors run on their own threads.We have the flexibility of having sensors:listeners in a m:n relationship through the use of the composite listener pool.
Further note: SensorData is inner for enhanced encapsulation.

ParkingLot : Facade for the parking lot subsystem. Manages parkingSpot assignments. Validates vehicles to ensure that they follow parking policy (for eg max height).
A parking spot encapsulates level, spot no and vehicle types it is suitable for. This enables a vehicle to enter through a different level(floor) and park at a completely different floor (in case there was no space available on the entry floor.)Validators are strategy objects to ensure flexibility around different parking policies that might arise. Spot assignment is again based on strategy objects which decide which spot goes to which vehicle based on parameters.
Additionally, it would be easy to add timekeeping as shown. This would aid billing.

@soumyadeep2007 Appreciate your answer. In Interview , are they expect class diagrams or coding for this problem? just want to know how to answer design related questions, if they gave time for 30-40 mn how to approach to these kind of questions?

@rlmadhu There is no substitute for code on the whiteboard, that is what they want. If they ask you to do a class diagram, then do it, but its more of an adjunct. If you are asked such a question, take the initiative and get on the whiteboard and narrate your decision making. And not pseudo-code, actual code. You can obviously shorten syntax and stuff, but communicate that to the interviewer.

@rlmadhu honestly, I have never been asked to write the complete code of a system/oo design question in an interview.

I have always started with clarifying questions to understand all the use cases and restrictions. Then start my design with drawing class diagrams. I usually start with small components and try to connect them together to build dependencies and associations and finally the whole system. I usually come up with new classes once I'm trying to connect pieces together.

Then, the interviewer probably finds some parts of my design interesting and asks me to write code for a use case or two. Then I will do.

And mostly the interview is followed by some follow up questions such as how to add a new component/use case to the system and [almost always] how I'm gonna test the application.

For testing my design, I will start with a small component and test it alone. Try to remove the dependencies for the mentioned component/function (look up unit testing/mock/fake/stub). Then I'll test two or more components that are building a workflow together (integration testing) and finally the system as a whole (system testing).

Appreciate effort of this post. But I think there's no time to write so much code or think such detail. This looks like production code. I think design interview is more of high level.
What do you think?