How to Approach a System Design Interview: A 6-Step Framework

System design interviews feel intimidating because the prompt is huge and the time is short. “Design Twitter” in 45 minutes. “Design a ride-sharing app” in an hour. The trap is to start drawing boxes immediately and get lost. The fix is a framework you can run on autopilot, so your brain is free to think about the actual problem.

Here is the one I use. It works for entry-level, senior, and staff loops. Only the depth changes.

Step 1: Clarify the problem in 3 to 5 minutes

Most candidates skip this step and pay for it later. The interviewer does not want a generic solution. They want you to scope something specific.

Ask three categories of questions, in order:

• Who is the user? Consumer? Internal team? Both?
• What are the core features? Pick two or three. Push back on the rest.
• What is the scale? Number of users, requests per second, data size.

If they say “you decide,” pick numbers and say them out loud. “Let me assume 100 million daily active users, around 10,000 reads per second at peak.” Now you have a target to design against.

Do not ask twenty questions. The interviewer is also being graded on how productive the conversation feels.

Step 2: Define the API and data model

Before drawing any boxes, write the API. Two or three endpoints is enough. Something like createPost(userId, content) and getFeed(userId, cursor). This forces you to decide what the system actually does.

Then sketch the data model. Not full schemas. Just entity names and key fields. “Users table, Posts table, Followers join table.” If you are going NoSQL, describe the document shape.

This step is where senior candidates separate themselves. If you cannot name your entities, you cannot reason about storage, caching, or sharding later.

Step 3: Draw the high-level architecture

Now you draw boxes. Keep it boring. Client, load balancer, application servers, database, cache. Maybe a queue if you have async work.

Resist the urge to mention Kafka, Redis, Cassandra, and Kubernetes in the same sentence. Interviewers can tell when you are name-dropping. Pick one technology per role and explain why.

Walk through one user flow end to end. “User posts a tweet. Request hits the load balancer, goes to an app server, writes to the database, publishes an event to the fanout service.” If you can narrate it without backtracking, your architecture is coherent.

Step 4: Deep dive on one or two components

The interviewer will pick a part of your design and ask you to go deeper. Sometimes they let you choose. Pick something interesting, not something safe.

For a feed system, dive into fanout-on-write versus fanout-on-read. For a chat app, dive into message ordering and delivery guarantees. For a payments system, dive into idempotency and consistency.

This is where understanding fundamentals pays off. If you are shaky on what data structures power a queue, brush up with what is DSA. If you cannot reason about why a particular operation is slow, you need big-O notation explained. System design questions are really algorithm questions wearing a suit.

Step 5: Address scale, reliability, and tradeoffs

Once the design works for one user, scale it. Talk about:

• Read versus write ratio. Most systems are read-heavy. Cache aggressively.
• Sharding. Where does the data split? By user ID? By geography?
• Replication. Sync or async? What happens during failover?
• Bottlenecks. Which component falls over first under load?

Name the tradeoffs out loud. “If I shard by user ID, follower lookups get expensive. I am accepting that because reads of a single user feed are more common.” Interviewers love hearing the tradeoff, not just the choice.

Step 6: Wrap with what you would do next

In the last two or three minutes, summarize. “I designed a feed system that handles 10k QPS using fanout-on-write with a Redis cache. The main risks are celebrity users and hot shards. If I had more time, I would design the rate limiter and the moderation pipeline.”

This ending signals senior thinking. You acknowledge what you did not cover. You name future work. You do not pretend the design is finished.

What to do when you get stuck

You will get stuck. Every candidate does. Here is the recovery sequence:

1. Restate the problem you are solving. Say it out loud. Often the answer falls out.
2. Ask the interviewer what they want to focus on. They are not adversaries. They will steer you.
3. Compare two approaches. If you cannot pick, list option A, option B, and the tradeoff. Choose one and move on.

Silence is the only fatal mistake. Even thinking out loud beats freezing.

Common mistakes that tank candidates

• Jumping to architecture before clarifying requirements
• Listing every technology you have ever heard of
• Designing for a billion users when the prompt said a thousand
• Drawing a beautiful diagram with no API behind it
• Refusing to commit to a choice when asked

The interview is a conversation about tradeoffs, not a quiz on AWS service names.

How to practice without a partner

Pick a real system you use daily. WhatsApp. Instagram. Uber. Spend 45 minutes designing it on paper. Then read an engineering blog post from that company about how they actually built it. Compare.

After ten of these, your instincts sharpen. You start recognizing patterns: write-heavy versus read-heavy, strong versus eventual consistency, hot keys, fanout.

Pair this with mock interviews if you can. Solo practice teaches you the framework. Mock interviews teach you to perform under pressure. If you are also prepping coding rounds, see dev interview prep basics for a broader study plan, and update your dev resume once you have a few system design projects to point to.

Wrap up

System design is not about knowing every technology. It is about thinking clearly under pressure and communicating tradeoffs. The framework gets you to the actual thinking faster.

Clarify, define the API, draw the architecture, go deep on one thing, address scale, summarize. Six steps. Run them every time. The prompts change. The shape of a good answer does not.