From Zero to System Design in One Week

A week ago I had never done a system design interview in my life. Then I got one scheduled with a Dublin startup, and I had seven days to get ready.

This is what that week taught me. Not just about pipelines and queues, but about preparing fast, and about the gap between how you imagine an interview and how it actually goes.

The first problem was not technical

My honest first reaction was not "how do queues work." It was a strategic question I did not know how to answer. Should I practice the existing well-known system design patterns that everyone studies, or should I prepare based on what this specific company actually builds?

I went with the company. I read everything about their product, their data sources, the problems they were solving, and I built my preparation around designing a system for them specifically.

That decision turned out to matter more than I expected, and not in the way I hoped. More on that later.

The concept that broke my brain, then clicked

The hardest thing for me to understand was failure handling in a data pipeline. Specifically, the difference between how a scheduler and a queue handle errors.

I kept confusing the two. Here is where I landed after it finally clicked.

A scheduler like EventBridge triggers a job and retries if the invocation itself fails. If all retries are exhausted the event goes to a dead letter queue and someone gets alerted.

A queue like SQS works differently. When a consumer picks up a message the message is not deleted immediately. It becomes invisible for a set time. If the consumer finishes and acknowledges the message, it is deleted. If the consumer crashes halfway through without acknowledging, the queue makes the message visible again and another consumer retries it.

The insight that unlocked it for me was this. A scheduler only knows whether a job started. A queue knows whether a job finished. That is why a queue sits between the stages of a pipeline that can fail mid-process. It catches the silent crash that a scheduler would never notice.

Once I understood that one distinction, a lot of the rest of the pipeline made sense. Where to put a queue, where a direct trigger was enough, and why.

What actually happened in the interview

Here is the part I did not see coming.

I had prepared to design their system. The problem I was actually asked to design was a well-known one, the kind you find in any system design tutorial on YouTube. Not something tied to their product at all.

That reframed something important for me. Companies mostly are not testing whether you understand their specific architecture. They are testing whether you can reason through a general design problem out loud. The classic problems exist for a reason. They are a shared language for evaluating how you think.

If I did this again I would split my preparation. Learn the common patterns first because those are what you are most likely to be asked. Then layer company-specific understanding on top, because it helps you ask better questions and it never hurts to show genuine interest.

The outcome

The result was a no. And I will be honest, it was disappointing, because the interviewer was engaged and helpful the whole way through. He coordinated, gave examples, guided me when I paused. It felt like a good conversation. The feedback afterwards was that it came down to experience level, not anything specifically wrong.

That is a strange kind of rejection to sit with. Nothing was wrong, it just was not quite enough yet.

But here is what I keep coming back to. A week before this I could not have held a one hour system design conversation at all. By the end of that week I could, and I did, without freezing. The gap now is experience, and experience is the one thing that only closes with time.

What I would tell someone facing their first one

Practice the common patterns. You are far more likely to be asked to design something that already exists than something unique to the company.

Learn failure handling properly. Anyone can draw boxes and arrows for the happy path. What separates a real answer is what happens when a stage crashes halfway through.

Talk out loud the entire time. The interviewer is not grading your silence. They are trying to follow your thinking.

And if the answer is no, ask for feedback. The honest kind is worth more than the result.

I am not done with this. The next one will go better.