Versions Compared

Old Version 55

changes.mady.by.user Nathan Wailes

Saved on

compared with

New Version 56

changes.mady.by.user Nathan Wailes

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

Algorithms-Specific Informational Websites (not programming challenge websites)

...

Interview Prep sites

Non-Interview-Prep Challenge sites

Topics

Linked Lists

...

System Design

Step-by-step process

  1. Ask clarifying questions. (Source)

    Constrain the problem to make it solvable within the hour

    Clarify the task.

    1. Share what you know about the system with the interviewer.

    2. If you’re not familiar with the system, tell the interviewer so they can fill you in.

    Metrics

    1. Specify some key metrics to help your high-level decision-making.

      Example

      explain how it should work.

    2. Constrain the problem to make it solvable within the hour.

  2. Clarify the scale of usage, the amount of data involved, the rate of requests.

    1. Specify some key metrics to help your high-level decision-making.

      1. Example: the number of users, the amount of data.

    2. You don’t necessarily have to go into the details of scaling at this point.

  3. Design the system at a high level.

    1. At an early stage, it’s OK to have a few simple components; later on you can get more complex.

    2. Example:

      1. Design Spotify: “A If asked to design Spotify, you could draw a mobile app connects connected to a load balancer which connects to multiple a group of webservers, which connect to the database.”

  4. Outline your database design.

    1. After laying out your components, design your database.

    2. Split out databases appropriate for different types of data.

    3. In general, try to explain why you’re doing something upfront rather than waiting for your interviewer to ask you.

Learning resources

...

  1. Go through particular use-cases and explain how it will work.

    1. Consider how the webservers will retrieve data from the db and how they’ll send it to the end-user; will they use websockets?

Learning resources

Designing Data-Intensive Applications

IGotAnOffer

  • System Design Interviews: 10 Key Principles (with ex-Google EM)

    • Communicate efficiently.

      • The interview is definitely an artificially time-constrained environment.

      • So you need to be efficient. You don’t want the interviewer wondering what you’re thinking. You want the interviewer to be able to follow your thinking.

      • They work with a lot of engineers who understand the technical part but struggle to clearly communicate what they’re thinking.

    • Scope the problem.

      • Real systems (like YouTube) are too complicated to fully design in a one-hour interview.

      • So you need to ask, “Which part of the app/feature-set should I focus on?”

      • You need to go along with what the interviewer wants to focus on.

    • Start drawing ~15 minutes in

      • This isn’t a hard number, it’s just a guideline.

      • If you start drawing too soon, you may not fully understand what the interviewer wants you to focus on, and start going down a wrong path.

      • If you wait too long, you may not have enough time to come up with a working solution.

      • The interviewer says that in one mock the Google EM didn’t start until 20 minutes in and would’ve been struggling to finish.

    • Start with a simple design

      • Don’t add requirements that don’t exist.

        • Example: Adding tiering storage could prevent you from having a complete solution by the end of the interviewer.

      • You can tell the interviewer that a particular optimization is available and how you’d use it, but don’t let it stop you.

      • If the interviewer asks you to go deeper on a subject, follow their lead.

    • Use prep resources

      • GitHub has a system design study guide, for example

      • You might see some differences across guides

    • Properly understand the problem

      • Talk through specific use cases.

      • Imagine actually calling the API.

      • Try to catch assumptions you may have made.

      • Check in with the interviewer to see if you’re on the right path.

      • He mentions the name of the doc used for a full spec is “PRD” - Product Requirements Document

    • Practice, practice, practice!

System Design Primer

Articles / Forum posts

...