System Design Interview: Keep It or Kill It?

The host estimates that around 70% of the audience are backend developers and 25–30% are team or technical leads, with fewer frontend and DevOps engineers.

Then he acts out a typical interview: design a food delivery service. The candidate clarifies functional requirements — restaurants on a map, contacts, search, reviews, ordering a dish — promises scalability and availability, runs the arithmetic, sketches an API and the classic three-tier architecture of the nineties with restaurant, search and user services.

Then Kafka has to go in, because the scorecard will say the candidate did not use it even where it does not belong; Grafana and a fashionable search engine follow, also for the tick. At the end he is told he said nothing about notifications, monitoring or algorithms. "I had 45 minutes." "A whole 45 minutes."

Hence the host's thesis: the practice was copied from big Western companies without thinking, and that is cargo cult. Philipp adds that while preparing he watched practice interviews with their commentary and found only one person who clearly understood what he was doing — Alexander himself.

Alexander answers that any tool can become a cargo cult — as in the story about worshipping aeroplanes; the question is whether you understand its limits.

He then explains why his company needed the section: it began with off-the-shelf products, but after eight or ten years some hit the ceiling of their scaling and others cost not like an aeroplane wing but like a whole aeroplane. The company began building its own systems; products, clients and load grew, and it needed many engineers making design decisions locally, rather than a corporate architecture department drawing arrows without knowing the local context.

Eight years ago Alexander ran hour-and-a-half interviews with small design tasks from the team's own domain — easy to invent, because he was in that context.

Once hiring had to be faster and levelled across the company, the checks were split into sections and a pool of interviewers: with hundreds of positions a month, a handful of the strongest engineers cannot carry that load. Alexander insists the drawing is secondary — what matters is which questions the candidate asks and whether he uses the answers: asking about load or an SLA and changing nothing in the design does not count.

He recalls a candidate who refused to allow for the system being collaborative, and behind the deeper questions — operating systems, networks, database internals — there was emptiness; the recruiter later asked why he had rejected someone who had passed every Russian big tech.

The boxes serve him as an anchor: with a picture you can ask what happens if the link between two data centres breaks — and at internal architecture reviews two people from the same team answer that differently.

Philipp attacks the link between the format and practice. Discussing a small product’s non-functional requirements may take two hours, but finding the missing answers can stretch the work over two or three weeks; at interviews, by his reckoning, 90% of the requirements are lost and the rest are collected wrongly — and the score is awarded anyway.

Daily load is computed by dividing DAU by the seconds in a day, and at no public interview has he heard anyone object. The textbook and architecture-kata Twitter designs, he argues, have nothing to do with the real architecture: the most important requirements are dropped at the very start.

The format also narrows the answers: the textbook task fits comfortably into a single PostgreSQL, while an average interviewer cannot assess an exotic database: you must not say what he will not understand. Hence his central claim: replacing architecture with boxes, arrows and the word cache spoils the industry, whereas architects mostly write prose. Alexander calls that a loud statement, but agrees he too is against arrow-drawers.

Philipp's alternative is fifteen minutes on real experience: why do you have microservices? "They give scalability" — did you have that scale? "They speed up delivery" — did delivery get faster? Saying "let us take Kafka" out of a book is easy; real experience demands awareness.

An audience member who has tried hiring through conversations about experience raises two problems: the judgement is monstrously subjective and barely transferable, and a reserved engineer will tell you nothing about his work — "we shipped it to production, it started, what is there to tell".

Philipp responds by describing how interviewers learn through shared practice: conduct interviews with another lead and explain why each question is asked. He also proposes rotating formats roughly once a year so that preparation does not replace the skill being tested.

He offers more checkable formats: hand over a chapter of the preparation book and ask for five stupid mistakes in it, ask the candidate to critique someone else’s interview or conduct one; a further option surfaces in the exchange — naming the tests you would write for a proposed architecture. Designing, in his view, is one of the least effective formats, because criticising someone else's work reveals more — as language screening long ago shifted from "write five lines" to "find the bug".

Alexander describes an additional section for senior-plus candidates: an hour on the CV and real cases about architecture and development processes, added after people collected every checkmark and then wrecked a team or kept a task eternally 90% done. He cautions that this section can uncover some risks, but does not eliminate all of them.

For SRE candidates, greenfield design added little, and an incident simulation fitted better: you have gone on holiday without a laptop, a junior is on duty, everything is on fire.

On small companies Philipp notes that they do plenty of design and have nobody to assess their first technical leader: one architecture kata's winning design would, he thinks, have run to some fifty thousand dollars a month on Amazon, where a thousand clients would be served more cheaply by one person with Excel.

In closing, Alexander says he sees no other way to bring in hundreds of engineers a month, while Philipp says the format looks under the streetlight and solves for sameness rather than quality: algorithms are pointless but harmless. The host showed the ballot result to the room and left its interpretation aside.