Over the years, more and more you start to realize the importance of structuring your application properly, particularly for maintainability and resiliency (depending on the context). There are so many factors to consider and that’s something that typically takes time and experience to understand deeply.
In college this was my first concern when it came to app development -- how are you supposed to structure/organize things? I didn't realize it was a high level concept, but explains my struggles so much more. I'm a top-down learner, it's been a struggle to learn from the bottom-up.
@@joaquin67 solution: Learn from the outside-in 😊 While I’m not formally educated, I’d imagine if you’re in school, the lessons may be very linear and abstract and hard to understand how it’s practical or why it matters. Learning to teach yourself is so important here, just to get hands on. At least for me that’s how it really “clicks”. That’s also good for staying up to date, too.
Different companies have different standards of System Design interviews tho. You can get a gist of what the company is asking on sites like Reddit or Blind and then prepare accordingly.
Hi, great videos and some really interesting content you guys produce! I must say I was blown away with how many subscribers you have considering you only joined around 6 months ago, care to reveal your secrets?😂😮
Hello, probably you've heard this a lot - please consider making the second volume available as an e-book. Doesn't have to be Amazon if that's the issue (as long as I can read it on my Kindle).
Great analysis and demonstration as usual, but 'non-functional' design/requirement is meaningless taxonomy which should be replaced with implementation detail and you use it wrong by saying it's more important as you mature in your career. That's a lower level concern.
Why is asking for how someone would design new systems higher signal than asking them about things they’ve actually worked on? Greenfield, brownfield, or maintenance. Shouldn’t interviewers be more interested in understanding what you demonstrably can do?
I don’t see those topics as mutually exclusive per se. You can ask the question different ways, not only “How _would_ you do [x]?” but also “What sort of design _have you_ architected/implemented in the past?” Also: Granted it’s more prominent in greenfield, but new system designs can be implemented in existing legacy systems, typically in lower level abstractions, if not a full rebuild. Sometimes it’s just in lower level abstractions. Remember, programming is a very creative process and that applies at all levels.
That is an important part of the overall interview process, too. They are not mutually exclusive. Some companies call that retrospectives, and value them so highly that they prefer to assign their most senior technical leaders to give those interviews when they can.
Whoever is doing animations on these deserves an award
Thanks for the compliment, but we prefer to be paid in memes.
A huge shoutout to our amazing video editor for the hard work...
@@ByteByteGo The universal currency.
Over the years, more and more you start to realize the importance of structuring your application properly, particularly for maintainability and resiliency (depending on the context). There are so many factors to consider and that’s something that typically takes time and experience to understand deeply.
In college this was my first concern when it came to app development -- how are you supposed to structure/organize things? I didn't realize it was a high level concept, but explains my struggles so much more. I'm a top-down learner, it's been a struggle to learn from the bottom-up.
@@joaquin67 solution: Learn from the outside-in 😊 While I’m not formally educated, I’d imagine if you’re in school, the lessons may be very linear and abstract and hard to understand how it’s practical or why it matters. Learning to teach yourself is so important here, just to get hands on. At least for me that’s how it really “clicks”. That’s also good for staying up to date, too.
This channel is THE GEM.
man your video explanations are truly exceptional!!! keep it up bro
Thanks for sharing, I bought your System Design book(awesome topics), very excited waiting for the new videos that are coming.
Amazing. Looking forward to the next set of videos.
Thank you so much. I got my first job with a senior prefix and i want to learn a lot about system design this year.
Since it has been a year from your comment... Have you learned a lot?
I like your diagrams. Which tool do you use to draw the diagrams? Please let me know, I am planning to use on my presentations.
The best channel.
These tips sounds also important to product managers too even if for those without tech background
Appreciate. Will be waiting for updates. Love Your books.
Different companies have different standards of System Design interviews tho. You can get a gist of what the company is asking on sites like Reddit or Blind and then prepare accordingly.
Hi, great videos and some really interesting content you guys produce!
I must say I was blown away with how many subscribers you have considering you only joined around 6 months ago, care to reveal your secrets?😂😮
great work, can you make one video about Open source, what is, why is etc
great stuff on your channel. thank you so much. Do you have any system design course. Could you plesase create one if you do not have.
I like your animation. Which tool do you use to draw them?
First to comment 😇...for the first time. Greate tutorials always.
Very good show. What tool are you using for you show ?
Looks like After Effects and working with a motion graphics designer
I love your content
Thnak you so much
A question to the mentor, is the system design same as solution design (in cloud terms) ?
Hello, probably you've heard this a lot - please consider making the second volume available as an e-book. Doesn't have to be Amazon if that's the issue (as long as I can read it on my Kindle).
Im your new avid fan. :)
Great analysis and demonstration as usual, but 'non-functional' design/requirement is meaningless taxonomy which should be replaced with implementation detail and you use it wrong by saying it's more important as you mature in your career. That's a lower level concern.
However, System Design Interview for junior engineering positions is a scam, especially in big organisations.
Why is asking for how someone would design new systems higher signal than asking them about things they’ve actually worked on? Greenfield, brownfield, or maintenance.
Shouldn’t interviewers be more interested in understanding what you demonstrably can do?
I don’t see those topics as mutually exclusive per se. You can ask the question different ways, not only “How _would_ you do [x]?” but also “What sort of design _have you_ architected/implemented in the past?”
Also: Granted it’s more prominent in greenfield, but new system designs can be implemented in existing legacy systems, typically in lower level abstractions, if not a full rebuild. Sometimes it’s just in lower level abstractions. Remember, programming is a very creative process and that applies at all levels.
That is an important part of the overall interview process, too. They are not mutually exclusive. Some companies call that retrospectives, and value them so highly that they prefer to assign their most senior technical leaders to give those interviews when they can.
@@ByteByteGo Ditto 😅
@@ByteByteGo that makes sense, thank you! Looking forward to a System Maintenance Interview book haha