My experience with System Design interview practice: tips on how to improve your mock interviews

In December 2020, I had the chance of an additional system design interview to decide my Google level (after failing the first). I succeeded on the second try. I want to share my experience and some of my findings.

The System Design Interview’s quirks

There are roughly four types of interview questions for software engineers:

• Practical Coding: given an algorithm, code it out in practice
• Whiteboarding: given a problem, design an algorithm
• Take-Home Exercise: given an algorithm and data, code an E2E application
• System design: given a large scale problem, design an architecture

Today, I’d like to speak about System Design. System Design interviews are fundamentally different from whiteboarding and need to be approached differently in three aspects:

1. There is no one right solution, i.e., no HashMap that will get you down from O(n²) to O(n). Instead, questions can be deliberately vague and open-ended and trade-off discussions are mandatory.
2. The necessity of scoping: get lost in the details and you won’t finish on time, staying on a too high level makes your solution appear shallow.
3. The strong human component: you have to satisfy your interviewer who will be a complete stranger to you. Ultimately this is the aspect that strongly influences A. and B.

The human component

I believe that it’s this human component that makes practicing alone ineffective past a certain point.

Assume the following setting: in the first few minutes, the interviewer gives you a rough outline of the problem, where you have to design an autocomplete suggestions system. What usually happens is that your brain’s HashMap starts working subconsciously and immediately some solutions that you have seen in the past come to your mind. Your first thought may be that you’re going to use a Trie and you start thinking about pre-processing a known dictionary into that. So you outline that solution and if this was you practicing it, you’d probably have that all mapped out to a nice beautiful diagram in 15 minutes and then could have opened up the next requirement or collected a few imaginary bonus points for adding some monitoring solution to this.

But who says that the interviewer won’t throw you a curve-ball because like they’re feeling that you’re too comfortable with this?

With the passing of time interviewing has become an arms race: since candidates have a lot more resources available, the expectations have gone up, and, especially for System Design, questions are deliberately trying to get you out of your comfort zone.

This is especially true for Big-Tech with a large pool of interview questions and high interview standardization.

Two examples in the context of this question, if they see you go into self driving mode:

• Changing the question they might say “OK, the whole system for auto completion was done by your colleague in the way you’ve suggested, can you now do offensive word filtering?”
• ad-hoc drill-downs, for example, “How are you going to scale this for languages beyond English?”.

Dealing with such changing requirements in a short amount of time, not getting sidetracked into unimportant parts of the overall solution while not ignoring them is something which requires practice. An ex-Google, ex-Uber staff engineer even told me during practice that he sees every system design interview as a kind of discussion, and, by definition, a discussion with yourself is not really a discussion but a monologue. One of my biggest takeaways and tips from them was to always try to gently steer the conversation into an area where I was strong.

Training

After establishing the difference of system design interviews from the other interview types let’s look into the process of practicing for them specifically. I’ve summarized my practice of System Design into the following graphic:

Effort (in the sense of time and brain cycle spent) to performance (in the sense of interview outcome) relationship.

1. Learning the ropes
   If you’re just starting out, you’ll probably appear to not make much progress in terms of interview performance just because you first need to learn all of the individual components like load balancers and message queue and you’re also still getting to know your tools like the whiteboarding tool that you’re going to use, this phase ends once you stop freezing up in the sense of that you have no idea what to do in such a setting. Note that you might still be going through this phase even if you’re comfortable with doing System Design at work since the tasks are way more general and the hard time-constrained puts extra stress on you.
2. Quick progress
   This is where the puzzle pieces come together: you know your tools, you know a couple of the basic system design questions. Things don’t feel awkward anymore.
   Facing each new situation will give you significant benefits and you just get better and better at managing time, putting your ideas onto the whiteboards.
   This phase comes to an end once you feel that questions start getting boring (depending on your skills, this can happen after going through 10 or 20 or more mock questions (generally the more experience the less this phase lasts). For myself, I’ve observed that as a developer I start approaching the problem of System design algorithmically, meaning that I will have a kind of standard approach I just will try to utilize for every problem.
3. At this stage, practicing by yourself starts having diminishing returns. With the great amount of resources that we have available now and with a lot more effort in introversion and insight into your own behavior, you will be able to fine-tune your designs but the lack of the human component (and the lack of feedback from another person on your final designs) starts showing. This is where you should move to doing mock interviews.

Here are some resources that I found helpful:

• System Design Interview channel. The best resource on YouTube that I could find. However, curb your expectations on YouTube videos in general, a lot (even with lots of views) are low quality.
• System’s expert course: questions. Before watching the videos, absolutely force yourself to solve the problem yourself.
• Questions posted/ leaked on LeetCode
• System Design Interview book. Was not yet available when I interviewed but it supposedly contains a lot of detail on common question types, and is very recommendable.
• Book: Building Microservices (second edition out now) — understanding the big picture in System Design
• Designing Data Intensive Applications. A great book, describing databases and handling data from the bottom-up. An overkill for the interview but a fun read.

Mock interviewing and its problems

Usually, we ask friends and colleagues for help. In my experience, there were some fundamental problems with that. I would like to outline them below and some possible mitigations.

1. A friendly situation is lightyears off of a real interview where you are talking to a stranger and are under pressure. The adrenaline and cortisol in your blood in a stress situation short-fuses your thinking. You absolutely want to practice unfriendly situations to get the stress level down.
   Mitigations (they boil down to making the situation less friendly):
   - no small talk before starting the interview
   - hard time limit, preferably make the time limit a little bit shorter than would be comfortable, e.g., 25 minutes instead of 30.
   - Have the timer always on the screen for extra pressure.
   - the peer must interrupt you and ask tough questions deliberately
   - audio connection only.
2. Most likely, unless they are often doing interviews at their job themself, they will not spend more than 30 mins preparing for your interview so they will not know all possible tradeoffs and nuances of a question.
   Mitigations:
   - Pick questions from a good database (e.g., System Design Interview book).
   - Tell your interviewer to select a question which is out of your comfort zone.
   - Emphasize to your partner that they will need to prepare for some time before they agree to mock with you.
3. Few will give negative feedback to your face to not tarnish their relationship with you. Mitigations:
   - ask them not to sugarcoat
   - ask them again not to sugarcoat and be serious about it
   - ask them to write down at least N clearly negative things you did during the interview no matter what.

Hence, yes, interview with your friends and colleagues for practice, however, don’t have too high expectations (it’s not possible to mitigate the problems fully).

Somewhat less helpful for me have been matching services (I used Pramp). There (perhaps this was a bad coincidence) I was paired with people doing their first ever System Design interview. That meant that they did not have much experience on how to be an interviewer ( people in Phase I.). In all three interviews, I was literally drawing for myself for half an hour and did not feel challenged.

The feedback I got for being an interviewee on Pramp was overwhelmingly positive (probably due to the people doing the interviews still being beginners themselves):

Pramp example feedback 1.

Pramp example feedback 2.

In hindsight, I think pairing services are helpful to feel how it is to be in the interviewer’s shoes but I would not expect to get a great interview experience.

Paying for a professional service

I heard from a friend about Verbetcetera (they don’t pay me any money to write this). This company matches you with freelance interviewers from Big-Tech companies. My experience with them after doing four interviews (with three different interviewers):

1. They led the interviews professionally: asking probing questions and trying to simulate a real-life experience. In fact, the interviews were so close to the real deal that I didn’t even get out of game mode come interview day.
2. The interviewers were experienced with the question they had asked and system design overall (calibrated at their respective companies). They looked at what trade-offs I made and were able to assess my design skills instead of pixel-matching my diagram to a sample solution.
3. I got very detailed feedback for every facet of my interview which helped me to improve with each iteration. Example:

4. beyond the interview they would share additional resources (for example, this guide).

Doing the interviews comes at a price (>100 EUR per interview) but given the difference in salary that a good interview can mean, I felt that it was still worth it (also, the training was tax-deductible in the Netherlands). After all, not only is a lot of money at stake but the odds are also skewed against you.

Summary

System Design interviews are dominated by the human component which can not be emulated by practicing alone. After practicing for some time and reaching a level of comfort, move to mock interviews. When doing mock interviews with friends, make the situation as “real” as possible and deliberately ask for negative feedback. Don’t expect a lot from interview matching sites and consider using a professional service.