System Design Interviews: What Worked, What I’d Do Differently

The preparation that worked, and the mistake I kept making

Of all the interview formats, system design is the one I respected most — and the one I most wanted to get sharper at.

Not because the material is unfamiliar. I understand these systems, I’ve made architectural decisions for years, and I can tell you why a design will hurt you in production. But as an Engineering Manager I’m not designing systems from scratch every week. I review, question, and guide — and that’s a different muscle from standing at a whiteboard with a blank problem and forty-five minutes. The knowledge was there, the repetition wasn’t. That gap had been on my list to close long before anyone asked me to interview.

So when I started interviewing, I did what everyone does: I went looking for how to prepare. That turned out to be its own problem. Search for “how to prepare for a system design interview” and you’ll drown — endless videos, almost none of them agreeing. One tells you to memorise a framework. The next says frameworks are why candidates fail. One promises a formula that works everywhere. Another insists there’s no such thing.

I spent weeks watching videos this way, and it got me nowhere. Not because the content was bad — a lot of it was good — but because watching whatever the algorithm serves you next isn’t studying. Every video starts from a different set of assumptions about what you already know. Nothing builds on anything. You finish a session feeling productive and retain almost none of it, and after five of them you have five different ideas of what you’re being graded on. It was the most frustrating part of the whole process.

What finally worked was picking a small number of sources and going through them properly, in order, start to finish. Consistency over volume. It sounds obvious written down; it wasn’t obvious while I was three hours into a playlist I’d never chosen.

The interviews themselves were no more consistent. Some asked me to design a distributed system from scratch. Others handed me an existing architecture and asked what I’d change. Some pushed on scalability, others on reliability, data modelling, or operational trade-offs. Across all of them, I don’t think I had two that were alike.

So I prepared for everything. Eventually I realised the unpredictability was largely an illusion — but first, the part of the problem that’s real.

The Engineering Manager dilemma

Given all that, I assumed these interviews would mostly evaluate how I approach problems, communicate decisions, and lead teams. That’s the job, after all.

They didn’t. Almost every one required deep implementation detail: architecture at the level of a senior or principal engineer, every decision justified, follow-ups getting more specific each time. Why this database. Why this consistency model. How does this component fail. What happens at ten times the traffic.

Before several interviews I heard some version of “you’re interviewing for a management role, so we don’t expect you to know every technical detail.” It was meant kindly. It was also not true.

Is that bar reasonable?

I’ve landed somewhere specific: the depth is right, the format is wrong.

The depth is right because a manager who can’t interrogate a consistency model can’t evaluate the decisions their team is making. You approve designs you don’t understand, and you find out they were wrong in production. If I can’t ask my engineers why not eventual consistency here, I’m not a technical leader — I’m a coordinator with a title.

But a 45-minute greenfield exercise doesn’t measure that. It measures recall under time pressure and the ability to perform architecture fluently for a stranger. Those relate to the real skill roughly the way a driving test relates to driving. The judgment that matters — which trade-off your organisation can actually live with, which design will be expensive to operate in two years, when not to rebuild — needs context the format can’t supply.

So the answer isn’t a lower bar for managers. It’s a better question. A few companies handed me a real architecture with a real problem and asked what I’d do. Those were the best conversations I had all year.

The format is what it is, though. Here’s how I prepared for it.

Rebuilding the foundation

I grouped the fundamentals into clusters rather than a flat list — partly for study, partly because it’s roughly how I now reason in the room:

• Data — SQL and NoSQL, data modelling, indexing, caching
• Distribution — CAP, replication, partitioning and sharding, read/write scaling, idempotency and concurrency control
• Communication — networking, API design, messaging, event-driven architectures, async and long-running workflows
• Reliability and operations — high availability, disaster recovery, rate limiting and backpressure, observability
• Security — authentication, authorization, and the boundary between them

This restored my confidence and wasn’t enough. Knowing the pieces is a different skill from assembling them under time pressure, which is the only thing the interview tests.

Hello Interview was the best structured resource — walkthroughs that explain why a decision gets made rather than presenting a finished answer. It comes in both video and written form, and I went with the written version, because I absorb things better reading than watching.

I also worked through it in a way that turned out to matter more than the source itself. For each problem I printed the final architecture diagram, then read the explanation with the page in front of me, annotating as I went — why this component is here, what it would break if you removed it, where the bottleneck sits, which decision I’d have made differently. By the end each diagram was covered in handwriting. A clean printed diagram tells you what the answer is. A marked-up one tells you why, and it’s yours.

Alongside that I kept ChatGPT open as a mentor. Any time something didn’t land, or I wanted to check whether I’d understood a trade-off correctly, or I disagreed with a choice the walkthrough made, I asked. Explain this differently. Why not the other approach here. What am I missing. That combination — a structured source to work through, a patient explainer for everything that source assumed I knew — was the single most effective part of my preparation.

Two books did the real work. Hacking the System Design Interview by Stanley Chiang is the one I’d hand to someone starting out — it covers the essential concepts and core components first, then moves into practice problems, and the problem chapters are sequenced so each one introduces components that the next builds on. You’re not dropped into a design on page one, you accumulate a toolkit and then watch it get used. Designing Data-Intensive Applications by Martin Kleppmann is the deeper one, and worth reading whether or not you’re interviewing.

Get Jekaterina Jegoscenko’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

And despite what I said about YouTube, three channels earned a permanent place — not as things to dip into, but as sources I worked through deliberately:

• Gaurav Sen — the best place to start. He builds concepts on top of each other rather than dumping them on you, and he’s more interested in why horizontal scaling wins past a certain threshold than in what to say when asked.
• ByteByteGo — Alex Xu’s channel, and the visual explanations are excellent. Short, animated, and unusually good at making a complicated system legible in a few minutes. Useful for filling gaps quickly.
• ByteMonk — concise and concrete, with a strong basics series and good real-world case studies. The videos are short enough to watch one over coffee, which meant I actually kept going.
• TechWorld with Nana is also excellent for anything cloud-native and Kubernetes.

The preparation that changed everything

One company worked in healthcare. My research pointed to one very likely question — design an appointment booking platform — so that’s what I practised the day before, end to end. I designed it myself first, then had an LLM pull it apart.

The actual interview asked something else. Instead of building from scratch, I was handed an existing architecture — a handful of services, each owning its own data, talking to each other over a message queue — and asked to evolve it. The new requirement involved assessing how urgent a patient’s case was and adjusting their appointment accordingly.

I hadn’t drilled that problem. But I’d spent the previous day inside the domain, so I wasn’t lost. I proposed a separate service for the urgency logic: it listens for the relevant events, scores each case using rules a clinician could read and audit, and publishes the result back out. Scheduling stays owned by the service that already owns it. Keeping a share of each doctor’s slots free for urgent cases avoids automatically rescheduling everyone else.

Then came the follow-ups. What happens when the service holding the medical data is unavailable — do you block the booking, or proceed normally and reassess when the data arrives? What consistency guarantees does this actually need, as opposed to the ones I’d reflexively reached for? Each question made me defend a decision I hadn’t noticed making. Several assumptions didn’t survive.

The task surprised me. The conversation didn’t. For the first time in the whole process I wasn’t solving an unfamiliar problem under pressure — I was having an architecture discussion with fellow engineers.

The pattern

That’s where it landed:

Companies ask you to design systems that resemble the systems they build.

Obvious in hindsight. The interviews were never unpredictable — I’d been preparing for an average of all possible companies instead of for the one in front of me.

So I stopped practicing random problems. Before each interview I researched the company properly: products, customers, engineering blog, stack, scale, and the problems their teams were most likely fighting. Then I designed a realistic problem in that space myself, and only afterwards brought in an LLM to pull it apart.

The point was never to predict the exact question — I rarely did. It’s that when the real task turned out to be a variant I hadn’t rehearsed, I could still hold a real conversation about the trade-offs that mattered to them. When an interviewer pushed on an edge case, I’d usually already been near it — because it’s the edge case their product lives with every day.

It isn’t a universal law. One online gaming company, hiring for a payments team, asked me to design a social media app with post sharing. Nothing to do with their product or the role. But that’s the other half of the advice: the classics still come up, and you should be able to design a feed, a URL shortener, or a chat system without preparation, because some interviewers will reach for a standard problem precisely because it’s standard. Domain research worked for me maybe four times in five. The classics cover the rest.

The order mattered more than I expected. Design first, challenge second. Earlier I’d used AI as a mentor — explaining things I didn’t understand. Here it was the opposite role: not a teacher but an opponent, and only after I’d committed to a design of my own. Asking for the architecture up front teaches you a solution, asking it to attack yours teaches you the reasoning. AI is most useful when it makes you think harder about what you’ve already produced, not when it produces it for you.

The thing I’d do differently

Looking back at that task, my strongest answer isn’t the one I gave. I went straight to services and events — boxes and arrows — before I’d made the actual problem explicit.

What I should have done first was walk through the user journey: the patient, the doctor and their schedule constraints, the clinic in between, and the business problem underneath it all — get the urgent cases seen sooner without wrecking everyone else’s day. Once that’s on the table, the architecture almost designs itself, and every choice has a why an interviewer can follow. Skip it, and even a correct design is hard to defend, because you never said out loud what it was solving for.

That framing is exactly the product thinking an Engineering Manager is meant to bring, and under pressure I reached for the architecture instead. The best answers don’t start from the components. They start from the user and the business problem, and let the components fall out.

What I’d tell you

I also recreated architectures of systems I’d built earlier in my career and interrogated them the same way: where are the bottlenecks I didn’t see at the time, what breaks at a hundred times the load, what would I simplify. That connected theory to things I’d actually lived through, and my answers stopped sounding rehearsed. (Eraser is excellent for this and I found it far too late.)

If you’re preparing:

1. Pick a few sources and finish them. Random videos feel like progress and aren’t. Consistency beats volume.
2. Print the diagrams and write on them. Reading an architecture is passive. Annotating one forces you to have an opinion about every box.
3. Research the company’s domain before every interview. This one mattered most; the rest is table stakes.
4. Keep the classics warm anyway. Four times in five the domain research paid off. The fifth time you’ll be asked to design a feed.
5. Start from the user journey and the business problem, not the architecture. The boxes should follow from the problem, not precede it.
6. Learn principles rather than memorising architectures — there’s rarely one right answer, only informed trade-offs against the constraints in front of you.
7. Use AI two ways: as a mentor while you’re learning, and as an opponent once you’ve designed something.
8. Draw architectures from systems you’ve actually built, then critique them.
9. Practise explaining your reasoning out loud. A good architecture you can’t explain scores as a bad one.

This took far more time than I expected, and it ended somewhere good. Even if I never sit another system design interview, the preparation made me a better architect and a sharper technical communicator — which was never interview-specific in the first place.