harisrid Tech News

Online resources

• algoexpert.io – a solid peer-to-peer real-time practice platform
• interviewing.io – a solid peer-to-peer real-time practice platform
• pramp.com – good for junior/entry-level engineers, with a targeted focus on algorithmic-style questions ( and limited system design )
• leetcode.com

How I prepped System Design Interviewing?

I’ve been asked this by a good number of peers, including mid-level ( L4 ) and senior ( L5 ) peers who work in name-renowned companies like Google and AirBnB. And I’ll definitely admit the truth ; preparing for a system design interview is harder than an algorithmic interview.

So how did I prepare?

1. Self-studying the books : I plowed through Alex Xu’s Volume 1 and Volume 2 System Design Interview Books
2. Paid practice sessions : I immediately signed up for 20 mock interview practice sessions on interveiwing.io ( https://interviewing.io/ ) for system design preparation. Technically speaking, I think those slots were meant to be only one-hour long each, but many interviewers I practiced with were nice and oftentimes extended sessions to 75-minutes or 90-minutes in length. I got good feedback on where I could improve, what to communicate, and what to emphasize – pointers such as changing the order of sections, thinking about security mechanisms, etc.,
3. Mock interview sessions : I set up 5-6 practice mock interview sessions with my friends, each about an hour ( or 90-minutes ) in their session length. I figured that the best way to learn a subject is to teach a subject; I already knew how to mock algorithmic interviews – mocking a design interview would be incredibly similar.

But why are they significantly harder, Hari?

Well, there’s a couple of reasons. Let’s dive into them!

But why are System Design Interviews Harder to Prep?

1. Resource Prep Scarcity– unlike algorithmic interviews, which have been around the block for a long time and where we have a long list of resources ( e.g. CTCI, Leetcode.com, AlgoExpert.Io ), we don’t have as many resources for System Design Preparation. Alex Xu’s one of the few authors who even took a stab at architecting books to help others learn system design skills.
2. Interview Practice Scarcity – companies ask algorithmic questions more than design questions ( and whether that’s a good or a bad thing is up to question ). Let’s suppose a senior engineer has to do three on-sites for Big Tech Companies – they can expect upwards to fifteen hours of total interviewing : each one hour block 50 minutes of interviewing and a 10 minute cooldown break. Each company on-site will entail a single 1-hour phone screen and a 4-hour onsite. I expect the phone screen to be algorithmic and 2/4 sessions in the on-site to be algorithmic, netting us about 9 ( out of 15 hours ) of deliberate practice in the land of algorithms. Consequentially, developers get solid algorithmic practice, BUT, not as much design practice.
3. Domain Knowledge Expertise – System Design skills aren’t writing APIs contracts or throwing a SQL database models. Harder design questions require some knowledge in networking protocols, distributed systems ( e.g. failure modes, leader election ) , and databases index data structures ( LSM trees or B-trees ) as well .
4. Hard to prep for atypical, non-standard questions – There’s plenty of material on questions such as Designing Instagram or Designing WhatsApp, but questions asked are occasionally niche and akin to real-life case studies ( e.g. designing a large-scale data ingestion/streaming service for a social media platform ). You may need to deviate from traditional patterns or templates.
5. A lack of on-the-job practice – not all software engineering jobs need system design skills, and even if they do, they might not need the skills frequently exercised. A discussion on quota bucket might involve a month long project, but other projects can be scoped to code-only features or other proprietary organizational goals.
6. Mismatches between Academy and Industry – undergraduate classes in networking or distributed systems are useful ( from their theory-heavy emphasis ), but they don’t extend full comprehensive coverage of all system design topics ( e.g. API contracts design or tradeoffs discussions between SQL databases versus No-SQL databases ).