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.
Good luck. Hope this helps somewhat.