Creating an outline online shop seems quite a popular coding challenge. Even in businesses that don't seem to have any relation to this business model.
However defining the behaviour for how an online shop should handle orders is really complex. For the purpose of coding challenges I think that most organisations who set it really just want to handle concurrent ordering in simple ways with a quantity on the data entity representing the inventory item (the row or the document typically).
I get the impression that most people who set this problem want stock quantity to operate in serial. Each order attempts to assign stock to fulfil it when the order processing happens. Ideally people are ordering different things and the orders can happen in parallel but if there's a conflict it is first come, first served according to the process that first acquired the lock (rather than when the order was placed).
I think basically people are asking for a table or database lock with a row or document lock for each item in the order as being a solution less likely to cause performance issues or deadlocking.
Inventory = Stock - Orders
I've actually worked in a grocery business though and this model is not at all how the inventory system actually worked. I've also attended some interesting talks about how to implement allocation or auction systems for retail systems where items are potentially unique (such as Etsy or vintage fashion) or very small (fashion "drops").
None of these systems combine the inventory with the definition of the item.
For the system I actually worked on it recorded the following things separately:
- the quantity of items that had actually been checked in and shelved in the warehouse
- the orders with suppliers and the orders from customers.
Our terms and conditions meant that orders were actually requests from customers and we would only honour them if stock was available. Similarly if we had "buy one get one free" (BOGOF) style promotions we would allocate stock to orders to try and maximise the fulfilment of promotions but once the stock ran out we would then go to substitution logic to try and fulfil the desired quantity of the order.
The concept of our inventory then was actually quite complex and was basically the quantity on hand for the exact Stock Keeping Unit (SKU) code minus the customer orders for those SKUS. This meant our inventory quantities could be negative.
For negative inventory our buyers would be expected to try and purchase just enough supply before the fulfilment deadline to match the demand.
If we got to the fulfilment time and the stock could not be "picked" (transferred from the warehouse shelves to the transport container) then we would "short" the order and if necessary refund the customer.
I believe we had this setup because the order was considered a kind of asset and therefore we could borrow money in the form of a short-term overdraft to do the necessary purchasing to fulfil the order. The less inventory we had on had in the warehouse the more, perhaps paradoxically, we could sell as we didn't need to store the full amount for all orders.
Amazon seems to do the same thing offering items that might be fulfilled in the future or a substitute in the shopping experience. They obviously must be in a different league for how they manage this and allocate purchases between their own inventory and partners.
The system delivered "fairness" in order fulfilment by using an ordered queue where each order was processed based on its submission time. Our orders didn't have to be fulfilled in real-time (which is like quite a few real-world systems) so the time to actually place the order didn't matter. Even if your order was first placed it might not be completed in full though, for reasons explained in the next section.
I'm not sure the queue idea would be accepted as a solution in a coding challenge though as it creates a bottleneck if orders are disjunct. You'd probably get dinged for not scaling (despite it working in the real world).
Allocating stock
In our fulfilment process, stock was allocated across all orders for the ordering period to try and ensure that the maximum number of customers received some fulfilment of the order. This makes sense from a wholesale perspective because the customer will just try and order more in the next order cycle (or source from elsewhere if they can).
I'm trying to remember if BOGOF was assigned as a unit to each customer. I'm not sure but I think it was because again you want to try and maximise the number of customers who get the benefit of the discount rather than allocating all of it to the earliest bulk orders.
It is a very different model from Etsy though. I imagine there each order is allocated stock according to the time of its receipt but it is clear that something in your basket can be out of stock when you order.
Writing requirements
Often with these tests you get a hand-waving statement that your ability to deal with ambiguous requirements is also part of the test. Well that might be true but since you are often assessed on whether you implemented the ambiguous requirements "correctly" it feels like there is often hidden information. The kind of thing that in the real world you try and flush out with prototypes, workshops and conversations between all the project stakeholders. Those of kind of skills aren't actually being tested here.
You could allow a refinement phase of questions that are answered after the problem statement has been given but I haven't seen that much myself and on the other side I've seen candidates asking questions about how a problem should be solved classified as "problematic".
So really I think if you want to use the e-commerce shop as a test then you also have an obligation to explain how you want inventory and orders to be handled. You need to explain whether orders can be partially fulfilled. You need to say how the concept of being out of stock works for your case.
Is this is a shop?
But my other thought is that perhaps this is a poor kind of problem to set. It is too fraught with interpretation and assumptions of how things should work.
Maybe a problem domain that is much less ambiguous would work better. For example booking a theatre seat makes it clearer that the inventory is limited and that you can't sell the same item twice. Of course theatres and cinemas have their own twists in the form of not allowing single seats between bookings.
Maybe using an antiques shop as the example is clearer, each item is unique and therefore stock is not a concern. Each item in an order is equally desirable so you don't need to worry about partial or total fulfilment.
A little more thought in the problem statement makes it easier to push the candidate towards the skills you want them to demonstrate.
Conclusion
I think sometimes you can be cursed with too much knowledge of a problem. That is why abstract problems are sometimes seen as preferable despite the bias it creates towards prior knowledge.
The reason I wrote this was to let off a little steam but I'm also interested in the views of both candidates and employers. Why does this problem get used by employers that really don't do meaningful retail? How stressful is it for candidates to deal with these ambiguous requirements? Is this in any way a good coding test? What are the key things it demonstrates?
Top comments (0)