System Design Interviews
In my career i've been fortunate to take multiple interviews and also was interviewed multiple times , these interviews were a mix of pure problem solving ( Algorithms /DS ) and System design . I recollect best System Design interviews have been those where the candidate and the interviewer collaborated to arrive at an optimal solution of a real world problem with pros & cons.
System Design interview questions tend to be more open ended (Design an Online book store , Design a notification service etc ) and there can be multiple optimal solutions to those kind of problems . When i first started doing these interviews, i found it was a grey area and sometimes it was hard to make a decision on a candidate within a short time window (45 mins - 1 hr) . Over the years i figured out these interviews are different (where the focus should be on how the candidate thinks and makes a design choice ) , I have tried to apply the following steps which has helped me in making a better and informed decision of the candidate technical abilities .
Understand the problem : - Asks clarification questions on the basic requirements of the System , doesn't assume anything about the users and the Product , clarifies users , the interaction of the users with the Product and how they are going to use it with the interviewer.
System Boundaries & Constraints - Does the candidate truly identify and understand what are the System boundaries and definition of the System he or she is trying to built. This will be good to get clarity on clients , Offline processes or any UI interactions involved which fall outside the problem domain. Also it will be good to clarify on the scaling /performance requirement of the System Total Concurrent Users , Requests , Average and Max Response time for the requests , Payload , total volume , storage capacity etc . I sometimes intentionally leave them open , a good engineer can derive them ( Avg Requests per sec from total traffic in a month etc) by doing back of the envelope calculation or by some heuristics.
High level Design - Able to come up with a high level System design of the problem , come up with a basic building blocks /sketches of the system and bounce ideas off the interviewer. Identify different services /layers involved and how they communicate between each other. I have seen most of the candidates jump to address scalability issues without even solving the basic use cases which is a red flag for me.
Drill down : Ability to drill down a system and break into a set of modules/component which interact with each other ( using different process or execution paths) to solve the problem . Can the candidate zoom in to a particular module and explain what it does and how it fits into the bigger picture . Is the candidate able to design a system which solves the basic System requirements involving the low level components .
Iterate on Scale & Tradeoffs : A good engineer would be able to reasonably identify how to scale the infrastructure & iterate on the design if its not scalable . For Ex - To scale reads in an transactional system , Does it require a Cache is it Centralized or Distributed , what are the memory constraints on the Cache , Can a replica be used to serve all the Read requests etc , etc. Look for those signals and see if the candidate can describe the pitfalls /tradeoffs in the current design and propose alternative recommendations.
Closing thoughts
As an interviewer don't expect mastery from the candidate in all areas , if a design is proposed ask the candidate why he choose it , what are tradeoffs and understand the thought process behind the design choices employed. Good Engineers thrive in the ambiguity of problem space , understand the problem and steer the system in the right direction by the design choices they make.
