My overall strategy on this page is to 1) summarize information I find around the web, and then 2) try to weave the information I have in those summaries into unified processes for handling DSA questions, system design questions, API design questions, how to format a resume, etc.
Draw out a simple visual example.
Do it in something like Balsamiq.
Copy-paste it to visually show what the step-by-step process should look like.
Think about what variables you want at each step to answer the relevant question you have to be able to calculate the desired answer.
Ask yourself: What features of the state of each ‘step’ through the input can you think of to assign names to? Write the code needed to calculate/update these values with each iteration (or just have them as stub functions to be filled in later) and it could give you enough of a step in the right direction for the rest of the solution to make itself clear.
I have Neetcode questions in Anki.
I track which questions I’ve actually studied by checking them off on the Neetcode website.
I’m aiming to go through all questions of a type before moving onto the next type.
Creating Replit versions:
If I can’t access the question on Leetcode (it’s a premium question) or the Lintcode version (or if the Lintcode version is too different from the Leetcode question), I can create a Replit version in here.
Make the ‘template’ version of the question, then when you actually want to do the question, use that same Replit and you can just use the git feature to discard all of the changes you made to the code when you’re done.
What is the threshold at which point it's a good idea to create a class for a data structure?
Algorithms-Specific Informational Websites (not programming challenge websites)
Nick Parlante - Pointers, Binary Trees, etc.
Very good explanations
OK explanations
Books
Look good:
The Algorithm Design Manual by Skiena
Rec'd by Adam D'Angelo in a Quora post.
Essential Algorithms - 5 stars on O'Reilly
Working with Algorithms in Python - O'Reilly video series - 4.3 stars - Same guy who wrote 'Algorithms in a Nutshell'
Maybe good:
Meh:
Articles
http://haseebq.com/how-to-break-into-tech-job-hunting-and-interviews/
First, a high-level roadmap.
Watch the Princeton Coursera course on algorithms (by Robert Sedgewick), mostly up until Dijkstra’s algorithm and not much more than that. Try to follow along and code as you go. You don’t need to implement things in Java unless you already know Java.
Read The Algorithm Design Manual for general algorithms and data structures background. Go through most of it. (You can skip the giant appendix about specific algorithmic topics).
Buy Cracking the Coding Interview. We’ll be using this as a repository of coding problems and solutions.
(...)
If you’re working on an algorithms problem (such as out of CTCI) and can’t figure it out, spend no more than 20-30 minutes without making progress. Just go look up the answer. Contrary to popular belief, most struggling past 30 minutes is pointless.Some people will disagree with this. [NW: Like Tom and Chris Uga.]
Screw those people.
That said, if you find up having to look up the answer to more than 2/3rds of problems, your problem set is too hard and you need to downgrade.
But banging your head against a wall or staring blankly at code is a waste of time. For code/algorithms problems, you very much want to maximize the density of learning per hour.
Any time you look up the answer to a coding problem, try to understand the solution. Walk through it with a debugger if it’s particularly mysterious. Read multiple explanations of why it works.
Then—and this is extremely important—if you didn’t solve the problem completely on your own, treat the problem as though you never solved it at all. Put it back into your rotation of problems. Mark it as something you need to try again from scratch. Wait at least a day, and try to solve it fresh. If you fail, rinse and repeat ad infinitum.
And finally, structure the hell out of your learning. Make a schedule. Know exactly when you’re going to be working on this stuff, when you’re going to take breaks, when you’re going to go to lunch, etc. Build flexibility into your schedule, but have clear goals for how many hours a day you’ll spend studying.
Interview Challenge sites
this is by Kalzumeus
Front-end interview challenge / prep sites
Interview Prep sites
rec'd by Choketsu
Codility
Rec'd by Toptal
rec'd by Choketsu
via Tom A.
Non-Interview-Prep Challenge sites
Rec'd by Toptal
Someone who works with machine learning explaining how Kaggle is a simplification of real ML work:
Jason B Hill's Project Euler solutions
Rec'd by Toptal, Chris Uga
rec'd by Choketsu
How to get started training at the USACO Gateway:
What is it like to attend the USACO training camp?
It's only a week
New people just get 3 hours of lab/lecture in the morning
The top guys do a contest every day. Sometimes the contest goes until after lunch, otherwise they just review after lunch. (Seems like 5 hrs/day)
Then everyone has fun for the rest of the day
If one is stuck on a particular section, is it worthwhile to keep on trying to solve the given problem, or should one move on to other sources in preparation for programming contests?
Richard Peng, one of the most successful Canadian IOI competitors of all time, on the USACO training pages:
"USACO training was put together before the major IOI escalation (Finland/Korea/Wisconsin). A lot of the techniques described on it are no longer useful on *OI and a lot of the 'hot' topics over the past few years are not covered. Also, a lot of the bottle necks on training are quite meaningless, and they typically cause a lot of frustration and time waste on the scale of months."
Summary
1. What Are Algorithms and Why Should You Care?
2. How to Describe and Evaluate Computer Algorithms
3. Algorithms for Sorting and Searching
4. A Lower Bound for Sorting and How to Beat It
5. Directed Acyclic Graphs
6. Shortest Paths
7. Algorithms on Strings
8. Foundations of Cryptography
9. Data Compression
10. Hard? Problems
https://activities.tjhsst.edu/sct/lectures/0405/dp1.pdf
"Dynamic programming, often abbreviated "DP", is a technique to efficiently solve recursion problems -- problems whose solutions depend on solutions of smaller problems -- by storing partial results. Many times, it is obvious that a given problem is a recursion problem. However, it may not be so obvious that using DP will tremendously speed up the solution. We start by looking at an example."
http://seldo.com/weblog/2014/08/26/you_suck_at_technical_interviews
http://blog.triplebyte.com/how-to-pass-a-programming-interview
https://medium.com/@evnowandforever/f-you-i-quit-hiring-is-broken-bb8f3a48d324#.jhferyy53
Here is an explanation of how to programmatically create Anki deck packages: http://decks.wikia.com/wiki/Anki_APKG_format_documentation
Here's an example of people collaborating on an Anki deck: http://decks.wikia.com/wiki/Main_Page
Javascript problem manager: https://github.com/imaginate/algorithmIV-question-manager
Clarify the task.
Share what you know about the system with the interviewer.
If you’re not familiar with the system, tell the interviewer so they can explain how it should work.
Constrain the problem to make it solvable within the hour.
List the different metrics you could consider tracking / focusing on and explain the one you think we should focus on and why.
Total users, DAU, WAU, MAU. Maybe daily minutes per active user.
Uber: driver ratings, trip completion rates, and acceptance rates, number of rides completed per day, number of cancelled rides, number of rider complaints raised, average loading time, ratio of daily active users to monthly active users, number of daily rides booked per daily active user, average revenue per user, average wait time
Clarify the scale of usage, the amount of data involved, the rate of requests.
Specify some key metrics to help your high-level decision-making.
Example: the number of users, the amount of data.
Try to determine the number of requests per day, divide by 100,000 (seconds per day) to get the average requests per second, and take a guess at the peak factor (how much times the number of requests per second you might see in peak traffic), take a guess at how many requests per second a typical server might be able to handle (say, 1000), and use that to determine how many servers you’ll need.
It doesn’t have to be perfect, the idea is to see that you’re aware of these ideas.
If you’re going to be using auto-scaling servers, that’s fine.
(Source)
You don’t necessarily have to go into the details of scaling at this point.
Design the system at a high level.
At an early stage, it’s OK to have a few simple components; later on you can get more complex.
Example:
If asked to design Spotify, you could draw a mobile app connected to a load balancer which connects to a group of webservers, which connect to the database.
Outline your database design.
After laying out your components, design your database.
Split out databases appropriate for different types of data.
In general, try to explain why you’re doing something upfront rather than waiting for your interviewer to ask you.
Go through a normal use-cases and explain/flesh out how it will work in greater detail.
Consider how the webservers will retrieve data from the db and how they’ll send it to the end-user; will they use websockets?
If you have more time, think about how things could “go wrong” in terms of scaling.
Examples:
When designing Spotify, some songs might be requested by users for listening far more than others.
Solutions:
A CDN
Abbott & Fisher
https://www.amazon.com/API-Design-Patterns-JJ-Geewax/dp/161729585X
https://www.amazon.com/APIs-Strategy-Application-Programming-Interfaces/dp/1449308929/
The Art of Capacity Planning
Written by the manager of data operations for Flickr.com
First edition: https://www.amazon.com/Art-Capacity-Planning-Scaling-Resources/dp/0596518579
Second edition: https://www.amazon.com/Art-Capacity-Planning-Scaling-Resources-dp-1491939206/dp/1491939206/
ByteByteGo / Alex Xu
https://www.designgurus.io/ - Grokking the System Design Interview (online course)
https://www.amazon.com/Design-Web-APIs-Arnaud-Lauret/dp/1617295108/
https://www.amazon.com/Designing-Swagger-OpenAPI-Joshua-Ponelat/dp/1617296287/
https://www.amazon.com/Designing-Distributed-Systems-Patterns-Paradigms/dp/1491983647/
https://www.amazon.com/Designing-Web-APIs-Building-Developers/dp/1492026921/
microservice-api-patterns.org - This looks really interesting.
NeetCode system design courses - https://neetcode.io/courses
https://drive.google.com/file/d/1U7EchvgzCjTtF5JzGVVCFgjXC-qw7lIG/view?pli=1 ← They send you a link to this ebook when you sign up for their newsletter.
https://www.amazon.com/REST-Design-Rulebook-Mark-Masse/dp/1449310508/
https://www.algoexpert.io/systems/product
Negative review: https://www.reddit.com/r/cscareerquestions/comments/s0e54f/warning_systems_expert_by_the_algoexpert_guy_is/
“modules are very light on information, and you'd have a better time just reading the wikipedia page on those topics.”
“topics aren't well explained and it's just an extremely high level overview of what they are”
Udemy: https://www.udemy.com/courses/search/?src=ukw&q=system+design
https://www.amazon.com/Scalability-Startup-Engineers-Artur-Ejsmont/dp/0071843655
Summary
PART 1: INTRODUCTION
1 Introduction to APIs
2 Introduction to API design patterns
PART 2: DESIGN PRINCIPLES
3 Naming
4 Resource scope and hierarchy
5 Data types and defaults
PART 3: FUNDAMENTALS
6 Resource identification
7 Standard methods
8 Partial updates and retrievals
9 Custom methods
10 Long-running operations
11 Rerunnable jobs
PART 4: RESOURCE RELATIONSHIPS
12 Singleton sub-resources
13 Cross references
14 Association resources
15 Add and remove custom methods
16 Polymorphism
PART 5: COLLECTIVE OPERATIONS
17 Copy and move
18 Batch operations
19 Criteria-based deletion
20 Anonymous writes
21 Pagination
22 Filtering
23 Importing and exporting
PART 6: SAFETY AND SECURITY
24 Versioning and compatibility
25 Soft deletion
26 Request deduplication
27 Request validation
28 Resource revisions
29 Request retrial
30 Request authentication
Summary
PART 1 DESCRIBING APIS
1 Introducing APIs and OpenAPI
2 Getting set up to make API requests
3 Our first taste of OpenAPI definitions
4 Using Swagger Editor to write OpenAPI definitions
5 Describing API responses
6 Creating resources
7 Adding authentication and authorization
8 Preparing and hosting API documentation
PART 2 DESIGN-FIRST
9 Designing a web application
10 Creating an API design using OpenAPI
11 Building a change workflow around API design–first
12 Implementing frontend code and reacting to changes
13 Building a backend with Node.js and Swagger Codegen
14 Integrating and releasing the web application
PART 3 EXTENDING APIS
15 Designing the next API iteration
16 Designing schemas with composition in OpenAPI
17 Scaling collection endpoints with filters and pagination
18 Supporting the unhappy path: Error handling with problem+json
19 Improving input validation with advanced JSON Schema
20 Versioning an API and handling breaking changes
21 The API prerelease checklist
2023.03.10 - Design Spotify (with ex-Google EM)
Summary
He goes through the various use cases of Spotify he can think of, then asks which one he should focus on, which the interviewer limits to “finding and playing music”.
He asks how many users and how many songs the interviewer wants to support, then goes through some math to try to estimate how much data they’ll need to store, but he never ends up using that information later on.
He draws out a high-level diagram of the system: a phone connects to a load balancer which connects to a bunch of web servers which connect to a database.
He goes deeper on the database and explains that they’ll want to have a relational db for user metadata (AWS RDS) and blob storage for the songs (AWS S3). He then lists some example fields you might want to use for the song table in the relational db.
23:05 - He discusses how to send the audio data to the user, he initially suggests using websockets to send chunks to the webserver, then decides that for only 5mb it would be “almost instantaneous” to send data from S3 to the webservers, and would remove any lag from hitting the database. So that makes me wonder whether the S3 db would be at the same datacenter as the webservers and what kind of bandwidth you can get between them.
I’m interested in knowing the process for determining whether to chunk between the EC2 instance and the S3 bucket.
25:37 - After creating his relatively-simple design for Spotify, he asks himself, “What could go wrong here?” and realizes that certain songs/artists could be way more popular than others. To avoid wasting bandwidth, he recommends using a CDN (a cache).
33:00 - He’s talking about other types of caches: a cache layer between the db and the webservers (redis?), a local cache within each webserver, and then a cache within the phone app to store frequently-played songs.
35:20 - More on the load balancer - Normally load balancers strive to equalize the CPU load across servers, but for this app he might focus more on I/O and/or RAM usage; he’d want to make it smarter than a normal round-robin system. [NW: Can a load balancer dynamically divert traffic like that? That’s not how I thought they worked.]
38:20 - You may want to locate your replicas closer to the geographies where the data is more likely to be used.
Comments
Like many others I was designing my own version alongside Mark's and I think the area he was a little weaker in (which he himself admits) was load balancing. My background is systems administration so I may have a different perspective on this. I think going back a few steps, chunking the data also serves an important role in the load balancing process. I would have songs chunked, from every retrieval source, so that as soon as the user presses Play, the song begins playing, and playback should always be an instantaneous process unless the servers are over capacity, which can occur because some song or album has gone viral.
I would structure the web server load balancing so that client apps attempt to contact the server geographically closest to them first and utilize GSLB (global site load balancing) which combines layer 4 and layer 7 load balancing, as I/O capacity or concurrent connections (the two metrics I would prioritize) reach a threshold.
Again, when talking about load balancing, it's important to determine what happens when maximum capacity on all servers is exceeded. When this happens in my design, the system will issue "tickets" for data chunks, served in the order they arrive in. This is where song chunking comes into play. Because we are chunking the MP3 data, we can still serve the first chunk of the song from the nearest available server as soon as that I/O is available, further ensuring near-instantaneous playback upon pressing the Play button. The rest of the song then has some time to download and cache to the client device, reducing the number of interruptions and pauses in playback due to bandwidth and concurrent connection overages.
2023.06.30 - Design TikTok (with ex-Google EM)
He just straight up asks the interviewer what use case he wants him to focus on without describing anything about how the app works. The interviewer says he wants him to ignore how the app itself works and instead focus on the backend that handles uploading and downloading videos. He clarifies that the interviewer doesn’t want him to spend any time on how people will create accounts etc.
He asks the interviewer what scale / usage to build for and he’s told 1B users in 150 countries, 1B views per day, 10B videos uploaded in a year.
He asks the interviewer what kind of success metrics we should be aiming for and is asked to come up with them. He comes up with “time in app”.
He asks how much time we should expect an average active user to spend in the app, the interviewer says an hour.
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!
You can watch and read a lot of material and think you understand it, but still not be able to perform when it comes time to do it for real.
Practicing will also make you relax when you have a real interview.
If you don’t have another person or coach, just record yourself.
The English guy said his mom pointed out he touches his hair and face too much.
Don’t underestimate how much time it’ll take for a mock interview; if you want enough time for back-and-forth, you may want to block out 2 hours. 10 minutes for feedback is pretty tight.
Explain your thinking
Example: Don’t just say “I’m going to use a database”, or “I’m going to use a MySQL/relational db”; explain why you’re choosing the particular technology you’re using. “The data is pretty well structured, I’ll need multiple tables, do queries across the data (join tables)”.
You don’t want to come across like you’re repeating memorized solutions without understanding the pros and cons of the technology.
The interviewer wants to see how clearly you can communicate.
It’s could be fine if the interviewer doesn’t agree with your choice.
Get comfortable with the math.
They want to see that you can make some assumptions and do some really basic back-of-the-envelope math.
Make sure the interviewer can follow your math.
If you have a billion queries a day, with ~100,000 seconds in a day you’re dealing with ~10,000 requests per second.
I want to hear from you that you know about peaks (in traffic), that you’re aware of it. So a peak factor of 5 means you could hit 50,000 requests per second.
If a server can handle 1,000 requests per second, that means we need ~50 servers.
Get comfortable with the units for larger amounts of data (terabytes, petabytes, exabytes). Showing familiarity with that
Don’t get bits and bytes confused. Network bandwidth is measured in bits per second, data is measured in bytes. You can keep it simple by estimating 10 bits per byte instead of 8.
Using a calculator is fine.
Use the drawing tool efficiently.
Be aware of what drawing tool they’ll want you to use.
You might be able to negotiate with the recruiter about what tool you use.
You want to be able to draw things quickly.
You need to know how to draw three things:
Boxes
Arrows
Text
Colors are not important, perfectness of arrows is not important, the text just needs to be good enough that you can refer to it.
It just needs to be clear what you’re pointing at when you have your mouse over something.
You don’t want the interviewer to have to keep track of stuff in their head.
It’s totally fine to change your diagram.
2023.03.11 - NeetCode - 20 System Design Concepts Explained in 10 Minutes
Summary
Vertical Scaling - Adding more RAM or CPU to your server(s)
Horizontal Scaling - Adding more servers that replicate your app. This also adds fault tolerance, but it’s much more complicated.
Load Balancer - This is a server known as a reverse proxy to route traffic to your different app servers. To choose which server to send the request to you could use round robin or hash the request ID, or route to the nearest location if you have your servers located around the world.
CDN - A network of servers located around the world. They take files on your servers and copy them to the CDN servers. This can be done on a push or pull basis.
Caching - Creating copies of data so it can be re-fetched faster in the future. Browsers cache data from the internet on disk, but that can be expensive, so they’ll cache in memory, but that can also be expensive, so the computer will copy a subset of the data into the L1 / L2 / L3 CPU cache.
IP Address - How computers communicate.
TCP / IP - The Internet Protocol Suite. Also includes UDP. These are the rules that decide how we send data on the internet. Files are broken down into packets, the packets are numbered so they can be re-assembled. HTTP and Websockets are built on top of TCP / IP.
DNS - A decentralized service that that translates a domain name to an IP address. Your computer will cache the A Record so it doesn’t need to look up the IP address for every request.
HTTP - Why do we use HTTP to view websites? TCP is too low level. HTTP is an “application-layer protocol”. It follows the client-server model: a client will initiate a request, which includes two parts: a request header, which is like a shipping label on a package. The second part is the request body, which is like the package contents. There are multiple API patterns we can follow while using HTTP: REST, GraphQL, gRPC.
REST - A standardization aimed at making APIs stateless (i.e. a request can be diverted to any of numerous duplicated app servers). Includes ideas like a successful request should include a 200 header, a bad request gets a 400, and an error with the server gets a 500 response.
GraphQL - An API pattern introduced by Facebook in 2015. You can make a “query” and specify exactly which resources and which fields you want. This reduces the number of API requests needed and the amount of unnecessary data sent.
gRPC - An RPC (remote procedure call) API framework introduced by Google for server-to-server communication. gRPC Web lets you use gRPC from a browser. It has a performance boost over JSON because it converts the data to a compressed form in binary using a library called Protocol Buffers, but it’s not human-readable like JSON.
WebSocket - This is an API pattern helpful for stuff like chat apps where the client should be notified immediately of an update.
SQL - A db is better than storing stuff in plaintext files (like CSVs) because it allows for fast retrieval/querying of data.
ACID compliance - ACID (Atomicity, Consistency, Isolation, Durability) - Durability means the data will be there if the machine shuts down. Isolation means that different transactions won’t interfere with each other. Atomicity means that each transaction is all-or-nothing; you won’t have a partial transaction if the machine turns off in the middle of writing data. Consistency means that foreign key constraints will be enforced.
NoSQL databases - These dbs dropped the consistency constraint of SQL dbs and the idea of relations to make it easier to scale. Popular types are: key-value stores, document stores, and graph dbs. Not needing to worry about foreign key constraints means we can break up our data across different machines (sharding).
Sharding - This is when you break up your db. You split up the data based on a “shard key”, which can just be the ID of a user.
Replication - A simpler way to scale reads is to make copies of the entire database. When the copies are read-only, it’s called “leader-follower replication”. You can also do “leader-leader” replication but it can lead to inconsistencies, so it’s best to do it where you can ensure a given user will only be interacting with one of them, like if you have them in different regions in the world. It can be complicated to keep them in sync.
CAP thoerem - The idea that we have to choose between data consistency and data availability. It’s a somewhat controversial theorem, which led to the development of the PACELC theorem.
Message Queues - Kind of like db because they have durable storage, can be replicated / sharded. If your system is receiving more data than it can process, the queue can prevent requests from getting lost/dropped.
In summary: software engineering is all about storing and moving data around.
Key things I want to remember for the purposes of system design interviews:
Think about how you could break down an app into different services (e.g. login vs searching vs. completing a cart) hosted in different server pools, or how you could shard the data effectively (for example, maybe first by geography, then by user ID).
Summary / Notes
Reduce the Equation
Rule 1 - Don’t Overengineer the Solution
Rule 2 - Design Scale into the Solution (D-I-D Process) - Design for 20x capacity, Implement for 3x capacity, Deploy for ~1.5x capacity
Rule 3 - Simplify the Solution 3 Times Over
Rule 4 - Reduce DNS Lookups
Rule 5 - Reduce Objects Where Possible
Rule 6 - Use Homogenous Networks
Distribute Your Work
Rule 7 - Design to Clone Things (X Axis) - Be able to duplicate data/services
Rule 8 - Design to Split Different Things (Y Axis) - You can split up your app / data / servers based on either actions the user/app can take (“services”) or by data the app may need to access (“resources”).
Services examples - signup, login, search, browse, view, add-to-cart, purchase/buy - “The data needed to perform any one of these can vary from the data needed for the others”
Resources examples - product catalog, product inventory, user account information, marketing information
Rule 9 - Design to Split Similar Things (Z Axis) - Set data up into unique and separated shards or swimlanes - Separate the db / servers by things like customer ID, name, geography, etc.
Design to Scale Out Horizontally
Rule 10 - Design Your Solution to Scale Out--Not Just Up
Rule 11 - Use Commodity Systems (Goldfish Not Thoroughbreds)
Rule 12 - Scale Out Your Data Centers
Rule 13 - Design to Leverage the Cloud
Use the Right Tools
Rule 14 - Use Databases Appropriately
Rule 15 - Avoid Using Firewalls - Firewalls cause issues with scalability and availability, so only use them when they significantly reduce risk or are required for compliance.
Rule 16 - Actively Use Log Files
Don’t Duplicate Your Work
Rule 17 - Don’t Check Your Work - Don’t read data you just wrote unless it’s a regulatory / legal requirement, and if so, consider doing it asynchronously.
Rule 18 - Stop Redirecting Traffic
Rule 19 - Relax Temporal Constraints - For example, requiring items being available from when a viewer views them until they purchase them.
Use Caching Aggressively
Rule 20 - Use CDNs
Rule 21 - Use ‘Expires’ Headers
Rule 22 - Cache Ajax Calls
Rule 23 - Use Page Caches
Rule 24 - Use Application Caches
Rule 25 - Use Object Caches - These are used for data that may be expensive to regenerate, like the result set of complex db queries.
Rule 26 - Put Object Caches on Their Own Servers
They have a diagram of multiple web servers connecting to an application server object cache, which connects to multiple app servers, which connect to a db object cache, which connects to db servers.
They use the word “tier” to refer to these servers being another entire row in their diagram.
Learn from Your Mistakes
Rule 27 - Learn Aggressively - Use A/B testing, postmortems.
Rule 28 - Don’t Rely on QA to Find Mistakes
Rule 29 - Failing to Design for Rollback Is Designing for Failure - Practice rolling back in staging or QA.
Rule 30 - Discuss and Learn from Failures - Do postmortems
Database Rules
Rule 31 - Be Aware of Costly Relationships
Rule 32 - Use the Right Type of Database Lock
Rule 33 - Don’t Use Multiphase Commits
Rule 34 - Try Not to Use “Select for Update”
Rule 35 - Don’t Select Everything
Design for Fault Tolerance and Graceful Failure
Rule 36 - Design Using Fault Isolative “Swimlanes”
Rule 37 - Never Trust Single Points of Failure - Identify single instances on design diagrams and try to turn them into active/active configurations.
Rule 38 - Avoid Putting Systems in Series
Rule 39 - Ensure You Can Wire On and Off Functions
Avoid or Distribute State
Rule 40 - Strive for Statelessness
Rule 41 - Maintain Sessions in the Browser When Possible - Use cookies, this lets the user request be served by any web server in the pool.
Rule 42 - Use a Distributed Cache for States
Asynchronous Communication and Message Buses
Rule 43 - Communicate Asynchronously As Much As Possible
Rule 44 - Make Sure Your Message Bus Can Scale
Rule 45 - Avoid Overcrowding Your Message Bus
Miscellaneous Rules
Rule 46 - Be Wary of Scaling Through Third Parties - Own your destiny, reduce your total cost of ownership.
Rule 47 - Purge, Archive, and Cost-Justify Storage
Rule 48 - Remove Business Intelligence from Transaction Processing
Rule 49 - Design Your Application to Be Monitored
Rule 50 - Be Competent
Rule Review and Prioritization
I’ve added the mentioned resources to the “learning resources” section on this page, but the most-common recommendations were the GitHub primer and the DDIA book.
https://medium.com/javarevisited/7-best-places-to-learn-system-design-79e2d261f343
TODO: Go through this.
API design patterns
Searching Google for “api patterns” turns up a lot of results.
https://www.linkedin.com/pulse/api-design-patterns-best-practices-building-robust-apis/
This looks like a good article.
CAP theorem
https://stackoverflow.com/questions/12346326/cap-theorem-availability-and-partition-tolerance
Lessons from Giant Scale Services – My understanding is that this is the original CAP theorem paper.
https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/
Command and Query Responsibility Segregation (CQRS) - A fancy term for separating the read and write parts of the API so you can scale them separately.
Databases
GraphQL
This is an API pattern, an alternative to REST.
gRPC
This is an API pattern, an alternative to REST.
Message queues
PACELC theorem
Motivation: The goal here isn’t to make fun of the people shown here, but to criticize the way interviews are done today, by showing that smart, productive people don’t have to come into the job already knowing everything about everything to do their job well; people can research issues/decisions as they come up, or read books to get onboarded. I want to be able to point to examples when I tell people that the degree of strictness used to evaluate candidates in these interviews is not helping select better engineers. There are other attributes that matter more than whether a person has managed to memorize everything about system design, data structures, and algorithms. Using these tests as a proxy for “determination” isn’t ideal, because a person can be determined to get the job offer but end up hating the actual work. That’s why you’ll see guys totally determined to become Navy SEALs and then drop out of the teams when it turns out they’re tasked with working as bodyguards and have to spend a lot of time away from their family, or you’ll see people totally determined to get into FAANG and then quit because of the lack of work/life balance. It would be better to just try to be very open with candidates about the work, maybe make it easy for them to get a taste of the lifestyle, and then just try to predict who is going to put in the time necessary to do a good job and isn’t going to quit.
Design Spotify (with ex-Google EM) - He was an engineering manager for 13 years at Google and then 2 years at Uber. He doesn’t know that a CDN generally acts as the DNS and sits in front of the load balancer; he has an arrow pointing from the CDN to the db and another from the CDN to the webservers (rather than the load balancer). He thinks the the webserver would actively dictate when songs should start getting cached instead of the CDN using a static configuration with a heuristic like Least-Frequently-Used to determine what to cache. He says the web server would send a message to the user to redirect them to the CDN.
31:50 - He thinks Flask might be the name of a CDN. He can’t name CloudFlare as an example of CDN.
Stuff to maybe include on a second page of your resume:
Locations you’re open to working - Countries, states, cities; fully in-office, hybrid, remote.
References - name, the job you worked with them at, their contact info, maybe something impressive about them to add weight to their recommendation.
Continuing education (books/courses you’ve read and summarized, with links to your summaries).
https://www.amazon.com/Google-R%C3%A9sum%C3%A9-Prepare-Microsoft-Company/dp/151138459X
Thoughts:
Despite the name of the book, from reading the chapter listing it seems to not really be focused on resumes.
From reading the chapter on the resume, while I can say it’s certainly better than nothing and could be helpful for a new college grad, it’s like a LinkedIn post in depth, and IMO doesn’t really earn the title of the book (“The Google Resume”).
Reviews
Negative
Content of the book is 90% of 'How to Get a Job' another million of books.
doesn't tell you anything that you already don't know by common knowledge
Summary / Notes
Not resume-related: Chapter 1 - Introduction, Chapter 2 - Advanced Preparation, Chapter 3 - Getting in the Door
Chapter 4 - Resumes
Six Hallmarks of a Powerful Resume
Accomplishment Oriented - Everyone wants an employee who “gets things done”.
Quantified Results - Listing accomplishments without the numbers may make them harder to evaluate. Quantifying results with dollars will make the strongest impact.
Well-Targeted - Tailor your resume to the position: mention experience relevant to what they’re looking for.
Universally Meaningful - Avoid technical jargon, acronyms; use plain English.
Clean, Professional, Concise
Well-Structured and Clear
The Structure
The Objective
Summary / Key Accomplishments
Work Experience
Projects
Education
Skills
Awards & Honors
What Not to Include
How Long is Too Long? - People with less than 5-10 years of experience should stick to one page.
Your Questions Answered
Q: Can I add an explanation for a gap in my resume to my resume?
A: Personal details can be TMI; the resume should focus on what you actually did.
Q: Should I not list my GPA if it’s low?
A: It’s normal not to list your GPA if it’s below 3.0. If it’s been improving every year and more-recent years are above 3.0, you can list the more-recent years.
Q: Can I use more than one page if I need it, even if I don’t have many years of work experience?
A: Yes but you risk frustrating/annoying the recruiter; just focus on the best, most-relevant accomplishments.
Chapter 5 - Deconstructing the Resume
Resume A: Bill Jobs
Resume B: Steve Gates
Resume C: Geena Roberts
Parting Words
Additional Resources
Chapter 6 - Cover Letters and References
Not resume-related: Chapter 7 - Interview Prep and Overview, Chapter 8 - Interview Questions, Chapter 9 - The Programming Interview, Chapter 10 - Getting into Gaming, Chapter 11 - The Offer, Chapter 12 - On the Job, Chapter 13 - Final Thoughts: Luck, Determination, and What You Can Do
Appendix A - 156 Action Words to Make Your Resume Jump
Appendix B - Answers to Behavioral Interview Questions
IGotAnOffer
Engineering resume review (with top ex-Google recruiter)
The format doesn’t matter.
The top (first page) is the prime real estate.
Page 2, page 3 are less valuable real estate, it’s stuff the recruiter might look at.
Aim to answer recruiters' questions as quickly as possible.
We want the resume to be easy-to-read.
You don’t need your full address.
Include your name, contact info, LinkedIn, locations you’re open to working (countries/cities, hybrid, remote).
Don’t have “fluff” that doesn’t really say anything: “keen to learn and extremely adaptable” is something anyone can say. Give specific achievements.
Recruiters may have requirements for a certain number of years of experience with certain tech, so make it easy for them to answer that question.
NW: maybe have a table of tech with years of experience on a second page?
“Numbers tell a better story”, “we want to see impact/result”
NW: How do they verify the numbers?
How many designs and iterations? How many implementations?
I built X product, X revenue, X traffic.
If you’re a great manager, what was your attrition rate over five years? (10% is incredible)
We want it to be the most-groundbreaking thing you did; only include your most impressive achievements.
If you feel like you haven’t done anything earth-shattering, just include whatever numbers you have available.
“It’s ok because I at least have an impact that you’re making, and that’s what we wanna communicate: our impact and why we’re valuable.”
NW: This guy really strikes me as someone who hasn’t thought deeply about how to do his job.
It’s OK to talk about what you did at your uni / internships.
I don’t want to have to dig for:
how many years of experience you have in the industry
how many years of experience you have in management
Let’s stick to what you did as a manager that was impactful. What things did your team deliver, what was the impact, what was the result, tell me through numbers.
It’s not helpful to list numbers for non-outstanding/unimpressive work/results, like: “Interviewed 250 people, hired X people, promoted X people”.
I want to see those two-to-three bullet points that make my jaw drop and say “Wow”.
Comments:
If [recruiters are] in the process it's prudent to write two resumes: one technical, for engineers, and one for HR. E.g. skip LinkedIn on the technical version and include links to code. It's stronger than easily-fluffed numbers on the resume.
This is exactly what I’m thinking. People can just make up numbers, but if that’s how nontechnical recruiters are choosing between resumes, then you’ll want to do what they’re looking for until you can get to someone who actually knows how to evaluate your “real” resume.