Stop Parroting YouTube solutions in System Design Interviews

5 common mistakes in system design interviews and how to avoid them

As a seasoned interviewer with 100s of system design interviews, I see some mistakes happen all the time.

---

There are a lot of resources on system design interviews. Many candidates focus on following the "YouTube" format instead of actually solving the problem. They follow the same “requirements, calculations, data schema, load balancers and API design“ format robotically. They won’t adapt to the problem at hand.

As a result, even good engineers end up failing their system design interviews.

---

If you have a system design interview coming up, remember to avoid these 5 common mistakes.

I will use the URL shortener problem to make my suggestions, as most people are already familiar with the problem.

This topic is too big to cover in a single post. So, I will focus on the most common mistakes for now, giving practical tips.

⏳ 1. Not prioritizing the scenarios

Interviews run only for 45 mins / 60 mins. You need to focus on discussing the important aspects of the problem, but sometimes candidates spend a lot of time on irrelevant scenarios.

Example

• Candidates talk at length about user registration for a question like ‘designing Snapchat’

• They spend too much time discussing security, rate limiting, or load balancers instead of focusing on the P0s.

• Spend a lot of time repeating the requirements without uncovering new information.

Recommendation

Take your time understanding the nuances of the requirements and surface the P0s.

• Keep a section on the whiteboard to list out all requirements that pop in your head.

  • It’s ok if you don’t get ALL requirements upfront. Add them as you think about them.

  • Annotate the P0s. That lets your interviewer and you align on the priorities

• Quickly talk through the core scenarios one level deeper. That will expand your thinking. For URL shortener:

  • [P0] Create short URL from long URL. One level deeper:

    • “Web page(P0) or browser plug-in or a phone app or a programmatic api that can take a long URL and create a short one”.

    • “Once the short url is created, it should be available for redirection”

      • This tells your brain to define the acceptable latency between creation and usage. Also once it is created it should be durable.

  • [P0] Redirect short URLs. One level deeper:

    • “Visiting the short URL should redirect quickly to the long URL”

      • This tells you to not only define the latency but also that your design should perform a fast lookup.

    • “Read heavy system as URLs are redirected a lot more than created.”

    • “When shared by influencers, it will increase load”

  • Analytics, custom short URL, update support & TTLs. Check if your interviewer wants you to cover any of these. Focus on the P0s first.

🔢 2. Talk about non-functional requirements in abstract

Saying "Highly available, strongly consistent, CAP, realtime, etc." does not add value to the discussion unless it is about a specific scenario.

Candidates are wasting valuable time and the interviewer gets no real signal.

Tbh, avoid talking about the CAP theorem if you are discussing product APIs and not delving into hardcore distributed systems.

Recommendation

Be specific and explain your numbers instead of using jargon. For the URL shortener problem you can say

• The URL redirection needs to have 99.999…% availability and success.

  • People would be using the shortened links in critical path and if the links don’t work they will take their business elsewhere

• Creating short URL is important but we can afford more failures.

  • People creating the short URL would be more willing to retry

• Eventual Consistency with a relaxed threshold for creations.

  • As short URLs are created by humans, a couple of seconds of latency would be acceptable before they can be used globally.

• Once a short URL is created we cannot lose it ever (unless there is a TTL)

🤿 3. Shallow design implementation

• Candidates hand wave the business logic by saying the “REST API will be handled by the ‘server’ and the result will be written ‘to the database’”.

• They draw arrows showing request flows from the browser to gateway / load balancers to server to DB and stop.

• Define DB schema in abstract.

As an interviewer, I would like to also see candidates find the hot spots or failure cases in the system. Those open up further discussion. However, until the nuances of the implementation are outlined, those issues won’t be visible to you.

Recommendation

Here is how you can unlock your critical thinking and add depth to your answers

• Short URL creation API needs to create a short URL from the long URL. But dig in.

  • How is the short unique string generated? How long should it be? Where is the short URL stored and how can the redirect API find it fast? How to scale creations when a large number is created per second?

• Redirection API would take in the short URL code and send back HTTP redirect. But dig in.

  • Fetching from the storage would be slow? An in memory cache helps? Does the full cache fit on a single machine? Do you need a distributed cache? What is the load when a celebrity shares a short url?

• When you list these questions, you generate more problems to solve. That begins to add details to the discussion.

Similarly, if a different problem involves async APIs then think about what is stored in the queue, how will the user be notified of request status.

Once you have these details, you can actually create a data model to support the business logic. Get into the details of the key parameters for the API, data model of the queue, and data references across storage systems.

⚖️ 4. Superficial trade offs

Interviewers are really trying to understand how you evaluate different options. They would be ok accepting a “suboptimal” solution if candidates clearly explains the constraints. Trade offs help differentiate a junior from a senior and a senior from a staff.

Interviewees talk about horizontal vs vertical scaling, sharding the DB, replication, etc. However, these are generic points. They are not useful until you connect them to the scenarios.

Recommendation

• Talk about design choices that can impact redirection latency. Eg: TTL & proximity of the cache. How to favor popular URLs and its impact on latency and cost.

• Talk about scaling creations with various ways of sharding or hashing.

• Don’t spend more time on wrong trade offs. Eg: Creating a short url from the browser should be quick so considering async API is unnecessary.

Another common mistake is wrong SQL vs NoSQL trade offs. Some assume SQL DBs are “slow” and undervalue the benefits of a strongly consistent schema. It is ok to pick a tech that you had experience with and call out the pros & cons.

🚫 5. Irrelevant Failure discussions

The quality of failures & trade offs you call out demonstrates seniority.

In most cases, interviewers don’t get any signal when candidates talk about hardware failures, database failover, generic overload, load balancer failures, authentication failures, etc.

Recommendation

Talk about failures for the “core scenarios” first. For URL shortener, large scale redirection failures are catastrophic. So think about which component failure can cause it or if the design already handles those failures:

• Browser & edge caching can reduce load on the system

• Large amounts of cache misses of short URLs could overload the DB. Talk about how you would run a degraded experience.

• How you communicate internal error vs short URLs that never existed.

Both trade-offs and failure handling take practice to build the right mindset.

• Make notes of important and unimportant trade-offs and failures across different problems. That should improve your knowledge.

• Experience helps. Though it’s ok if you don’t have it. You can read system design decisions and mistakes made by companies.

🎁 Bonus: Not admitting what you don’t know.

When you hide the lack of your knowledge, the interviewer will keep asking questions and you risk saying the wrong things. Though when you are open about it, the interviewer will actually share information that should help you make decisions.

🌟 Parting thoughts

I do encourage you’ll to solve varied questions and learn from them. Remember the following to avoid making the common mistakes:

• Solve the question as if you were solving a real problem and adapt your approach to the problem.

• Start with simplicity and paint a holistic picture of the solution space. Then delve deeper into the P0 scenarios.

• For most problems, discuss the data schema after you have ironed out the core scenarios and implementation details.

• Trade-offs and handling failures demonstrate your seniority, so invest in them.

• Record yourself and evaluate if you are making the aforementioned mistakes.

---

Thank you for reading and getting this newsletter to 3.2k+ subscribers.

If you enjoyed this article then hit the ❤️ button. It really helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

---

📣 Level Up

My friend,

Jordan Cutler

, has an upcoming course for mid level engineers to level up. Jordan has done this in just 2 years and has actionable tips for you all.

If you use this affiliate link, you can get a 25% discount until November 20th, and 10% after that. Sign up fast!

---

📚 Resources

• ByteByteGo Newsletter

• System Design Newsletter

• Engineer’s Codex

• Gaurav Sen’s YouTube channel

• Engineering Blogs if you have the time

If you have more suggestions then share them in the comments.