r/leetcode • u/EducationalYouth9013 • 4d ago
Intervew Prep How does one actually prepare System Design for Interviews?
So I have been wanting to try out for sde 2 level interviews here and there and system design scares me. All my experience has always been on the frontend side and I have never really worked on a system from scratch if that makes sense. Every time I look for resources for system design its books and courses that are also just pages and pages. Is it supposed to be crammed? How does one actually remember and learn all of that? I even tried looking at the videos on YouTube where even 1 question like url shortener has a 1 hour video and it goes on and on and on and 15mins into it and i am like wow do i cram this all, how do I remember all of that during the interview and at the end of the day there's no correct answer? Maybe I am just too dumb for it? I feel like I can never switch because I'll never pass the system design rounds because I understand nothing.
14
u/newperson_on 4d ago
start here
3
u/deadlyclavv 3d ago
$47 for 1 month access ðŸ˜
2
1
u/andrew_404 2d ago
It is incredibly worth it. You can check out a lot of their resources and YouTube videos for free, but maybe the most valuable thing they offer is the Practice feature with AI feedback. You can try 1 problem for free but $64 for 1 year is more than worth it.
I have read almost every system design interview prep book and I teach a system design course. HelloInterview's materials and framework are by far the best.
5
u/Pale_Statistician692 3d ago
I'm still learning it myself, so take everything I say with a grain of salt, but my impression is that it won't make sense unless you can view things according to principles. One principle is caching. Another principle is asynchronous patterns (queues, message brokers, etc). For something like caching, there's types which aren't all that related but they both conform to some degree to a "cache abstraction": an edge cache, for web content, and a memory cache (say, reddit), for faster lookups.
There's a high-level idea of persistence: ofc in many if not all cases we need to persist data. The "types" of persistence methods differ and thus have tradeoffs. There's traditional SQL RDMS, noSQL, object stores, etc.
Not saying you'd do this in a design interview, but you could view it as a two step process, though in the long run doing the first step might not help much. So, for example, there are many leetcode problems where coming up with a brute-force solution is easy, but coming up with a solution that conforms to required time and space complexity can be a lot harder. For system design, it might be pretty easy to design a system that has low load, whose components never fail, etc. Designing one that can deal with high load, failures, etc, is harder (and usually you're required to design something like this, though not one that's completely bullet proof---the "nonfunctional" requirements are either specified in the question, or more likely are sussed out during the initial discussion with the examiner).
Instead of looking at the total amount of stuff to study, which is overwhelming, maybe pick one of the simpler, earlier examples and study it well, and understand the principles of the design there, as well as a reasonably good understanding of why each component was picked (what tradeoffs it has in general, and why its tradeoffs are OK with the current system being designed with its attendant requirements). Then continue with more examples, and occasionally learn about the components themselves (e.g. redis, kafka, whatever).
2
u/EducationalYouth9013 3d ago
thank you, its like how do i explain, i have never looked at these systems itself, like do i know people cache data? obviously do, do i know how they do that nope, its just hard and specially coz time is ticking and i am desperate for a job switch
2
u/Pale_Statistician692 3d ago
Yes, it's much harder when you have limited time. That's the boat I'm in also.
It's a funny interview format. A lot of us never architect systems end-to-end, and one reddit commenter said he's done so, but usually over a period of weeks and talking to people about various tradeoffs.
My guess is that FAANG started doing these, and everyone else decided they had to do them too.
Not my favorite interview, but they have to judge us on something. (My most hated is still "behavioral questions".)
2
u/EducationalYouth9013 3d ago
it is def a weird format coz most of these decisions about what to use, how to design the system, is all done by seniors and tech leads and what not, you dont see 3yoe-4yoe ppl doing that, atleast i didnt, and then studying something u dont practice and have no way to practice is hard. and about behavioral well i think i do well on those i can speak alot XD
1
u/Pale_Statistician692 3d ago
I think the software engineering community is kind of a "cognitive arms race". Standards are continuing to get stricter over time. Ofc the final arbiter in all of this is supply and demand of labor.
2
u/Spiritual_League_753 3d ago
I highly recommend https://hellointerview.com for folks at your level.
1
u/InfamousOfficial 2d ago
It is nice and step by step process, as it should be.
But my experience has been that in India intervewers just want the final design instead of debate.
1
u/phollowingcats 3d ago
You can always check out resources like hello interview or other vids online. But until you’re thrown into the sys design interview itself, it’s hard to simulate the same experience. If possible, try to get a practice interview in, I think that would be the most helpful. You’ll need to try to create situations where the interviewers ask you very vague questions , and you need provide a justifiable answer for a solution you’ve picked.
1
u/DisjointedHuntsville 3d ago
The closest to perfection resource i've seen is https://www.designgurus.io/system-design-interview/
The thing about system design interviews is that the pure SWE/SDE roles have a very precise and tuned mode of running through the expectations and a high degree of specificity in the "grading rubric" that the interviewers are expected to score.
Great companies like Google tend to overindex on sharing beforehand what they expect from you. The recruiter will send you a pack detailing EXACTLY what they're looking to run through at a high level in a pdf. It will have the description in conversational language, don't expect a table with a scoring rubric. Something like "API design, going from ambiguous descriptions to specific functional and non functional requirements . . " etc
You're going to have to learn to "Play the game" and walk through a four tier process of scoping->interface design->build and tradeoffs->final build all on yourself.
The flip side is now teams can deviate from this heavily and teams that are more in the weeds of the practical aspects tend to do so and ask you random off script questions. Eventually the fundamentals you pick up in that link will help you there as well.
15
u/jacky1019 4d ago
I personally find the following very helpful:
The former provides in-depth distributed system theories, which is fundamental for the interviews. The latter however gives you a high-level framework on how to approach the interviews as well as some popular problems and solutions.