How to Really Prepare for a System Design Interview

The section appeared in 2020, when Igor Maslov joined the company for platform work: he had many people to hire and proposed unifying the process. It started with about five tasks and ten interviewers Igor picked himself, but with no criteria and no shared reading of a result: everyone was simply trusted to design well and to spot that skill in others. When Igor moved on, the section passed to Alexander, and in one of the heavy hiring years he ran two hundred interviews minus one across System Design, management, and troubleshooting. Then came a seven-step process, an assessment matrix refined afterwards, a task pool, and preparation materials handed to candidates with an invitation to come back in six months. He passed the section to a colleague in 2024. Alongside it sits an architecture section for staff-plus engineers, built not on an invented problem but on the candidate's real cases and scope of responsibility.

The System Design book had weighed on him for years: a table of contents and a pile of chapters in a Google Doc that would not move. Late last year the company started building an internal counterpart to tools such as Manus; Alexander dug into how they work and used one for the site of their research on AI in development, the track he has officially owned since last week. Out of curiosity he loaded the book into the same tool, got a first version of the site, and moved his old articles into chapters one by one, adding visualisations; the work ate his January holidays. Grigory praises the interactive examples, such as a circuit breaker you can play with on the page. Alexander admits he would never have finished the book: the motivation only arrived once people started using the site. Most of the feedback from the announcement he fixed the same evening and morning, leaving the harder items: a learning path and the argument about longreads.

The section exists to see how a person thinks. Many candidates fail at the very first step: they read the prompt, say it is all clear, and design a system of their own invention, never clarifying scenarios, load, operating modes, or integration points. The interviewer then feeds in the missing pieces - here is the user count, here is the main scenario - and twenty minutes later the drawing turns out to solve a different problem. Grigory adds his own example: in his task only ten kilobytes travel over the network, but a candidate who never computes the load manages to draw a spaceship. The opposite extreme is no better: requirements can be gathered forever. Alexander recalls a troubleshooting interview where the candidate spent forty minutes collecting logs and took no action to fix the incident; his feedback said the man would make an excellent chronicler of incidents, but hardly an engineer. Requirements and quality attributes are a prerequisite, yet analysis paralysis has to end and design begin.

His own preference is to begin with the black box: what the system promises to the outside, and to whom. These days that fixation usually takes the shape of an API, a contract with concrete consumers on the far side. Both directions can go wrong: leaving the necessary contracts unwritten, or dragging in everything at once - authentication, quotas, an admin panel, an export to the data platform - after which you design all day instead of narrowing the scope to the agreed scenarios. Those who start from entities and data models land on a database choice in more than nine cases out of ten before knowing which scenario they cover. Next comes not beautiful diagrams, which will not fit into the hour, but a rough sketch: five or six blocks with requests and events passing through them, and scenarios traced across them. Quality attributes and SLAs surface at the same step. Alexander recalls designing a social network almost twenty years ago that worked fine for a hundred people and collapsed under multi-storey selects at ten thousand.

There is a separate species of answer: put a cache here, plug Kafka in there. Every fashionable word is in place, and an interviewer who did not know the field would call it good design. Alexander recalls a candidate who laid a system out quickly and elegantly in half an hour but forgot the main requirement and refused to redo it, patching the hole with hotfixes; when the questions went deeper, into distributed systems and the foundations that fill the second half of the site, there was emptiness - though he already held offers from other companies. He is equally candid about his own miss: with a degree of arrogance he handed a candidate a task from that candidate's own domain, the answers were brilliant, the score came out inflated, and colleagues came with questions afterwards: the task had been half leaked. The rule since then is simple: when everything goes too smoothly, steer the task away from the default one by adjusting requirements or adding scenarios. The reverse happens too - a leader with a trading background solved one task differently from the reference answer, but better suited to its conditions.

An interview is almost always greenfield with free technology choice; work is brownfield, a limited stack and integrations, so you design not the best system but the one that fits the landscape most cheaply, and watch who on the team will maintain it. His example is an attempt to build new authorisation on relationship-based access control following Google's approach, with the permission graph stored as triplets: the flexible model cannot be cut into shards, a test bench on distributed databases showed the vendors' numbers assumed a different load profile, while the team's load hit the database far harder, and the hardware costs insane money for a hugely complex system. They kept the API and the data model but sliced the graph for the specific query types they believe in. The next interview format Alexander imagines is a brownfield project with an agent: his demo had neither tenancy nor an API, and adding a tenancy model took about an hour. It has to be trialled on current employees first. An agent writes code and sometimes designs, but without foundations you cannot direct or check it, and a junior can hand over responsibility along with the task.