Interview Deep Dive: Polymorphism in Machine Coding

Common Interview QuestionsQuestion 1: "Design a parking lot system. How would you use polymorphism?"
Answer Framework:
First, Identify the variation: Vehicle types (Car, Motorcycle, Truck) have different sizes and parking fee calculations.

Second, Define abstraction: Create Vehicle base class with calculateParkingFee(duration) and getRequiredSpotSize() methods.

Third, Show extensibility: ParkingLot.parkVehicle(vehicle) works with any vehicle type. Adding Bus requires only creating the new class.

Fourth, Address exceptions: If fee calculation becomes complex (dynamic pricing based on time of day), consider Strategy Pattern for pricing instead of embedding logic in each vehicle class.
Question 2: "How does polymorphism help you follow SOLID principles?"
Open/Closed Principle (OCP): Add new types without modifying existing code. The ParkingLot class is closed for modification but open for extension via new Vehicle subclasses.

Liskov Substitution Principle (LSP): Subtypes must be substitutable for base types. If parkVehicle expects a Vehicle, passing a Car or Truck must work correctly without breaking assumptions.

Dependency Inversion Principle (DIP): High-level modules depend on abstractions (Vehicle), not concrete implementations (Car). This decouples the parking logic from specific vehicle types.
Machine Coding ConsiderationsConsideration 1: Interface vs Abstract Class. Use an interface when types do not share implementation (e.g., PaymentMethod). Use an abstract class when types share common attributes or helper methods (e.g., Vehicle with registrationNumber field). If unsure, start with an interface; refactor to abstract class if duplication emerges.
Consideration 2: Method Granularity. Make polymorphic methods focused. Instead of one large process() method, use specific methods like validate(), execute(), calculateFee(). This makes implementations clearer and supports Single Responsibility Principle (SRP).
Consideration 3: Avoid Type Checking. If you find yourself using instanceof or type checks in client code, you have violated polymorphism. The entire point is to eliminate such checks. If needed, consider Visitor Pattern or double dispatch for complex type-dependent operations.
Anti-Pattern: Type Checking
if vehicle instanceof Car:
  fee = hours * 10
else if vehicle instanceof Motorcycle:
  fee = hours * 5
else if vehicle instanceof Truck:
  fee = hours * 20
This defeats polymorphism. Move fee calculation to each class's calculateFee() method.
Interview VariationsVariation 1: "The client wants to add dynamic pricing (weekday vs weekend rates). How do you modify your design?"
Answer: Do not modify the Vehicle hierarchy. Instead, introduce a PricingStrategy interface with WeekdayPricing and WeekendPricing implementations. Compose this into the ParkingLot or pass it to calculateFee(duration, pricingStrategy). This combines polymorphism (via Strategy) with composition, keeping the vehicle hierarchy stable.
Variation 2: "What if vehicles can have multiple roles (electric and luxury)? How do you avoid combinatorial explosion?"
Answer: Avoid creating ElectricLuxuryCar, ElectricStandardCar, etc. Use composition with interfaces: ElectricPowered and LuxuryAmenities as separate interfaces. A Car can implement both. Alternatively, use Decorator Pattern to add features dynamically.
Interview Tip: Interviewers test whether you recognize when polymorphism alone is insufficient. Always be prepared to combine it with Strategy, Decorator, or Visitor patterns for complex requirements.

💡 Key Takeaways

✓Polymorphism supports OCP (extensibility), LSP (substitutability), and DIP (abstraction dependency)

✓Use interfaces for behavior-only contracts; abstract classes when sharing implementation

✓Avoid instanceof checks; they indicate broken polymorphism design

✓Combine polymorphism with other patterns (Strategy, Decorator) for complex variation

✓In machine coding, start with simple inheritance; refactor to composition if hierarchy becomes rigid

📌 Examples

1Parking lot: Vehicle hierarchy with polymorphic fee calculation

2Vending machine: ProductSlot with different dispensing strategies

3Elevator: Request types (internal vs external) with different prioritization

← Back to Polymorphism Overview