Slide contents

1. 1. How to pass a System Design Interview

   Preparation and candidate behavior

2. 2. Alexander Polomodov

   Role at the time · 2022

   Alexander Polomodov, CTO, mobile banking and acquisition, Tinkoff

   Oversaw architecture decisions

   Oversaw System Design Interviews

   Interviewed technical leaders

3. 3. From hiring to candidate behavior

   Eight connected themes

   Hiring and seven steps

   Requirements, boundaries, flows

   Models, technology, scaling

   Behavior and study paths

4. 4. System Design targets Senior and Senior+

   Not a universal modern hiring process

5. 5. Architecture emerges one step at a time

   From the prompt to follow-up questions

6. 6. 02. Formalization

   Before the first line is drawn

7. 7. Clarify the problem first

   Scenarios, scale, priorities

   What is in and out

   Who uses it and why

   What volumes are expected

   What matters most

8. 8. Priorities direct the architecture

   Sizing connects requirements to scale

9. 9. Learn the language of requirements

   Functionality and architecture qualities

   UML Use Cases

   User Stories and JTBD

   ATAM for trade-offs

   Wiegers and Eyskens

10. 10. 03. System boundaries

    The system inside its environment

11. 11. A boundary starts with a scenario

    Files, DB, API, or Messaging

12. 12. Understand every request path

    From context to load balancer

    C4 System Context

    REST, RPC, GraphQL, AsyncAPI

    OSI, TCP/IP, DNS

    HTTP/1.1–HTTP/3 and WebSockets

13. 13. 04. Flows

    Components emerge from behavior

14. 14. The happy path reveals exceptions

    Failures and corner cases come next

15. 15. Separate reads from writes

    Test load and failure behavior

    Trace the read path

    Trace the write path

    Apply the leading NFRs

    Add failures and retries

16. 16. Choose the diagram for the question

    Do not mix every notation

    C4 shows containers

    Sequence reveals interactions

    Activity captures branching

    DFD and BPMN show flows

17. 17. 05. Conceptual design

    Solution classes come first

18. 18. Responsibility comes before product choice

    State, data, and bounded contexts

19. 19. Connect models to storage

    Data determines access

    RDBMS and NoSQL classes

    ER and Class Diagrams

    DDD and bounded contexts

    Twelve-Factor App

20. 20. 06. Real system design

    Technology, guarantees, operations

21. 21. Technology must uphold the promise

    Guarantees, capacity, failure domains

22. 22. Design continues after launch

    Observe, change, recover

    Logs, metrics, traces

    Backups and recovery

    Schema and data migrations

    SRE and Kubernetes Patterns

23. 23. 07. Under load

    Different state, different levers

24. 24. State determines the scaling mechanism

    Autoscaling, replication, partitioning, sharding

25. 25. Scale for real access patterns

    Topology changes guarantees

    Start with access patterns

    Name the consistency model

    Check for hot keys

    Validate with load tests

26. 26. Lead the conversation, do not guess

    Think aloud and notice prompts

27. 27. Study along four paths

    Full bibliography in presenter notes

    Requirements and trade-offs

    Networks and integration

    Data and distribution

    Reliability and operations

28. 28. Meaning first, technology second

    Seven steps keep the conversation coherent

    polomodov.tech

    Clarify, trace flows, explain trade-offs

    Alexander Polomodov, Author and speaker, ArchDays 2022

    @book_cube