Discussion with Grisha Skobelev on preparation for System Design Interview (Category Architecture)

This weekend, Grisha and I are from the club. talk About preparing for the System Design Interview and how I came to life the way I built the site. system-design.space. The main points that we managed to discuss the following ​ The System Design book is quickly becoming obsolete: patterns and requirements change, and a live site can be continuously added to practice, rather than to “perpetual theory.” Interview expectations shift from “do you know the standard set of services and buzzwords” to the ability to think like an architect: soberly choose compromises, ask questions, formalize requirements. Discuss common mistakes of candidates

• Immediately draw "cubes and arrows" without specifying the restrictions, Optimize beyond real bottlenecks Learn task patterns instead of understanding invariants (consistency, durability, latency budgets, etc.) System Design interviews actually check not “do you know Kafka” but how you make decisions, how you talk to a product manager, how you evolve from an MVP to a complex architecture. Difference Between Drawing Cubes and Architectural Thinking: In the latter case, you always tie solutions to custom scenarios, load, fault tolerance and cost of ownership, rather than just listing trendy technologies Topics required for senior/staff are: storage and computation scaling, queues and asynchronized work, caching, consistency, observability, evolution of data schema and rollouts, and work with uncertainty and incomplete requirements
• You need to prepare not "on the checklist of tasks", but systematically: build your own set of invariants and thought patterns, run real cases, and not just memorize solutions. ​ When it comes to ideas that can be shared, The SD interview should be rebuilt from "guess the service" to the analysis of the real case: give incomplete requirements, see how the candidate refines, cuts the scope and develops the architecture iteratively. A good SD interview is a mini-co-design: you come together to at least the first adequate approximation of the system, not the perfect picture from the textbook. Clearly formalize what levels of architectural thinking you expect from middle/senior/staff and give people a transparent ladder of growth. (Ideally, with examples in internal cases.). Instead of waiting for the team to read SD books, it’s easier to give a living practice base, checklists, and post-mortem parsings—that is, institutional knowledge, rather than a set of references to classic books. ​ #SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering