How I Run System Design Interviews for Data Engineers
Why System Design Still Matters
Hi, fellow future and current Data Leaders; Ben here 👋
Today we have another amazing guest author.
Mehdi Ouazza —better known as mehdio—is a data engineer and developer advocate at MotherDuck with over a decade of experience building data systems at companies like Klarna, BackMarket, and Trade Republic. He combines deep engineering expertise with a playful, approachable style, creating blogs, videos, and social content that make complex data and software topics easier to grasp. When he’s not shipping pipelines or crafting educational content, he’s usually experimenting with creative ideas that bring a fresh, off-beat energy to the developer community.
He’ll be sharing how he runs system design interviews for data engineers, but I won’t get too ahead of myself.
So let’s jump into the article!
After hundreds of technical interviews for data engineering positions, I’ve developed what I call the “exploration” approach to system design interviews. Think of it like exploring a new city: you start with a bird’s-eye view of the whole map, then zoom into specific neighborhoods that look interesting, getting to know some streets really well while keeping track of how they connect to the bigger picture. It’s become my secret weapon for truly understanding a candidate’s technical knowledge while keeping the conversation engaging and productive.
This type of interview matters even more in our current AI-assisted world. Coding matters less than ever before. We can generate vast amounts of code with tools like Copilot or ChatGPT. But understanding how components work, their foundations, and their trade-offs? That’s irreplaceable.
If you’re interviewing with me, consider this your cheat code.
Setting the stage
Be human
You would be surprised how many interviewers miss the obvious: presenting yourself as a human being. I’ve sat through countless interviews where the interviewer jumps straight into “I’m the head of engineering, let’s talk about Kafka.” No. Just no.
When I start an interview, I actually introduce myself: where I’m based, how long I’ve been with the company, maybe share that I once debugged a production issue on my phone while biking (true story). This isn’t fluff, it’s creating an environment where candidates can relax and show their best selves. Interviews are stressful enough without feeling like you’re talking to a robot, especially over a video call where human connection is already harder.
I also explicitly tell candidates upfront: “We’re going to start really broad with the whole system, then zoom into specific areas for technical depth. It’s completely okay if you don’t know everything: nobody does. I’m more interested in how you think through problems than memorized answers.”
This transparency matters. Without it, candidates might think “Wow, this is easy” when I ask the initial broad question, only to panic when we drill into the internals of Parquet files.
That’s not fair to them, and it doesn’t help me assess their true capabilities.
Live white boarding collaboration
I use Excalidraw for live collaborative drawing: it’s free and requires no setup/login. Candidates can visualize their architectures while we discuss them. This isn’t just about pretty diagrams; it’s about thinking visually and communicating complex systems clearly.
I actively support candidates during the interview. If they get stuck, I’ll introduce a source system or clarify a requirement. This isn’t a gotcha test : it’s a collaborative design exercise, much closer to real work.
After all, how often do we get perfectly clear requirements from stakeholders? 😉
Wide & zoom through 3 core scenarios
I need someone who understands how components connect, why certain architectural decisions matter, and can demonstrate real depth in at least some areas, depending on the requirements of the role.
The exploration metaphor works because we’re mapping out their knowledge landscape together.
I usually cover 3 main system design scenarios, each highlighting different aspects of data engineering. In a 45-60 minute interview, there’s rarely time for all three. If a candidate shows strong depth, I move on quickly; if they struggle, I spend more time there. The goal is to map both strengths and weak spots.
1. Simple ETL data stack
I start with something deceptively simple: “You have a small e-commerce website, and you’re getting data that you need to analyze. Design your first data infrastructure. How would you build the data stack?”
The question is intentionally vague. Good engineers don’t just dump technology names; they ask questions, make assumptions, and tailor solutions to specific needs. This is where the real engineering happens!
Some might argue: “Why do I even need a data stack? I can just query my current database!” And that’s a perfectly pragmatic answer.
Then I’d evolve the scenario: “Now imagine you have a table larger than 100GB and need to run analytics queries. Would you still rely on the same setup? If not, how would you redesign the stack, and why?”
When candidates sketch their initial architecture (ingestion → processing → storage → serving), I probe further based on the technologies they mention. Here are some common examples:
File format deep dive
“You mentioned storing data in object storage. What format would you use?”
“Why Parquet over CSV?”
“If Parquet is so fantastic, what are its limitations?”
“I see Iceberg and Delta Lake mentioned everywhere. What problems do they solve that Parquet alone doesn’t?”
This progression reveals whether someone just memorizes buzzwords or truly understands the trade-offs.
Here’s how a typical deep dive might unfold:
The data warehouse vs Lakehouse debate
“Should compute run inside or outside your data warehouse?”
“What are the implications of each approach?”
“If running inside, what should you watch out for? Indexing? Data volume?”
These questions separate those who’ve actually built and operated systems from those who’ve only read about them.
2. Streaming pipelines
Next, I change the requirements: “Now I need 1-5 minute latency between source data and where the data is being served. Redesign your solution.”
This shift from batch to streaming reveals a different dimension of understanding:
The Pub/Sub Deep Dive
“You mentioned needing a pub/sub system. Which ones do you know?”
“How does Kafka actually work? What are brokers, partitions, and consumer groups?”
“What’s the difference between at-least-once and exactly-once semantics?”
“How do you handle late-arriving data in streaming?”
Again, I’m looking for practical knowledge here. Anyone can say “use Kafka,” but understanding partition strategies, offset management, and the challenges of maintaining streaming infrastructure shows real experience.
3. Customer-facing analytics
The final scenario is more end-to-end, with specific requirements: “You need to expose pre-computed analytics to your operational web application. How would you architect this?”
This is where things get interesting, as there are again multiple solutions to the problem.
Some examples of key questions :
“Can you connect your data warehouse directly to your web app? What’s the usual latency ?”
“What happens when 10,000 users hit your analytics dashboard simultaneously?”
“Where would you place caching layers?”
“How do you handle data freshness vs. performance trade-offs?”
The best candidates recognize this as a classic OLTP vs. OLAP problem and discuss solutions like read replicas, caching strategies, pre-aggregations and more.
What to look for
Both breadth and depth are important, and the shape of them will really depend on the role, as they are many different data engineer profile
Here are a few examples of the indicators I’m watching for.
Depth indicators
When someone truly understands a technology, they can discuss:
Internal mechanics: How does Spark actually distribute work? What’s happening during a shuffle?
Failure modes: What breaks when you lose a Kafka broker? How does Delta Lake handle concurrent writes?
Performance implications: Why does a broadcast join beat a shuffle join for small tables?
Operational realities: How do you debug a slow dbt model? What metrics indicate a streaming backlog?
Breadth indicators
Strong candidates can also:
Connect different technologies and explain their relationships
Understand why certain tools exist (what problem were they solving?)
Recognize patterns across different solutions
Make appropriate trade-offs based on constraints
Each level reveals more understanding. A junior engineer might stop at “Parquet is columnar.” A senior engineer discusses compression algorithms, predicate pushdown, and why you might choose Avro for streaming despite Parquet’s advantages.
Red Flags and Green Flags
How to prepare?
If you’re preparing for interviews like mine, here’s a few tips by order of importance :
Pick 3-4 technologies you use and go deep : understand their internals, failure modes, and alternatives
Practice explaining : If you can’t explain it simply, you don’t understand it fully
Build something real : even a toy Kafka setup teaches more than reading docs
Break things : Kill processes, corrupt data, fill up disks. Understanding failure teaches resilience
Read post-mortems : Learn from others’ production disasters
The value beyond AI
This interview style works because it mirrors real engineering. We start with vague requirements, ask questions, make trade-offs, and solve problems collaboratively. It’s rare for candidates to completely fail: everyone can draw something and explain at least some components.
What varies is depth, breadth, and the ability to reason about trade-offs. That’s what separates great engineers from good ones, and it’s what this interview approach reveals.
Remember: in the age of AI-assisted development, your value isn’t in memorizing syntax or configuration details. It’s in understanding systems deeply enough to design, debug, and evolve them.
Prompt engineering matters, but the fundamentals remain and will help you grow in this wild west era.
Events
Articles Worth Reading
There are thousands of new articles posted daily all over the web! I have spent a lot of time sifting through some of these articles as well as TechCrunch and companies tech blog and wanted to share some of my favorites!
The unwritten rules of being a head of data
A friend of mine became head of data but they had a hard time stepping away from coding. They kept shipping code late at night after their normal work ended.
This was fine at first until they realized, months later, they hadn’t really led anything of note for the business. There was nothing they had really driven.
They had been promoted, but still were working like a senior engineer. Delivering lots of well-designed work but not actually taking a stand on any specific project.
Once you become a data leader, the game changes. What the business needs from you isn’t just to write another Python script or notebook. But that’s not always made clear. Some companies or mentors will help guide you as you become a leader. Others will give you the promotion and then hope you figure it out.
In this article, I wanted to discuss some of the unspoken rules and lessons you need to pick up fast if you are a data leader.
Organization Architecture
By Alex Ewerlöf
The reliability of a service is directly impacted by the shape of the organization providing it. The shape, not the budget, headcount, or maturity level —as irresponsible leaders like to frame it!
This article elaborates:
Why does the shape of the organization matter for reliability?
How does it impact communication between teams and by extension interactions between the components of the system?
What insight can be unlocked with consumer journeys to create a healthy organization that builds reliable systems?
End Of Day 204
Thanks for checking out our community. We put out 4-5 Newsletters a month discussing data, tech, and start-ups.
If you enjoyed it, consider liking, sharing and helping this newsletter grow.
 | A guest post by
|
Great article! Thank you both.
Thanks for advises! Some time ago I built the great framework for data engineering system design interview - https://blog.surfalytics.com/p/ultimate-cheatsheet-for-data-engineering