← Amazon Interview Insights

Amazon·Software Engineer·Onsite - Coding / Algorithms·Intermediate

Intermediate
Apr 2026

Summary

Amazon SWE coding round focused entirely on object-oriented design, specifically a multi-level parking lot system. The scope was broader than a typical LeetCode session, covering class design, implementation, and a design discussion all in one go.

Questions Asked (3)

Q1

Design a multi-level parking lot system that supports different vehicle types and spot sizes. Identify the main entities, sketch a class diagram with clear responsibilities, fields, and methods, and implement the core classes with attention to encapsulation and extensibility.

System DesignData ModelingTechnical Trade-offs
Author's notes

I started with the entities and drew out ParkingLot, Level, ParkingSpot, and the Vehicle hierarchy pretty quickly.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints (e.g., vehicle types, spot sizes, levels, entry/exit points, payment). Then identify core entities and their relationships, sketch a class diagram with clear responsibilities, and implement key classes focusing on encapsulation and extensibility. Finally, discuss trade-offs and potential extensions.

Pro tip: Emphasize extensibility by using interfaces and design patterns (e.g., Strategy for pricing, Factory for spot creation) and discuss how to handle concurrency for spot allocation. This shows you think beyond basic OOP and consider real-world scalability.

1. Clarify Requirements

Ask questions to understand scope: vehicle types (car, motorcycle, truck), spot sizes (compact, large, handicapped), levels, entry/exit, payment, and any constraints. Confirm assumptions.

2. Identify Core Entities

List main classes: ParkingLot, Level, ParkingSpot, Vehicle (with subclasses), Ticket, Payment, and possibly EntryPanel/ExitPanel. Define relationships (e.g., ParkingLot has Levels, Level has Spots).

3. Design Class Diagram

Sketch classes with fields and methods, ensuring single responsibility. Use inheritance for vehicles and spots, and interfaces for behaviors like pricing or spot allocation.

4. Implement Core Classes

Code key classes (e.g., ParkingLot, Level, ParkingSpot, Vehicle) with proper encapsulation (private fields, getters/setters) and extensibility (abstract classes/interfaces).

5. Discuss Trade-offs and Extensions

Talk about design choices (e.g., inheritance vs composition), concurrency handling, and how to extend for new vehicle types or pricing strategies.

Key Points to Mention

  • Use of inheritance and polymorphism for vehicle types and spot sizes.
  • Encapsulation: private fields with public methods, avoiding direct access.
  • Extensibility: interfaces for pricing, spot allocation, and payment; design patterns like Strategy, Factory.
  • Concurrency: thread-safe spot allocation using locks or synchronized methods.
  • Data modeling: relationships between entities (1-to-many, etc.) and database considerations.
  • Trade-offs: simplicity vs flexibility, performance vs maintainability.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

Implement park(vehicle), leave(vehicle), and availability_summary() methods. How do you handle spot assignment and freeing spots for vehicles that occupy multiple spots?

Algorithms & Data StructuresSystem DesignAPI & Integrations
Author's notes

Multi-spot assignment for trucks is where things got messy.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: vehicle sizes, spot sizes, and whether spots are contiguous. Then design data structures to track spot occupancy and efficiently find contiguous free spots for multi-spot vehicles, ensuring O(1) or O(log n) operations for park and leave. Finally, discuss availability_summary aggregation and trade-offs between simplicity and scalability.

Pro tip: Mention that you would use a segment tree or interval tree to quickly find contiguous free spots, but also consider a simpler approach like a linked list of free blocks if the parking lot is small. This shows you balance efficiency with practical constraints.

1. Clarify requirements and assumptions

Ask about vehicle sizes (e.g., motorcycle, car, bus), spot sizes, whether spots must be contiguous, and expected scale. Confirm if availability_summary should report counts by spot size or vehicle type.

2. Design data structures

Propose a data structure to represent spots (e.g., array or linked list) and track occupancy. For multi-spot vehicles, consider a segment tree or interval tree to find contiguous free blocks efficiently.

3. Implement park(vehicle)

Describe the algorithm: find a contiguous block of free spots matching the vehicle's size, mark them occupied, and store the assignment (e.g., vehicle ID to spot indices). Handle failure if no block exists.

4. Implement leave(vehicle)

Look up the vehicle's assigned spots, mark them free, and update any data structures (e.g., merge adjacent free blocks). Ensure the vehicle is removed from tracking.

5. Implement availability_summary()

Aggregate free spots by size or contiguity. If using a segment tree, you can query the number of free spots or largest contiguous block. Discuss time complexity and potential optimizations.

Key Points to Mention

  • Handling multi-spot vehicles requires finding contiguous free spots, which can be done with a segment tree or interval tree for O(log n) queries.
  • Use a hash map to map vehicle ID to its assigned spots for O(1) leave operations.
  • When freeing spots, merge adjacent free blocks to maintain accurate availability for future multi-spot vehicles.
  • Consider concurrency and locking if multiple threads access the parking lot simultaneously.
  • availability_summary can be computed on-the-fly or maintained incrementally; discuss trade-offs.
  • Edge cases: no available spots, vehicle size larger than any free block, and invalid vehicle IDs.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

Walk through your design and discuss how it would accommodate future requirements like hourly billing, reservations, EV-charging spots, and multi-tenant lots.

Technical Trade-offsSystem DesignAdaptability & Ambiguity
Author's notes

This part I actually felt okay about.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by outlining your core design for a parking lot system, emphasizing modularity and extensibility. Then, for each future requirement, explain how you would extend the design without major refactoring, using principles like separation of concerns and design patterns. Conclude by discussing trade-offs and how you would validate the design against these evolving needs.

Pro tip: Demonstrate foresight by anticipating not just the listed features but also potential interactions between them, such as how multi-tenant lots might affect billing and reservations. This shows you think holistically about system evolution.

1. Present the core design

Briefly describe the initial design for a parking lot system, focusing on key entities like ParkingLot, Spot, Vehicle, and Ticket, and how they interact.

2. Identify extension points

Highlight areas in the design that are likely to change, such as pricing, spot allocation, and lot management, and explain how you've made them extensible.

3. Address each future requirement

For each requirement (hourly billing, reservations, EV-charging, multi-tenant), explain the necessary additions or modifications, referencing design patterns like Strategy, Observer, or Decorator.

4. Discuss trade-offs and scalability

Analyze the trade-offs of your approach, such as increased complexity versus flexibility, and how the design scales with more features or tenants.

5. Summarize and validate

Summarize how the design accommodates future needs and mention how you would test or validate the extensibility, perhaps through unit tests or prototyping.

Key Points to Mention

  • Use of interfaces and abstract classes to define contracts for billing strategies, reservation policies, and spot types.
  • Application of design patterns like Strategy for billing, Observer for reservations, and Decorator for adding features like EV charging.
  • Multi-tenancy considerations: data isolation, configuration per tenant, and potential use of a tenant ID in core entities.
  • Database schema design that supports flexible pricing models and reservation time slots.
  • API design that allows clients to query availability, make reservations, and handle billing seamlessly.
  • Trade-offs between over-engineering and future-proofing, and how to balance them based on likely requirements.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.