Design questions (also known as thinking questions) in an interview are very interesting. People have a love-hate relationship with it. If you are an interviewer or an experienced interviewee, you love the design questions. Else, you might not be too fond of it. The reason is simple – As an interviewer, your goal is to observe the candidate’s thought process, approach and creative thinking in a super compressed time. You may also end up learning something new. If you are an interviewee, you are not exactly sure if your answer is what the interviewer is looking for.
So, what exactly is a design question?
A design question is posed by the interviewer to observe your thoughts, approach, and style of working, in resolving questions related to algorithm, architecture and abstract issues.
Before we go further, it is important for you to understand your interviewer.
Most interviews are conducted by a group of people from different backgrounds. This is done to get rounded feedback about the candidate, their potential, strengths and perceived weaknesses (what I consider as strength, you might consider as a weakness and vice versa). Also, since you will be working with different people in the organization/company, feedback from a wide range of interviewers is extremely important. Such a group is generally a mix of your future peers, lead, manager, people from different disciplines (dev, test, build, etc) and a final approver also called “as appropriate” or “final interviewer”.
Some people are wired to think as developers, others as testers and yet others as Program Managers (depending on their experience and interests). Each one from a different discipline might approach the same design question with a different angle. Neither approach is right or wrong, but they can be very different.
Different types of design questions
In my experience design problems can be broken into the following categories. Of course, the world of imagination is limitless, but for most practical purposes, you can classify a given design question into one of the following buckets.
Algorithmic problems: These are problems that have specific steps to solve them. These problems are related to patterns, themes, algorithms, data structures and computer science applications.
Examples include “search”, “sort”, “tree” problems. These problems may occur in different formats like “Check if a number is a palindrome or not”, “Find a node in a tree”, “Find the fist common manager in an organization for any two given employees”, “Design a user-validation API based on certain criteria”, etc.
Architectural problems: Software architecture is the set of structures/components needed to design a software system, their relationship and dependencies. These are problems related to defining or modifying the architecture of a system.
These problems require you to think through the problem in detail, understand the consequence of different paths chosen. There is no right or wrong answers to these problems but experience of the space will help you become better at these problems.
Examples include “Design the architecture of the Ad platform” or “Design the shopping experience of Amazon”.
Abstract problems: Problems related to the approach of defining and designing a system. These problems require you to put on Product/Program Manager hat.
Examples include “Design an airport” or “Design a water heater in a hotel” or “Design an elevator”
Today’s problem: Usually the interviewer is stuck in a certain problem related to the area s/he is working on and will ask you about it. This is both very interesting and crazy. You do not have the complete context of the problem and implications, but if are a person who can think fast on your feet, you can give some very good suggestions to the interviewer (which also helps them think in a different direction).
Examples include “Imagine you are looking at an advertiser who is unable to spend money on clothing, how will you approach it” or “This is the architecture of the system, how do I make it more performant”.
Approach to design question
The most important part of approaching design questions or interviews in general is to understand the interviewer, personality and their current role. Listen to their questions and what they are looking for and definitely ask a lot of clarifying questions (but don’t just ask questions for the sake of asking). It is okay to make assumptions but make sure to communicate to the interviewer what you are assuming (e.g. I am assuming that you want me to design an online website for shopping wines and you do not have a brick and mortar store). Interviewers are looking for the process and approach you are taking to the design questions. They do not expect to have a solid design in place within an hour.
What are your thoughts and feedback on design questions? I would love to hear about “dos” and “don’t” of your experience.
More details about specific design problems in the next blog.