Interview knowledge

System Design interview

Establishedest.Started 21 Aug 20264 min read#interviewing#system-design

System Design

Methodology

Framework

Allocate specific time slots: 5m for requirements, 20m for high-level design, 15m for deep dive, and 5m for wrapping up.

  • Define requirements and use cases
    • functional requirements first, and non-functional requirements if obvious
      • a good framing could be: "users should be able to..."
      • Start with the simplest happy path, then deep dive later
    • add more non-functional requirements if you think about them later
      • consistency Vs availability
        • On that example, clarify the priority in the context.
          • For example with Ticketmaster, consistency is way more important, but for rate limiters, availability is more important
      • read vs write ratio
      • access pattern (hot vs cold)
    • narrow down scope and verify with interviewer
      • you can suggest cutting down scope too
  • List core entities
    • Quickly list the data and its type
    • Don't write proper models yet until fleshed out further or prompted
  • Find rough load parameters to get an idea of the scale
    • Do maths estimations only if it servers a purpose. Do it only if it changes your design
      • Ie if the data is big enough to force a database sharing or if one database is enough.
    • Things like
      • How many users
      • Amount of data
    • Practicing quick maths will help here
  • Layout simple high level components, avoid early optimisation
  • Deep dive
    • Mention example technology, ideally more in the deep dive section
      • mention if used to or not used to a certain technology sometimes
    • propose multiple solutions, and discuss trade-offs with data
    • Show understanding between complexity and scale.
      • match system design to actual scale (ie, only bring sharding if necessary)
  • Wrap Up
    • Run through a use case once components are layed out, test your own setup
      • Question to ask at the end: did all the agreed requirements and non functional requirements pass with the design and the use cases run-through?
    • If not and time is up, probably highlight what you'd look into next
    • Think about what could go wrong, and list some obvious edge cases you can think of
      • What if all users want the same thing as a spike
    • Introduce new dimension or directions it could go at the end
    • Consider challenging your own design with different axes
      • Scalability
      • Maintainability

Things to keep in mind

  • lead the conversation but keep it a conversation: avoid asking them for insight if you're stuck, that might be interpreted as you're not senior enough
    • Take notes, make assumptions, lay them out and verify them sometimes
    • List what's involved, share your knowledge of the existing thing and ask if anything needs to be corrected
    • Ask where to focus on or deep dive once you have a few options, with a possibility to start with your preference
  • Try to be upfront on decision making
  • SQL vs NoSQL is not that interesting of a chat, especially as a senior
    • What's more interesting is whether you need consistency and ACID (both can do that well these days), the use cases (ie search or caching) and the context
  • Get familiar with tools like excalidraw
  • Don't just write low latency, specify a number if you do
  • Expectations
    • Seniors are expected to be more proactive with issues and limitations like a single refis is not enough
    • Staff could explain stories on how they had to deal with similar scenarios, what they did and learned
  • Don't use memorised answers

What gets assessed

Problem Navigation, Solution Design, Technical Excellence, and Communication and Collaboration
Pasted image 20260828201738.png

Problem navigation

You should be able to break down the problem into smaller, more manageable pieces, prioritize the most important ones, and then navigate through those pieces to a solution

The most common ways that candidates fail with this competency are:

  • Insufficiently exploring the problem and gathering requirements.
  • Focusing on uninteresting/trivial aspects of the problem vs the most important ones.
  • Getting stuck on a particular piece of the problem and not being able to move forward.
  • Failing to deliver a working system.

Solution design

The most common ways that candidates fail with this competency are:

  • Not having a strong enough understanding of the core concepts to solve the problem.
  • Ignoring scaling and performance considerations.
  • "Spaghetti design" - a solution that is not well-structured and difficult to understand.

Other tips

  • KISS: don't overengineer, explain the simplest solution first
  • Lead the conversation, but keep it conversational
  • Use a physical board when in person
  • Time management: leave time for discussion of the solution and next steps (potential latency issues, scalability, etc)

Resource

Blog

https://www.hellointerview.com/learn/system-design/in-a-hurry/introduction

Video

In this topic

  • System DesignEstablished

    Hello interview in a hurry is the best resource: https://www.hellointerview.com/learn/system-design/in-a-hurry/introduction. Book - Designing Data-Intensive Applications (haven't extracted all notes yet)

Sources