Amazon Interview Question
Program ManagersCountry: India
Interview Type: Phone Interview
is a comprehensive book on getting a job at a top tech company, while focuses on dev interviews and does this for PMs.
CareerCup's interview videos give you a real-life look at technical interviews. In these unscripted videos, watch how other candidates handle tough questions and how the interviewer thinks about their performance.
Most engineers make critical mistakes on their resumes -- we can fix your resume with our custom resume review service. And, we use fellow engineers as our resume reviewers, so you can be sure that we "get" what you're saying.
Our Mock Interviews will be conducted "in character" just like a real interview, and can focus on whatever topics you want. All our interviewers have worked for Microsoft, Google or Amazon, you know you'll get a true-to-life experience.
Design question for the phone interview is heavy when you dont really have a white board to show the details.
- Saurabh July 27, 2014Never the less, here is how I will answer this question
Note: For now I have not handled follow up questions
-------------
To handle design questions, I will take following approach.
1. Think about the use cases
2. Outline all the constraints of the system.
3. Then write abstract design.
4. Come up with the Non Functional requirements (Required Performance Analysis, Scalability, Availability, Maintainability etc)
Following are the use cases that immediately come to mind:
Use Case:
=================
1. Customer pays cash / card and books tickets in the multiplex for a show.
2. Customer goes online, pays through credit/debit card and books ticket for a show. (Using API)
3. 3rd party books tickets for the show and we share revenue with the 3rd party. (follow up step)
4. Online seat availability system to display available seat count for a show.
5. Ticket Cancellation (Discuss with interview, identify it as a non important use case to be implemented as an enhancement for version 2)
Constraints:
=================
1. To be available for box office (desk at the theater) and online.
2. need to integrate with 3rd party using APIs -- ( Not to be considered due to time constraints)
3. Display seat availability chart or just the count on the screen (online and inside theater system)
4. Functional requirement - How is last seat handled, booked through online and also booked through the box office (desk at the theater)
5. Handle non functional requirements
- Performance (How many transactions per second)
- Scalability
Abstract Design:
=================
Architecture:
Following entities come to my mind when I think about multiplex booking software.
Entities in the system
1. Theater Location
2. Movie
3. Show details (Show Time and Show Date)
4. Reservation
5. Show charges
6. Discounts (if any → to be kept outside of the scope for now)
7. Customer
8. Payment
Following is the detailed table structure.
Table Structure:
=================
* marked is the primary key
Theater Location:
----
Theater ID *
Location Zip Code (as the cost might changed based on theater location)
Theater Type (AC / non AC etc) → may be in Alasta we dont need AC theaters)
Movie
----
Movie ID *
Movie Name
Movie Type (PG-13, G)
Show Details
----
Show ID *
Theater ID *
Movie Type (3D, 3d With IMax, non 3D)
Screen Number (moved later to different table)
Show Charges (different charges for morning show, late night show etc) (moved later to different table)
Seating capacity (moved later to different table)
----------
As part of 3rd normal form, screen number and capacity does not depend on show id and theater id, so moving it out of the Show details table)
Show charges will change per movie as well, so need to move the charges out of show details table and create a costing table
-----------
Costing
----
Movie ID *
Movie Type (imax, 3D) *
Day (Weekend or weekday) *
Time (prime time - 8PM to 11PM vs non prime) *
theater ID *
cost (cost in dollars)
PlayingMovie
----
Playing Movie ID *
Show ID
Theater ID
Screen Number
Show Time
Show Date
Movie ID
Screen
----
Show ID *
Theater ID *
Screen Number *
Seating Capacity
Screen Type (iMax or non iMax)
Customer
----
Customer ID *
Customer name
Payment
----
Customer id *
Show id *
payment id
Payment Type (Credit/Debit/Cash/Cheque)
Payment Amount
Credit card last 4 digits (For cash it will say cash)
Reservation
----
Customer ID *
Show ID *
Playing Movie ID *
Based on the tables some of the relationships will be as follows:
Relationships:
----------------------
Cost = Theater location -- Movie -- Movie Type (3D, 3d With IMax, non 3D), Show ID
customer to payment → 1 .. * (1 customer can make multiple payments)
....
How to check if the tables are good enough
==============================
1. Ask yourself SQL type questions:
How many seats are booked for movie ID 101 in theater ID ABC at screen 5 at time 11AM
Answer:
1. Go to Playing Movie table and for the show id, theater id and date, time and screen, get the playing movie id.
2. Go to screen table, For that show id and theater id, get the seating capacity.
3. Go to Reservation table, for the Playing Movie ID, count the total rows
Give me the cost of the iMax movie “ABC” which is playing in theater in chicago today at 11AM
Answer:
1. Go to Movie table. For that movie name and type, get the movie ID
2. Go to costing table, for that movie ID, get the list of costs. They will change based on other parameters, so it will return bunch of values)
API design:
=================
Some of the coarse Grain APIs for the front end and the 3rd party system:
1. Search Movie
2. Give availability
3. Make Payment
4. Reserve Movie
Non Functional Requirements
=================
1. Performance Requirements
Assuming for a very successful site, 100 thousand customers per hour visiting site.
20 % book ticket
20 % of 100K = 20K per hour
For 1 hour = 20K
For 1 min = around 350 transactions
For 1 second = 5 to 6 transactions
So the scalability will be based on this number.
2. Scalability
Handle scalability using Horizontal / vertical scaling, Caching, Database Sharding / Move some functionality to Asynchronous communication)
3. Availability - Using external load balancer, round robin calls between multiple servers.
Based on the time constraints, few more things can be added to the system like cancellation of the ticket, 3rd party ticketing and revenue sharing system
But for the phone interview, I guess, this much should do. It took me 40 mins to come up with all those details.