I Failed 4 System Design Interviews Before I Understood What They Were Actually Testing

The first system design interview I failed, I walked out thinking I had done quite well. I had described a system with a load balancer, several microservices, a primary database with read replicas, and a caching layer in front of the most frequently accessed data. I had drawn boxes and arrows. I had mentioned Kafka, which I had read was a good thing to mention.

The rejection email arrived two days later: "Didn't demonstrate sufficient depth on scalability trade-offs."

I studied more. I did the same interview three more times, with minor variations, different companies, different problem statements, slightly different components in my diagrams. The feedback was different each time but pointed in the same direction. Not enough depth. Didn't explore trade-offs. Struggled when pushed on specifics.

On attempt five, I finally understood what was actually being evaluated. It wasn't what I knew. It was how I thought.

What I Thought the Interview Was

My mental model of a system design interview was: they give you a problem, you describe a system that solves it, they assess whether the system is good. Like a coding problem but with boxes and arrows instead of code. The measure of success was whether my proposed architecture was technically sound.

This model is wrong, and it's the reason most developers who fail these interviews keep failing them even as they accumulate more architectural knowledge. You can memorize every component in every system design primer ever written and still fail, because the interview isn't primarily testing what you know. It's testing how you operate when you're given a complex, underspecified problem with no single correct answer and someone watching how you handle it.

The reason my first four attempts failed is that I was demonstrating knowledge, showing the interviewer what I had studied, rather than demonstrating thinking, which is what they were actually trying to see.

Interview One: Designing a URL Shortener

Classic problem. I recognized it immediately from my preparation and launched into the design without pausing. Hash function to generate short codes, key-value store mapping short codes to URLs, redirect endpoint, CDN cache in front of the redirect for frequently accessed URLs. I had the components out within the first few minutes.

What I didn't do: ask a single clarifying question before starting. I didn't know how many URLs the system needed to handle per day, or whether the traffic was read-heavy or write-heavy, or what the latency requirement on the redirect was, or whether the short codes needed to be unpredictable for security reasons or could be sequential. I assumed all of these things and built for my assumptions, which may or may not have matched what the interviewer had in mind.

Towards the end, the interviewer asked what I would do if the system needed to handle ten billion redirects per day. I gave a generic answer about horizontal scaling and adding more cache nodes. It wasn't wrong. It was the answer you give when you're applying a pattern rather than thinking about the specific problem. It didn't demonstrate that I understood where the actual bottlenecks would appear at that scale, the hash generation, the key-value store write path, the cache invalidation strategy, or that I had thought about the order of magnitude difference between "a URL shortener" and "the world's URL shortener."

Interview Two: Designing a Notification System

I had studied more between attempts. I knew about fan-out patterns, push versus pull delivery models, the trade-offs between processing notifications synchronously versus queuing them. I described these with more confidence than the first interview.

About halfway through, the interviewer asked a question I hadn't prepared a clean answer for: "What happens if a notification fails to deliver?"

I said we would retry it.

"How many times? With what backoff interval? How do you distinguish between a transient failure, the delivery service is temporarily down, and a permanent one, like the user's device token being invalid? At what point do you stop retrying and mark the notification as permanently failed? What does the user experience when that happens, do they see a missed notification indicator, or does the system simply not tell them? And how do you handle a notification that was successfully queued but the service that was supposed to deliver it crashed before doing so?"

I had designed a notification system without seriously thinking about what happens when it doesn't work. I had designed the happy path and called it a design. In production, at scale, the happy path is the easy part. The interesting engineering is the failure surface, and I had left mine entirely unexamined.

Interview Three: Designing a Rate Limiter

By the third interview I was studying failure modes explicitly. I also chose a problem with narrower scope, thinking that a smaller system would let me go deeper on the parts that mattered.

I went deep on the algorithms: token bucket, sliding window log, fixed window counter, sliding window counter. I walked through the trade-offs between them, accuracy versus memory efficiency, implementation complexity versus operational simplicity. The interviewer seemed engaged.

Then: "Where does this run in your architecture?"

I said: at the API gateway.

"You have multiple API gateway instances running for availability and load distribution. Is the rate limit enforced per instance or globally across all instances? If it's global, where does the shared counter state live, and what are the consistency and latency requirements for reading and writing that state? What's the trade-off between exact rate limiting, which requires strong consistency and therefore coordination overhead, and approximate limiting, which is faster but may allow small bursts above the limit? What's the cost to your business of over-counting versus under-counting? And what happens to in-flight requests when the state store is temporarily unavailable?"

I had designed the rate limiter as a component in isolation. The interviewer wanted to see it in context, how it integrates with the surrounding system, where its dependencies are, what the failure modes at the integration boundaries look like. A component that appears to be a solved problem when considered alone often has significant complexity exactly at the points where it connects to everything else. I had missed all of it.

Interview Four: Designing a Search Autocomplete System

At this point I had revised my approach substantially. Ask clarifying questions at the start. Think about failure modes. Consider integration boundaries. I did all three.

It went meaningfully better than the previous attempts. I got further into the conversation before running out of things to say. I still didn't get the offer.

The feedback was different this time, which was progress of a kind: "Good technical depth, but communication could be clearer when discussing trade-offs."

I had been narrating my design rather than discussing it. I was describing what I was doing, "here I would add a cache, here I would add a queue", rather than thinking out loud in a way that invited the interviewer into the reasoning process. The interview is a conversation, not a presentation. The interviewer is not an audience watching you perform competence. They are a collaborator, and the best candidates treat them that way, by asking for their view, by flagging uncertainty explicitly, by treating the interview as a joint problem-solving session rather than a solo demonstration.

Interview Five: What Changed

Before the fifth attempt, I did something I hadn't done in the previous four: I practiced out loud with a friend who had recently passed this type of interview at a company I respected. Not to get the architecture right, to practice the conversation. We ran through three mock problems over two evenings. She interrupted me constantly, asked questions mid-design, pushed back on decisions I made without sufficient justification, and told me afterwards what felt like genuine thinking versus what felt like recitation.

The structural shift in how I approached the fifth interview was this: I stopped trying to produce a good design and started trying to have a good conversation about a hard problem.

I opened by spending five minutes asking questions before drawing anything. What scale are we designing for? What are the latency requirements? Is this more read-heavy or write-heavy? Are there consistency requirements I should know about, does a user need to see their own writes immediately, or is eventual consistency acceptable? Are there any existing systems I should assume are available, or are we building from scratch? I wrote the answers on the whiteboard as I received them, creating a shared foundation that both I and the interviewer could refer back to throughout the conversation.

When I started designing, I narrated reasoning rather than components. Not "I'm adding a cache here" but "the read-to-write ratio you've described suggests we'll have significant repeated queries for the same data, I'd add a cache here to avoid hitting the database on every read, accepting that we'll need to think carefully about invalidation. If consistency were more important than it is in this case, I might make a different call." The interviewer knew why I was making each decision, which meant they could engage with the reasoning rather than just the outcome.

When I reached a genuine trade-off I wasn't certain about, I said so. "I can see two approaches here and I'm not sure which is better for this specific case. I lean towards option A because of reason Y, but I'm aware that creates problem Z. Is that a trade-off you'd want to explore, or is there a constraint I'm missing that makes the choice clearer?" This is not a performance of uncertainty to seem humble. It is what a senior engineer actually does when thinking through a difficult design problem. It invites the interviewer to contribute, which makes the conversation better, which makes you look better.

I got the offer. Not because I knew more than in the previous four attempts. Because I finally understood what the conversation was supposed to be.

What These Interviews Are Actually Testing

Can you scope an ambiguous problem? Real engineering problems don't arrive with complete specifications. Senior engineers' first move when given a vague requirement is to make it less vague, to identify the constraints, clarify the requirements, and define what's in scope before doing any design work. Doing this at the start of a system design interview is not a delay tactic. It signals exactly the behaviour that senior engineers exhibit, and interviewers recognise it as such.

Do you think about what breaks? Happy path designs are the easy part. Any reasonably experienced engineer can describe a system that works under normal conditions. The interesting engineering, and the signal the interviewer is looking for, is whether you have thought about what happens under load, under failure, under unexpected input patterns, under concurrent access from many users doing the same thing at the same time. Failure mode thinking should not be an afterthought you add at the end if you have time. It should be woven through the design from the start.

Can you articulate trade-offs? There is almost never a universally correct choice in system design. Consistency versus availability under network partition. Latency versus throughput. Read optimisation versus write optimisation. Operational simplicity versus architectural flexibility. The answer to most system design questions is "it depends," and the follow-up is "here's what it depends on and here's my reasoning given the specific constraints we've established." Demonstrating that you understand both sides of a trade-off and can explain your choice given the context is more valuable than always choosing the textbook answer.

Can you stay clear under pressure? You will be interrupted. You will be pushed on decisions. You will be asked to change direction mid-design when the interviewer introduces a new constraint. You will be asked questions you don't know the answer to. How you handle all of this, whether you stay calm and continue thinking clearly, or get flustered and lose the thread, is part of what's being observed. The ability to handle being challenged without becoming defensive or losing clarity is a signal about how you function in real engineering environments.

The Practical Advice

Spend the first five minutes asking questions, every time, even when the problem seems well-defined. There are always clarifying questions worth asking. The act of asking them signals that you think before you design, which is the right signal to send at the start of an interview.

Write the constraints on the board before you draw any components. Scale numbers, latency targets, consistency requirements, traffic patterns, any constraints the interviewer has mentioned. Refer back to them explicitly when you make design decisions. This shows the interviewer that your choices are driven by the specific requirements of this problem, not by architectural patterns you memorized.

Start simple and layer complexity. A design that starts as three components and grows into eight as the conversation reveals new requirements demonstrates better thinking than a design that starts as eight components and can't justify why each one is there. Complexity should emerge from requirements, not be pre-loaded to demonstrate knowledge.

Read about real systems, not system design prep materials, but the actual engineering blog posts and original papers from the teams that built systems at scale. The Dynamo paper. The Cassandra architecture documentation. Engineering posts from Netflix, Stripe, Cloudflare, Uber. Real systems were built to solve real constraints that somebody actually had. Understanding the constraints makes the design decisions legible. That understanding transfers to novel problems in a way that memorized architecture diagrams don't.

Practice out loud, with someone who will interrupt you. The technical knowledge and the communication skill are separate skills that require separate practice. Knowing what a sliding window rate limiter is and being able to explain clearly, under interruption, why you'd choose it over a token bucket in a specific scenario with specific constraints are not the same thing. The second one needs to be practiced as a spoken skill, not a written one.

The fifth interview was not the one where I knew the most. It was the one where I finally understood what the conversation was for, and stopped trying to win it by demonstrating how much I had studied.