Round 1
Questions: Implement a Peer-to-Peer Delivery System that can be used to deliver a parcel from one customer to another. Below are the expected features of the system:
- The system should be able to onboard new customers and drivers.
- The list of items that can be delivered is preconfigured in the system and is fixed.
- Customers should be able to place an order for the delivery of a parcel and also be able to cancel it.
- One driver can pick up only one order at a time.
- Orders should be auto-assigned to drivers based on availability. Even if no driver is available, the system should accept the order and assign it to a driver when the driver becomes free. The number of ongoing orders can exceed the number of drivers.
- Once an order is assigned to a driver, the driver should be able to pick up the order and also mark the order as delivered after delivery.
- The system should be able to show the status of orders and drivers.
- Canceled orders shouldn’t be assigned to the driver. If an assigned order gets canceled, the driver shouldn’t be able to pick up the order; the driver should be available for other orders.
- Once a driver picks up an order, the order cannot be canceled by the user nor system.
- Assume driver is available 24*7. Ignore the travel time.
- Ensure application is thread safe and all concurrency scenarios.
Bonus:
- Notify the customer and drivers through email and phone for order updates. For this exercise, write a class that represents a vendor providing the email or SMS service and just print the log indicating that the vendor has processed the request.
- Customers should be able to rate the driver after delivery.
- Dashboard to show top drivers based on different strategy: number of orders, rating.
- If no driver picks up the order within 30 minutes of its creation, the order should be canceled. Regardless of whether an order has been assigned to a driver or not, if no driver picks it up within 30 minutes of order creation, the order should be canceled.
Guidelines:
- Time: 120 mins.
- Write modular, clean and demo-able code (Test cases or runtime execution).
- A driver program/main class/test case is needed to test out the code by the evaluator with multiple test cases.
- Use design patterns wherever applicable.
- Please handle concurrency wherever applicable.
- Evaluation criteria: Demoable & functionally correct code, Code readability, Proper Entity modeling, Modularity & Extensibility, Separation of concerns, Abstractions, Exception Handling, Code comments.
- You are not allowed to use any external databases like MySQL. Use only in-memory data structures.
- No need to create any UX or any HTTP API. It should be a standalone application.
Sample Test cases:
- onboard customer (id, name)
- onboard driver (id, name)
- place order (customer_id, item_id)
- cancel order (order_id)
- show order status(order_id)
- show driver status (driver_id)
Candidate's Approach
The candidate approached the problem by designing a modular system with classes for Customer, Driver, Order, and DeliveryService. They implemented methods for onboarding customers and drivers, placing and canceling orders, and checking the status of orders and drivers. The candidate ensured thread safety by using synchronized blocks where necessary and handled concurrency scenarios effectively. They also created a mock notification service to simulate email and SMS notifications for order updates.
Interviewer's Feedback
The interviewer appreciated the candidate's modular design and attention to concurrency issues. They noted that the code was clean and well-structured, making it easy to follow. However, they suggested adding more test cases to cover edge cases and improve the robustness of the solution.