Quick Start

Common Mistakes

Harold

— 3 min read
Share
Common Mistakes 
Most candidates do not fail system design interviews because they do not know enough technologies.
They fail because their answer is unclear, unstructured, or too shallow.

Mistake 1: Starting with a diagram too early

Many candidates hear the prompt and immediately start drawing boxes.

This is risky.

If you do not clarify the problem first, you may design the wrong system.

For example, “Design a news feed” can mean many different things:

  • Is it for friends only or public creators?
  • Is ranking required?
  • Is real-time delivery required?
  • How many users are active per day?
  • Is the feed read-heavy or write-heavy?

If you skip these questions, your design may miss the real problem.

Better approach:

Before I jump into the design, I’d like to clarify the core features and scale.

Mistake 2: Over-optimizing the high-level design

Some candidates add everything in the first diagram:

CDN
Cache
Message Queue
Kafka
Sharding
Read replicas
Search index
Rate limiter

This may look advanced, but it often hurts the answer.

Why?

Because the interviewer cannot see your thinking.

A better approach is:

  1. Start with a simple design.
  2. Explain the bottleneck.
  3. Add one improvement at a time.
  4. Explain the tradeoff.

For example:

The simple read path hits the database every time. That will not work at high read traffic, so I would add a cache. Since this data is mostly immutable, caching is a good fit.

This sounds much more thoughtful.

Mistake 3: Only naming technologies

Saying “use Redis” is not enough.

The interviewer wants to know why and how.

Weak answer:

I’ll add Redis.

Better answer:

I’ll add Redis as a cache in front of the database. The read path checks Redis first, and on a cache miss, it reads from the database and fills the cache. This works well because the data is read-heavy. The tradeoff is cache freshness, so we need a TTL or invalidation strategy.

The second answer shows understanding.

Mistake 4: No tradeoff discussion

Every design choice has a cost.

If you do not mention tradeoffs, your answer may sound memorized.

Examples:

  • Cache improves latency, but can create stale data.
  • Message queue improves reliability, but adds delay.
  • Strong consistency prevents conflicts, but may reduce availability.
  • Sharding increases capacity, but adds operational complexity.
  • CDN improves global latency, but may reduce control over dynamic content.

A useful phrase:

The tradeoff here is...

Use it often.

Mistake 5: Spending too much time on requirements

Requirements are important, but do not spend 15 minutes there.

In most 50-minute interviews, 5 minutes is enough.

Ask the key questions, define scope, and move on.

If you are unsure, say:

I’ll make a reasonable assumption here, and we can adjust if needed.

This keeps the interview moving.

Mistake 6: Deep dives are too shallow

Deep dive is where the interviewer decides if you really understand the system.

A shallow answer sounds like this:

We can scale it with cache and sharding.

A stronger answer sounds like this:

The first bottleneck is the database read path. I would add a cache for hot keys. If the cache hit rate is 99%, the database only sees 1% of read traffic. For storage growth, I would shard by short code. This gives a fairly even distribution, but cross-shard queries become harder.

The strong answer explains:

  • the bottleneck,
  • the fix,
  • why it works,
  • and the tradeoff.

Mistake 7: Not checking in with the interviewer

System design is a discussion, not a lecture.

You should check in from time to time.

Useful phrases:

  • Does this scope sound reasonable?
  • Would you like me to go deeper into the read path or the write path?
  • I’ll focus on latency first unless you prefer availability.
  • Is it okay if I assume eventual consistency here?

These small phrases make the interview feel collaborative.

Final takeaway

The strongest candidates are not the ones who know the most buzzwords.

They are the ones who can explain a system clearly.

Avoid these mistakes:

  • jumping into design,
  • overloading the first diagram,
  • naming tools without explaining them,
  • skipping tradeoffs,
  • losing time,
  • and giving shallow deep dives.

A clear, simple answer with good tradeoffs is better than a complicated answer that is hard to follow.

Read more