If it helps, I didn't really start to grok system design and architecture until more than 2 years full time. Before that it was just a bunch of functions/methods, classes that used each other. Slowly though, you start to notice the patterns, you see what failed badly and how it failed (bad design). You get burnt having to solve problems in badly designed code. You get stuck trying to test badly designed code. You slowly see the bigger picture, how to put together these small pieces into that complete application that isn't a tangled mess and unmaintainable (bad design = maintainability being inversely related to time * functionality, or some equation of that sort).
Of course this has nothing to do with what system design questions (most) interviewers care about. But this is the system design that matters on the job.
Read books for the real system design after you land the job, they won't really stick before you get expeirence - refactoring legacy applications, pragmatic programmer, clean coder, clean code, clean architecture (all clean books are by 'Uncle Bob').
For interview system design (I'm not speaking from too much experience here), youtube has some good videos "software system design interview", I've seen "grokking the system design interview" book being mentioned.
> Of course this has nothing to do with what system design questions (most) interviewers care about. But this is the system design that matters on the job.
Sigh.
I just think it's so absurd that "system design" is now an interview category that's expected of new grads. I'm talking about the fanciful form of this, where the bright eyed and bushy tailed new grad is somehow working on a problem that is the equivalent of the Large Hadron Collider or the Apollo space program.
I've sat on the other side of these interviews, and what I'm hoping for, especially from beginners, is just some common sense, and some reassurance that they can identify at least the main design tradeoffs and make appropriate decisions based on the information available. And then we look at what should happen to the design of our system if I modify our assumptions, or add new use cases that create new forms of stress on the system.
What I get instead is stuff like "I'll use a key value store", and when I ask why, I get "because it scales better", and when I ask "compared to what, why, under what conditions", I get blank stares, because they've barely used either. Then I learn that they said a thing because they read some github repo with 100 system design questions that said so. Or they read a prep bible that told them this is how Google does things. Or they read an actual book about a subject (a bit better) but didn't really absorb the ideas (which is fine! happens to me too!), but wanted to use the thing they learned about anyway.
What I actually wanted was "because the data is simple and non-relational and this will suffice for the foreseeable future, and features XYZ help remove complexity from the app" or "this is a single-purpose system designed to do one thing very well, and we can pack a lot more storage / throughput per node this way" or "Never mind, the requirements and the future are fairly vague, I'll just use something I understand well, is flexible, well supported and easy to migrate out of" or ANY sort of sense that we do things because of reasons, and we don't do things if we don't have good reasons to do them.
I remember being a beginner too - not knowing things and inexperience is perfectly fine, the point is we want you to do your best with what you have. It's fine to be honest about your knowledge and capabilities. You can look silly otherwise.
What are fairly nuanced, philosophical or "it depends on ..." questions to me after two degrees and almost a decade and a half into my career, for some of these folks is "of course it's X", and I'm just flabbergasted at the level of confidence that's projected. Please just a) exercise judgement b) based on the facts available c) leveraging your existing knowledge of core software concepts. Try a design, say why you did each thing this way, say what you like and don't like about it, say what you're uncertain about, what a few alternatives would look like, what you don't like about those, and what you'd change if you had a bit more information. This is the kind of "how do I do this" thing everyone building anything should be doing every day.
It's not impressive for you to be able to regurgitate the X types of cache policies according to wikipedia. It is, however, impressive when I point out a potential problem with the way you set up your caching scheme, and so you look at what you designed, actually think about what that means, and are able to tweak it to better fit the requirements. I don't mind whether you're aware that you just re-discovered a thing that already has a name.
My plea to whoever is posing and judging these system design interview questions in this way causes young interviewees to think they need to participate in a kind of veteran staff engineer cosplay tech-braggadocio circus: for god's sake, just test what's required for the job, please and thank you.
> Or they read a prep bible that told them this is how Google does things. Or they read an actual book about a subject (a bit better) but didn't really absorb the ideas (which is fine! happens to me too!), but wanted to use the thing they learned about anyway.
In my experience and from what I have heard from other people, this is just how people generally are.
It seems rare that people consider things rather than regurgitating them.
As a young guy who doesn't like to cargo cult like that it's sad to hear, but on the other hand it's less competition for me. Though a lot of experienced people are also like that so...
I mean, I have 10 years of experience in the field and when someone asks me that in an interview I still go like ‘duuuh?’. They’re like asking me to package up 10 years of experience into a 3 sentence package.
How many ways are there to tell you that a caching mechanism is better for a site that barely ever changes than using database replication (yes, answering that question probably gave me some form of trauma).
I do a lot of stuff intuitively, and don’t consider the exact reasons behind them every single time.
It’s like when my maths teacher asks me to write out the steps to arrive at the solution. “But the answer is 30, right?”, “Yes, but I need to see how you arrive at that solution.”, “I look at the problem. The answer is obvious.”
Do I really need to stop and unwind the steps my mind takes to arrive there.
I’m not in school anymore, and I don’t have to graduate any more, so my patience for that kind of shit has gone down correspondingly.
I've had a very different experience. Being able to explain my thought process well is a key part of my job, whether its mentoring juniors or building consensus for larger architectural changes.
It’s really about approximating the experience as a why to a decision. Usually I try to think through questions and talk out their benefits and things start to get more “obvious” to me as I go.
Admittedly, I don’t struggle near as much in system / software design questions, it’s my “niche” (tldr thinking in systems changed my life as a teen) but data structures and algorithms still kill me, in much the same way. I have the correct intuition but can’t for the life of me correctly describe it in Big O notation and I sometimes “freeze” on questions because it’s not something I do every day and I can just well…look things up sometimes, or work through a problem iteratively until I have a solution
Of course this has nothing to do with what system design questions (most) interviewers care about. But this is the system design that matters on the job.
Read books for the real system design after you land the job, they won't really stick before you get expeirence - refactoring legacy applications, pragmatic programmer, clean coder, clean code, clean architecture (all clean books are by 'Uncle Bob').
For interview system design (I'm not speaking from too much experience here), youtube has some good videos "software system design interview", I've seen "grokking the system design interview" book being mentioned.
Good luck. Hope this helps somewhat.