# System Design Interview Framework

DevFeed: [System Design Interview Framework](<https://devfeed.tech/articles/system-design-interview-framework-32316.md>)

Original publisher: [Read original article](<https://evanking1.medium.com/system-design-interview-framework-419b4796e051?source=rss-9736778727ef------2>)

Author: Evan King

Published: 2024-11-19T21:39:41Z

Content type: tutorial

Language: en

Sources: [Evan King](<https://devfeed.tech/sources/evan-king.md>)

Topics: [Requirements](<https://devfeed.tech/topics/requirements.md>), [structure](<https://devfeed.tech/topics/structure.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Framework](<https://devfeed.tech/topics/framework.md>), [client](<https://devfeed.tech/topics/client.md>)

Tags: [approach](<https://devfeed.tech/tags/approach.md>), [framework](<https://devfeed.tech/tags/framework.md>), [interview](<https://devfeed.tech/tags/interview.md>), [requirements](<https://devfeed.tech/tags/requirements.md>), [structure](<https://devfeed.tech/tags/structure.md>), [system-design-interview](<https://devfeed.tech/tags/system-design-interview.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

A practical framework for system design interviews that emphasizes delivering a working system. It recommends spending about five minutes clarifying and prioritizing functional and non-functional requirements, with examples involving Twitter and a cache.

## Source excerpt

From the co-founder of www.hellointerview.com The easiest way to sabotage your chances of getting an offer in your system design interview is to fail to deliver a working system. This is the most common reason that mid-level candidates fail these interviews. While a firm structure to your approach is important and your interviewer is not trained specifically to assess you on your delivery (often this gets bucketed into "communication"), in practice we've seen many candidates that perform significantly better by following a structure which both keeps them from getting stuck and ensures they deliver a working system. Requirements (~5 minutes) The goal of the requirements section is to get a clear understanding of the system that you are being asked to design. To do this, we suggest you break your requirements into two sections. 1) Functional Requirements Functional requirements are your "Users/Clients should be able to..." statements. These are the core features of your system and should be the first thing you discuss with your interviewer. Oftentimes this is a back and fourth with your interviewer. Ask targeted questions as if you were talking to a client, customer, or product manager ("does the system need to do X?", "what would happen if Y?") to arrive at a prioritized list of core features. For example, if you were designing a system like Twitter, you might have the following functional requirements: Users should be able to post tweets Users should be able to follow other users Users should be able to see tweets from users they follow A cache meanwhile might have requirements like: Clients should be able to insert items Clients should be able to set expirations Clients should be able to read items Keep your requirements targeted! The main objective in the remaining part of the interview is to develop a system that meets the requirements you've identified -- so it's crucial to be strategic in your prioritization. Many of these systems have hundreds of features, but it