I recently got back to interviewing, and thought I’d share the framework I’ve been using for design interviews that has resulted in offers at various FAANG companies. Previously, I’ve also conducted numerous interviews and also been in hiring committees from the inside of these tech companies, so I felt sharing the angle from the interviewer’s point-of-view could be helpful.

I also consolidated a concise 1-page summary of 12 core topics that commonly pop up in system design interviews that you can get here.

PART I. System Design Interview Framework

Side note, this is not a replacement for studying your stuff. There are numerous resources I’ve used to prep and brush up on my fundamentals and this is primarily a tactical framework I use to get that additional bump, which is often helpful when your hire/no-hire decision is on the boundary.

First, I think about these 3 points throughout the whole interview. Unlike the coding section, there is no formal answer on design interviews. It’s often not about the answer you produce, but how you get there.

1. Speak out your logic

Remember, everything is a tradeoff. Everything. Even expanding that field in your DB that will enable a critical user feature, or adding a test that will prevent that recurring bug comes at a cost. Don’t even think about adding a load balancer or async task queue until you understand why that is the most effective use of your company’s engineering resources at that time. So talk about this. Speak it out. Say that you would start by monitoring where the bottleneck will happen with the increased traffic, and give your reasoning on why you believe service “x” is where you would start increasing instances, and what would be the cost of such. Don’t always have to go into depth, but try to formulate your design decisions around “given (because of) A, I would do B”

One added benefit is that it gives you a fast way out should your decision be wrong. You might find that your logic is incorrect midway while you’re speaking out your logic. It might also expose a logic that comes from a misinterpretation of the requirements in which case you give a chance for your interviewer to correct your assumptions. The worst thing is when you have seemingly made up your (incorrect) decision, and the interviewer is not sure why you made that decision and is waiting for it to possibly make sense, but it never does and has to correct you 10 minutes later. By speaking out your logic you fail early and also have given a reasonable reason on what you took that path.

2. Read the room

So I lied above that “it’s not about the answer you produce, but how you get there”. Although it shouldn’t be, in practice your interviewer has already used this question a few times and knows the parts a good candidate should be covering. If you do your homework well you should be able to get 2/3 of your way to what the interviewer wants, but how on earth are you going to cover designing an Instagram feed in 45 minutes comprehensively? So if the interviewer starts talking about data failover, make sure you immediately pivot over to that topic even though you really want to continue discussing that security issue. If the interviewer is uneasy with what you’re giving, keep trying out different angles to your approach instead of doubling-down on your first answer. Try to get as much coverage on the components the interviewer is “expecting” you to cover.

3. Get your [++] marks

Remember, this is still an interview, not a tech discussion with your peers (unlike what some folks try to frame it as being). At the end of the day, the interviewer (at least a good one) is taking notes on the [+] and [-] parts of your interview session. If the previous part (“read the room”) was about minimizing the number of [-] marks, this section is about maximizing your [+] marks. If you’re targeting a senior role, you have to get some [+] and [++] marks. This is important for senior levels, and even for mid-levels (L4, L5), being able to “impress” the interviewer a couple of times during the interview goes a long way. So how do you impress?

One approach is to go one level deeper. Best to use your past knowledge/experience if possible, as that makes your points the most unique. Don’t dwell too long, unless the interviewer follows up as it could prevent you from covering other topics the interviewer wants to discuss. The point is that you want to show that you can talk about parts of a system in a bit more detail than the average interviewee. Talk about a feature in a service you’ve used in the past (e.g. using sets/lists in Redis for structured data cache), how you’d implement a service logic (e.g. rough verbal or written algorithm description), alternative approaches and discuss tradeoffs (e.g. numerate 3-4 ways of caching the request and which option you would choose). Best way to prepare for this is as you’re studying, write down a few “show-off” points. Read through company engineering blogs in your field, look into the feature sets and technical docs of a few popular services that you can mention universally for different types of interviews.

If you’re afraid to go too deep, simply touching in a different angle that is not commonly talked about will also add that “unique factor”. For example here are a wide variety of topics that you could be talking about. I’ve roughly ordered them by having the common topics at the top for generic interviews, but would obviously differ depending on your field.

• Scalability, availability, latency, throughput
• Usability (product-level), extensibility, testability, operational (monitoring, debugging, logging), resource capacity (CPU, memory, network bandwidth), async/offline jobs, analytics
• Security, portability (different surfaces), privacy (data retention, encryption)

So with these high-level points in mind, throughout the interview I try to take a simple 3 phase approach unless guided differently by the interviewer.

1. Assumptions

Clarify: From the interviewer’s perspective, this is the part where I see if the interviewee can narrow down an ambiguous scoped problem by asking relevant questions. From the interviewee’s perspective, all you need to think about is whether I can draw the right “building blocks” in part 2 below (high level design) with the information given. Don’t leave this step without 100% understanding the problem. Try to draw the building blocks in your head and if you’re stuck, ask.

Scope: After you’ve clarified and understood the problem, rule out blocks you won’t be drawing. Clarify the scope of the problem. e.g. do I have to think about the user login/authorization for this web app? What about the expiry on this URL short link?

Ballpark estimate: I feel this part is a bit overblown in design discussions. Showing off that you can crunch numbers well doesn’t impress interviewers. What does is how you connect those numbers to your design decisions. Here are a few points I try to touch on in this part

• Data schema, size → Guides database choice, replication
• Traffic: Bandwidth, patterns (cyclical, bursty) → Determines whether you need to touch on scalability and how.
• Read:write ratio → Storage (availability for high read), scaling (cache), API decisions

2. High level design

The part where you draw the rough building blocks. Try to “read the room” and make sure you get good coverage in this section. I make it a point that I will talk about scaling and other details after I have a rough drawing of the high level design.

In this section, I try to make sure I have good coverage on these two parts

• Component/API: Discuss the various components (service, storage, cache, queue, client, extensions) and also the interface between each component (API, communication protocol).
• Data: Details on data schema, flow between services, how it would be stored, cached, modified.

3. Detailed discussion

• This part is extremely specific to the problem at hand and it’s important to also follow the flow you are having with your interviewer in your session. Aim to get a few [+], [++] points here to show your knowledge and reasoning.
• Scalability: A frequent extension to the basic discussions. There should be a lot of material discussing this, but it’s important to note the following
  • Mention the tradeoffs of scaling your system and that you would only add a solution for this when/if needed (e.g. live traffic monitoring suggests we need to scale, we have strong product indication that we will require a large amount of traffic from day 0, Golang is beneficial for our scaling purposes despite the tradeoffs around generics, dependency management and even just experienced dev hiring)
• In general, here are some common topics to be aware about so that you can discuss should you go over them in this section: Load balancing, reverse proxy, Caching (server-side, client side, database-level, eviction policies), CDN, DNS, Async (task queues, message queues, backpressure routing), Batch (map-reduce), Database (RDBMS, No-SQL, Federation, Sharding, Denormalization, CAP theorem), Communication (REST, UDP, TCP, RPC)
• Different angle of discussions, mentioned in “3. Get your [++] marks” above, are also good points to touch in this section should you have time.

PART II. System Design Core Topic 1 Pagers

The first thing when I got back to prepping system design interviews was the sheer amount of material I had to go through. It was also a hassle to get a concise overview of each topic to brief before the day of the interview. I tried to consolidate my notes and summarize the topics I felt were important and good to know prior to my interview and have put them here for folks who are interested: http://gum.co/sysdesign

The 1 pagers focus on 2 things:

• Concise 1-page summary on each topic. The purpose is to share an overview of each topic without it being overwhelming (either for beginners or as a cheat-sheet post your interview preparations)
• Optimized for system design interviews. Unlike the already great number of good resources out there this focuses on points that can help during the interviews, such as discussing tradeoffs, knowing when and how to use this topic during an interview, and where to get that extra [++] points mentioned above.

The topics I cover are the following:

• CAP Theorem
• Domain Name Service (DNS)
• Consistent Hashing
• Scaling
  • Load Balancing
  • Reverse Proxy
  • CDN
  • Caching
• Database
  • RDBMS
  • NoSQL
• Event-based architecture
  • Messaging
  • Streaming & Batch processing
• Communication Protocols

With the system design framework above and the 1 pagers shared here, I hope it can help others out there prepping for their interviews. Good luck! :)