Example: If I say 'We can use a DHT based key value store such as Cassandra here' I assume they'll ask: "what makes it DHT?" I say "It's decentralized, where each node is responsible for a range of hashed key values distributed on a ring of nodes in counter clock wise fashion; it uses consistent hashing. Each node maintains routing tables, and will forward to another node if it receives a request to store/read a value whose hash(key) does not belong here. This relieves single point of failure seen in a centralized master->slave set up, and also minimizes the number of data items to be migrated when nodes join and leaves the network.' Will they keep digging, and ask me to describe the exact data structure of the node's routing table, the exact rules for forwarding to another node, the exact logic for handling joins and exits of nodes ,etc. ie, stuff that you really need to read the nitty gritty details of the Chord/Cassanda paper for? Or will the above qualitative description suffice? This is for general backend system design bar for E5, not specialist roles. Another example: "We can use versioning to detect write conflicts, and let either the application layer logic to explicitly resolve, or resolved based on last write." Will they ask me to describe the exact mechanism and data structure of versioning (ie, vector clocks) ? If any experienced interviewer could shed some light so I can appropriate target my study plans, that'll be great!
Just imagine you are in a new company without most handy tools, and you need to LEAD a design review/discussion. You need to show ability to make trade offs etc.
No, you won't be asked such deep questions. For a design interview you are expected to design a system end to end, from where you collect data, where you store it, how all these components will interact with each other (API), some implementation details, how will you estimate resources for the project etc. But if you had claimed to work on some internals of a DHT and if the interviewer also had worked, you might be asked more details. But the chance is slim. Try to see who your interviewer is and analyze their background, you will get an idea what they would ask and what they would expect. Good luck!
Thank you. And you are referring to system design (backend) right, not product design.
Yes system design. Make sure you design the end to end system before going into specifics. Interview may drive into the specifics they are looking for or you could drive your conversation into area where you feel you are strong.
https://www.practicecodinginterview.com/blog/2018/8/18/the-system-design-interview
Thanks. Does that imply that in the 45 min system design round it's not often that the level of detail described in my example will come up? What topics are more likely to come up instead?
thanks