Skip to content

Latest commit

 

History

History
83 lines (80 loc) · 9.3 KB

README.md

File metadata and controls

83 lines (80 loc) · 9.3 KB
Raw

Preparing for the Google System Design Interview

Studying for system design interviews are only necessary if you are targeting L5+ at Google.

Prerequisites

  • Go through the Grokking the System Design Interview online course.
    • This will get you familiar with the core concepts and the most popular system design questions. These questions are still asked regularly.
    • This course only covers the basics. Regurgitating these answers in an interview will not be enough to pass a Google system design interview.

Outline for System Design Problems

  • Follow this outline when solving system design questions.
    • Not all the topics in the outline are required. Depending on the problem, some topics are more relevant than others.
    • At Google, we write design documentation before we start implementing features. This outline is very similar to how we approach the design process. The system design interview very much emulates how we work at Google.

Tips for Success

  • Spend at least a couple minutes digging into the requirements so you are building the right system. Interviewees can get carried away building systems that the interviewer did not ask for. This part is important in highlighting your user empathy.
  • When asked to design a system, immediately start thinking about, "What is the Google-scale problem or bottleneck that needs to be solved?" For example:
    • When you're asked to design Ticketmaster, don't waste your time designing the frontend. Most of your design focus should be on, "How will my system handle the massive spike in requests at the opening minutes to an extremely popular show?"
    • When you're asked to design a leaderboard, focus on, "How will I update someone's rank amongst 10 million+ players? On top of that, how do I keep up with updating rankings for 500,000+ active players that are playing right now?"
  • Throughout the discussion, always mention trade-offs. Discuss alternative approaches and the pros and cons of each approach. Next, explain why one approach is ideal for the given problem. Even if you believe certain alternatives are obviously bad approaches, at least mention it and explain why.
  • Interviewers will expect you to drive the discussion. You shouldn't be waiting for the interviewer to ask you questions. At Google, we come up with an end-to-end solution (as I mentioned, covering a lot of the topics in this outline) and present it to other engineers during a design review for discussion and approval. If you feel you're at a fork in the road, you can always ask, "Would you like me to dig into this aspect further or move on to something else?"
  • Remember to tie everything back to the requirements (user goals). Don't overdesign a system that isn't core to the problem. Again, remember to build the right system the interviewer asked for.

Practice

Mock Interviews

Practicing with mock interviews is mandatory. I cannot stress this enough. You have to build the habits necessary to tell a complete story without missing the key talking points. Practice is the only way you will get the pacing down on how much time to spend in each section and still leave enough room for general questions. You will not be able to attain that without regular practice.

Mock interview resources:

  • Technical Mock Interview
    • This is a paid service with high quality interviewers from Google, Facebook, and Amazon with detailed verbal/written feedback and personalized coaching. I strongly recommend doing at least 7 mocks through here.
  • Friends and colleagues
    • Find other engineers to practice with. Start an interview club with your friends. Meet weekly to go through readings and videos together.
  • Mentor
    • Find a mentor. Reach out to other software engineers you respect. Ask them to meet with you regularly for mentoring sessions.

Recommended Order of Reading

  1. Building Software Systems At Google and Lessons Learned - Jeff Dean Video
  2. What happens when you type google.com into your browser?
  3. Designing Data-Intensive Applications, Chapters 1-2: Reliable, Scalable, and Maintainable Applications; Data Models and Query Languages
  4. System Design Numbers - My Notes
  5. Designing Data-Intensive Applications, Chapter 3: Storage and Retrieval
  6. Caching - My Notes
  7. Designing Data-Intensive Applications, Chapter 4: Encoding and Evolution
  8. Designing Data-Intensive Applications, Chapter 5: Replication
  9. Raft: Understandable Distributed Consensus - Animation
  10. Designing Data-Intensive Applications, Chapter 6: Partitioning
  11. Consistent Hashing - Wikipedia
  12. Rendezvous Hashing - Wikipedia
  13. Designing Data-Intensive Applications, Chapter 7: Transactions
  14. The Google File System
  15. Chubby: A Lock Service for Loosely-Coupled Distributed Systems
  16. Designing Data-Intensive Applications, Chapter 10: Batch Processing
    • TODO on My Notes
  17. MapReduce: Simplified Data Processing on Large Clusters
  18. Bigtable: A Distributed Storage System for Structured Data
  19. Designing Data-Intensive Applications, Chapter 11: Stream Processing
  20. Google: the Anatomy of a Large-Scale Hypertextual Web Search Engine
  21. Spanner: Google's Globally-Distributed Database
    • TODO on My Notes

Additional Reading

Resources

License

I am providing code and resources in this repository to you under an open source license. Because this is my personal repository, the license you receive to my code and resources is from me and not my employer (Google).

Copyright 2019 John Sangki Lee

Creative Commons Attribution 4.0 International License (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/