These mock interviews are pretty good to understand how a real interview would be. You may not have the right solution or the most optimal one but think logically about the largest entity to divide into classes until you reach the smallest Warehouse -> space in this case. I would probably have divided into these classes in terms of modeling the warehouse. Later you can define User and other methods to efficiently place products into a space in the shelf. Space is the most granular location. Unit is also a good idea when you just aggregate a bunch of products to be placed on the same space in the shelf. Warehouse + Map shelfTypeToShelves; // helps identify the shelves available and the use them to place products + Map productIdToShelfMap //helps identify the shelf where a product is placed quickly Shelf + ShelfType type + List openLocations + List occupiedLocations + Map productLocations (helps find a product in a given shelf) and remove from doubly linked list easily. Product + ProductId + Name + Description + Price ShelfType : enum Small, Medium, Large Space + SpaceId + SpaceStatus : boolean
Thank you for the detailed video... A few questions 1. Why does Order has a mapping of Product and count? Instead we can just use the list of Units which has all the information including unique product unit ID. 2. [minor] Tradeoff of using Product instead of productID in Unit class assumed copy by value instead of copy by reference? As Java generally passes by reference (for objects) so the Product reference wouldn't take extra memory and easy to refer to when needed. Instead productID will take even more memory because that is a copy by value.
2 cents: (which should be part of lld discussion/implementation or not, please clarify) 1. Order cancellations handling 2. Expiry date-based removal every day. (And pickup could be as well to minimize loss)
The head shaking is in agreement always? Like, it's *not* a "NO"? OR, when it is a no? I'm sorry if it sounds like a dumb question, keep in mind that is a cultural clash/shock one. 😅
Regarding the design. Q- Why are we handling the location class/Table differently? Type here is the only thing, can't we just add S/M/L in the unit class? Or is it to handle different location for a particular type of unit, but i don't see it mention in the Class. Thank you for these videos. It helps a lot and very informative.
Actually its reverse. Its to handle different units for a particular location. We can store S product in S M L location M in M L location, etc. Keeping the type in unit class which tightly couple the system to store S in S location, M in M location, etc. Since we are on enum part. I'll give a hint too to use state design pattern for handling the Status of Unit. But I believe we might not need for such small state transition diagram.
The design is good for given the time in which you made it but you have bundled a lot of things in the system class. It appears to violate the single responsibility principle. and that map of which product to which location you said you want to keep somewhere else apart from product should have been written in class diagram. like are you going to keep it in system or create a new trackProducts class.
These mock interviews are pretty good to understand how a real interview would be. You may not have the right solution or the most optimal one but think logically about the largest entity to divide into classes until you reach the smallest Warehouse -> space in this case. I would probably have divided into these classes in terms of modeling the warehouse. Later you can define User and other methods to efficiently place products into a space in the shelf. Space is the most granular location. Unit is also a good idea when you just aggregate a bunch of products to be placed on the same space in the shelf.
Warehouse
+ Map shelfTypeToShelves; // helps identify the shelves available and the use them to place products
+ Map productIdToShelfMap //helps identify the shelf where a product is placed quickly
Shelf
+ ShelfType type
+ List openLocations
+ List occupiedLocations
+ Map productLocations (helps find a product in a given shelf) and remove from doubly linked list easily.
Product
+ ProductId
+ Name
+ Description
+ Price
ShelfType : enum
Small, Medium, Large
Space
+ SpaceId
+ SpaceStatus : boolean
Thank you for the detailed video... A few questions
1. Why does Order has a mapping of Product and count? Instead we can just use the list of Units which has all the information including unique product unit ID.
2. [minor] Tradeoff of using Product instead of productID in Unit class assumed copy by value instead of copy by reference? As Java generally passes by reference (for objects) so the Product reference wouldn't take extra memory and easy to refer to when needed. Instead productID will take even more memory because that is a copy by value.
0:33 "maybe a notification" - sweet timing!
Lol
It's better to watch such an amazing workshop rather than watching a movie at friday night. 😅
💚💚💚enjoying it.
very informative video! thanks Arun and Gaurav for making it.
2 cents: (which should be part of lld discussion/implementation or not, please clarify)
1. Order cancellations handling
2. Expiry date-based removal every day. (And pickup could be as well to minimize loss)
Cool video. I find it useful 👏
Glad to hear that!
The head shaking is in agreement always? Like, it's *not* a "NO"? OR, when it is a no? I'm sorry if it sounds like a dumb question, keep in mind that is a cultural clash/shock one. 😅
@Sumit Rawat Thanks for clearing my doubt!
Regarding the design.
Q- Why are we handling the location class/Table differently? Type here is the only thing, can't we just add S/M/L in the unit class? Or is it to handle different location for a particular type of unit, but i don't see it mention in the Class.
Thank you for these videos. It helps a lot and very informative.
Actually its reverse. Its to handle different units for a particular location.
We can store S product in S M L location
M in M L location, etc.
Keeping the type in unit class which tightly couple the system to store S in S location, M in M location, etc.
Since we are on enum part. I'll give a hint too to use state design pattern for handling the Status of Unit. But I believe we might not need for such small state transition diagram.
Please bring asli engineering guy to one of the vidoe
Why are we storing product information, units, and locations in Java? Shouldn't we fetch these details from database?
jo main tha concurrent orders; wo ap logo ne assume krlia k sequential hoga order.. sedlyf ;(
The design is good for given the time in which you made it but you have bundled a lot of things in the system class. It appears to violate the single responsibility principle. and that map of which product to which location you said you want to keep somewhere else apart from product should have been written in class diagram. like are you going to keep it in system or create a new trackProducts class.
Hi please can any one help me how design database design for addresses like amazon users with different addresses
Arun is really good.
PS: I am not his fake id.
is it ok write down whole code in single class in interview?
Yes, easier to scroll between them instead of opening different tabs (in case of diff class files). Ofc, you wouldn't do that in the actual codebase.
never went to prod🤣