I faced system design questions while interviewing for both Google and Directi, co-incidentally during my final round of interview for both companies. Personally, I feel that these questions make up for an excellent measure to gauge a candidate’s knowledge and software engineering skills. You should treat these problems as discussions and not as your conventional interview questions. In contrast to algorithmic problems which have a consistent and clear approach to a solution (or solutions), system design questions tend to be very open-ended. The interviewer may often consciously make room for ambiguities as a test of your design skills. From what I’ve learnt during my interview process, there are some points which you should keep in mind, while tackling system design problems.
Keep it simple, stupid (KISS)!
At the very outset, you should ensure that all the system requirements, design goals, optimization objectives are crystal clear before you proceed to brainstorm on possible solutions. As an example, suppose you are asked to design a minimalist text editor using appropriate data structures. A bad approach would be to straight-away start with advanced concepts such as tries. Agreed, tries are optimized for fast insertion and search, but you need to ask yourself, “Is that really required for a minimalist editor”. It is always a good idea to note down all the data structures you know and write the pros and cons of using each one of them in the problem domain at hand. This not only clears your thought process, but also ensures that you do not over-complicate things. You will be surprised to know how many seemingly complicated systems can be implemented using data structures which are as simple and elegant as linked lists and stacks!
Divide and Conquer
The problem statements might seem overwhelming at first, but there is absolutely no need to panic. Design questions are supposed to do look intimidating! You are expected to break the problem into modules and tackle each one of them independently. The problems that are generally asked are such that they can be easily decomposed into such fragments and solving the individual sub-problems should be a matter of reducing them to a known algorithm. For example, if I am supposed to design a technique to compress log records (lossless compression), my approach would be to first decide on what kind of fields a log record might contain and then think about efficient ways of compressing each one of them. Date and time can be stored as seconds elapsed since the beginning of the year (assuming we are interested in logs that are not more than a year old, this should fit in a 32 bit integer), verbose error descriptions can be replaced by short error codes which are mapped to their respective descriptions on a separate hash map, and so on!
Think out loud
Another very important strategy is to always keep communicating with your interviewer. As stated earlier, system design questions do not have a 0-1 answer. Whatever solution you proffer, there is always scope for optimizations. In such a scenario, it is imperative to let your interviewer have a glimpse of your thought process. Though this advice is true in general for the entire spectrum of question formats, it holds special significance here. Following this has the added benefit of the fact that the interviewer would be able to correct you if you digress from the intended path and he may have some ideas that you can further build upon in your solution.
Knowledge is power
Since, the systems that you would be asked to design are most likely going to be a simplified prototype of a commercial system, you might end up having to use some Machine Learning or Data Science in your solution. So, it’s a good idea to brush up on some common M.L. and N.L.P. concepts before your interview! If you are asked to implement the “Did you mean” feature in Google search, in addition to everything else, it wouldn’t hurt you to know about how spelling correctors work (N.L.P.)!
P.S. : This was originally posted as a Quora answer to this thread.