I am giving up on system design interviews...
As a senior developer, I have a lot of experience creating tiny projects that can benefit thousands of consumers. developed applications using Kubernetes, Redis, RDBMS, and AWS. However, from what I've read about system design interviews in Blind and Reddit, the interviewer seems to be looking for in-depth system expertise. I can grasp when I read Alex Xu and Educataive-io, but after that, I start to forget the concepts. How do I retain the concepts? is this enough to crack faang or maang? Please provide some light on this for me. TC: 200K Years: 10 #engineering #software #swe #interviewed #career #systemdesign #faang @amazon @google @meta @netflix @adobe @apple @microsoft
Use the concepts to design a system yourself and work with a mock interviewer to see where you had gaps. Another way is to actually create your personal AWS account and do a full hobby project implementation. Use JMeter to create 100qps+ large request volumes and see how your system reacts end to end. Then you won’t forget the concepts
Repetition
find many examples of real world systems that were and memorize them. There are tons of example online
Bad idea to memorize. You'll be easily exposed when interviewing for staff.
I wouldn’t say memorize but do try to think through other ways that the system could’ve been made and note the pros and cons
Senior developer and tiny projects? You don’t want to start your interview with this.
Let's be real. 99% of senior developers @ faang have only worked on tiny projects. Granted, you never want to word it like that though 😂
For Google it may be true
My team does system design interviews differently. We don't care about asking you to design a new system in 30 minutes. We ask you to describe a system you've designed in the past, big or small, but it should be something you understand well. We evaluate on clarity of communication, ask about reasoning for certain decisions and rejected alternatives, and probe on failure modes. This has turned out to be well recieved by applicants as relatively low stress, allowing them to relax and just have a conversation. For us, this has proven to be very effective in determining the level of applicants.
Look up MIT distributed systems on YouTube. It's an amazing class and you can do all the programming assignments in Go where you implement consensus algorithms, key value store, etc. I find it easier to remember concepts if I actually code them
My two cents is these 4 books: Java Application Architecture: Modularity Patterns With Examples Using Osgi, 1E https://a.co/d/j6ARZPu Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems https://a.co/d/fLG6YJV Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions https://a.co/d/ijl4sy5 SOA in Practice: The Art of Distributed System Design https://www.amazon.ca/dp/B0026OR2R2?ref_=cm_sw_r_apin_dp_35TNJAQMGXVPC4D2ENZ7 I don't know if these books will help you pass the interviews, but they will help you design systems in real life better than the average. (There are provably more helpful books about this, I'm sharing the 4 that I found the most inspiring for me)
+1 to Designing Data Intensive Applications. It gets you thinking about systems at scale and how to design for them. Very useful as you transition to the senior part of your career.
Another route, if you're up for it, is to do something like the associate arch cert in AWS. Almost all of the concepts translate well to systems design interviews and cover about 80% of what you would need
200K senior engineer at FANG? And Only tiny projects? Something doesn’t seem right here… To help you though you’ll need to start understanding trade offs, look at projects end to end How does the client interact with the server, how do we build in redundancy, how does the client deal with fail over? How does the client deal with retry’s? Does the system need consistency ?
1. Client interacts with server using HTTPS, usually with REST or GraphQL. 2. Redundancy is built at the DB layer by deploying a SQL DB in master slave mode. 3. Client does retries by using exponential backoff. 4. Consistency is an application level construct that is widely misunderstood. Usually folks associate it with the DB but in reality the application needs to enforce it. DB can only provide semantics like transactions to allow the app to easily enforce consistency.
By the way, I am not in Faang; I worked on microservice design from start to finish for a mid-level company, using an event-driven approach. Few people are fortunate enough to be assigned to good projects, and I believe I am not one of them. I appreciate your suggestion.
They key for systems design is to understand and explain the why, not just the what or how.
+1 and also making trade offs.
Yup. Have to discuss tradeoffs as part of the "why _____, versus _____"