Some things to keep in mind:
- The focus of the test is the design of the system and not how intelligently you restock.
- The system should scale well and be extendable to any number of restaurants, menu items, ingredients etc.
- The strategy being used to restock can be different for each restaurant, can change over time or be outsourced to another company etc. Using separate modules and interfaces is highly recommended.
- The design should incorporate the fact that it is a real-time system. Everyday you will be getting new data for the system and would want to reuse your calculations till the previous day. One approach you might take is to run the restocking inventory code as a cron job that is independent of the order management system. If that is the case, you will want to have the state of the restaurant saved every day. The other approach would be to have a process that runs all the time that only runs the inventory restocking code once at the beginning of the day. There is no one correct solution to such problems. Both can work well if implemented properly.
- The system must be agnostic of the fact whether we run it on the same data in one go or in multiple runs. For example, we should be able to run from day 1 to day 10 and then from day 10 to day 11 or from day 1 to day 11 in one go and expect the results to match.
You can generate input files in the following format:
Dish, Ingredient [, Ingredients ]
Burger, 2 Bread, 1 Chicken, 1 Cheese, 1 Onion
Pasta, 1 Penne, 1 Cheese, 1 Capsicum
Risotto, 1 Rice, 1 Cheese
Ingredients, Days between Purchase and Expiry
Burger, Pasta, Risotto
Timestamp of placing order, Restaurant_ID, Dish, Quantity
2015-02-28 10:00:00, Restaurant_1, Risotto, 3
2015-02-28 12:00:00, Restaurant_2, Pasta, 4
2015-02-28 13:30:00, Restaurant_1, Pasta, 2
2015-02-28 15:00:00, Restaurant_1, Burger, 1