The Design Section in Tech Interviews

In the hiring process described in the talk, a developer speaks with a recruiter, completes technical interviews, meets a team, and receives an offer if the outcome is positive. System design sits alongside algorithms and language knowledge, but answers a different question: can this person make decisions beyond an isolated piece of code? In this particular process, Junior and Middle candidates normally do not need a separate design interview, while Senior and Senior+ candidates are expected to demonstrate greater independence. This is a description of a process presented in 2021, rather than a universal hiring rule or a guarantee of someone’s level. Strong programming skills alone do not reveal how an engineer will define a service boundary, agree on its behavior, or choose how it stores data. A separate design problem gives the candidate room to expose that reasoning as a connected whole.

The organizational need comes from growth. More customers increase load, new products create business verticals, and integrations have to support an expanding ecosystem. Large teams also split into more autonomous ones, moving architectural decisions closer to the engineers building each product. The company therefore needs people who can understand a product problem and take responsibility for part of a system without waiting for a complete design from above. Candidates benefit too. A strong performance can lead to more challenging work and better terms; an adequate but uneven profile can help identify a team where the engineer can grow alongside experienced colleagues. An unsuccessful interview should produce personalized feedback on missing skills and where to study them. The point is to connect the assessment to subsequent development. Specific strengths and limitations make the hiring conversation more useful than a general impression of how well the meeting went.

After the interviewer introduces the problem, the candidate takes the lead. The first task is to clarify behavior and the properties that matter: availability, data consistency, throughput, scalability, or auditability. Questions should follow from the problem. User counts, request rates, and storage volumes are inputs to later decisions; simply asking for every number in sequence is insufficient. The candidate should formulate assumptions about workload and record answers beside the requirements. Next come system boundaries, clients, supported scenarios, and the public API. At this stage, the internals can remain a black box: the immediate goal is to agree on what the system promises the outside world. The author relates this view to a C4 System Context diagram. A shared board keeps those agreements visible so the design can be checked against them. Before the exercise begins, the interviewer also explains the drawing tool, preventing unfamiliar controls from getting in the way of the architectural discussion.

The internal design develops by following data: where a request arrives, what happens to it, where information is stored, and what gets passed onward. Components emerge because a scenario requires them. Start with normal successful execution, then revisit exceptional paths and component failures. Constraints belong in this discussion too: whether a user’s task can be lost, for example, and how quickly it must complete. The conceptual diagram identifies component and storage categories, data models, and what belongs in memory versus persistent storage. Concrete technologies and capacity calculations come next. However, scalability must already be considered at the conceptual stage: the busiest components need an understood path to horizontal growth. Leaving workload until the end may force a redesign of an otherwise attractive diagram. The candidate needs to show which input numbers affect the architecture and why the chosen components fit those conditions, rather than merely listing technologies used in a previous job.

Assessment follows the design process but goes beyond whether a diagram exists. The talk identifies eight areas: problem formalization; system boundaries and APIs; data flows and components; the conceptual design and data models; concrete technology choices; workload and capacity planning; diagram readability; and additional questions. The last two provide distinct evidence. Readability shows whether someone can understand the system’s main behavior and limitations, or whether the drawing requires continuous explanation from its author. Additional questions allow the interviewer to explore technology alternatives and extensions to the original problem. A candidate’s skills rarely sit at the same level across every dimension. Good requirements work can coexist with limited storage knowledge, while a clear diagram can conceal weak reasoning about scale. Recording evidence separately for each area makes the assessment more informative than assigning a level without explaining what the person actually demonstrated.

The author illustrates this with an uneven candidate profile. The candidate clarifies requirements, defines boundaries and APIs, covers normal and exceptional scenarios, and produces a conceptual design with data models. Yet the concrete technologies come mainly from personal experience, with little explanation of their suitability. Workload enters the discussion only after prompting and barely affects the solution; additional questions reveal limited technical breadth. In this example, the author assigns a Middle level specifically in distributed systems design and records strengths and gaps for both the candidate and their future manager. That assessment suggests concrete preparation: practice missing stages, deepen knowledge of technology choices, and connect constraints to architecture. The suggested learning resources include design books, System Design Primer, Martin Kleppmann’s distributed systems course, Essential Architecture, and specialist conferences. These resources help explain why designs work; candidates still need to apply that understanding in a coherent discussion of a particular problem.