The Interview Question That Changed How I Think About System Design

About six or seven years ago, I went through an interview for a mid-level .NET role.

One of the questions has stayed with me ever since:

A user clicks a button on the UI to generate an Excel or PDF report. The report generation takes around five minutes (time can be arbitrary). The user has to wait for it to finish. How would you optimize this flow?

At the time, I focused on what I knew best: performance. I started thinking about how to make the report generation faster. Maybe I could optimize the SQL queries, reduce data transformations, or cache parts of the result. If I could get the process down from five minutes to one, that felt like a big win.

But even if I made it five times faster, the user still had to wait. If the browser crashed, they lost everything. If the network dropped, the process stopped. If they closed the tab, all progress was gone.

It wasn't really a performance issue at all, it was a design issue.

What I Missed Back Then

Looking back, I realize I was stuck in the mindset of "make the code faster". Not that there's anything wrong with that, performance optimization is a valuable skill. What I didn't see immediately was the bigger problem. The app was doing all this work synchronously, holding the user hostage until it finished. I did eventually figure it out, with a few nudges from the interviewer.

The better question wasn't "How can I make this faster?"

It was "Why is the user waiting in the first place?"

If something takes minutes (or hours, days) to complete, it shouldn't block the user. It should happen in the background, out of the main request flow, while the user moves on with their work.

Still, don't forget to optimize the code itself. Database queries, data processing, and file generation all matter. Maybe there's a missing index, an inefficient loop, or a better library for creating Excel files. But those optimizations are just part of the solution, not the whole picture.

How I'd Solve It Today

Today, I'd still start with the same UI button. The user clicks "Generate Report," but instead of waiting, the backend accepts the request, saves it somewhere (maybe as a job record in a database), and returns right away. This is the essence of building asynchronous APIs. The job is then picked up by a background worker.

The worker can be a hosted service, a Quartz job, or even an AWS Lambda Function triggered by a queue message. It handles the heavy lifting: pulling the data, building the file, and uploading it to storage like S3 or Azure Blob.

Once the report is ready, the worker updates the job status to "completed" and notifies the user. That could be an email with a download link or a real-time SignalR message that shows up in the app. The link points to the stored report, served securely from the backend.

Now, the user isn't waiting on a long-running HTTP request. The server isn't holding open connections for minutes. If something fails, it can be retried automatically. You also have the option to track progress or cancel the job if needed. And if a hundred users request reports at once, the system can scale without locking up.

The experience feels faster, even if the actual report generation time hasn't changed. Because in the end, users don't care about performance metrics, they care about responsiveness.

Why I Still Use This Question

A few years later, I started using this exact question when interviewing other developers. Not to trick anyone, but because it reveals how people think.

Some candidates go straight to optimizing code and queries, just like I did back then. This is a good sign that they know their way around performance tuning. I can proceed with further technical questions around algorithms, data structures, or database optimization.

Others pause for a moment and start thinking about user experience, background processing, and fault tolerance. That's when the real conversation begins: queues, retries, notifications, secure file sharing, etc. There are so many ways you can spin off this one scenario into a broader system design discussion.

There's no single right answer. But there's a big difference between someone who focuses only on code and someone who can design a scalable system.

The Lesson

When I first heard this question, I thought about making the code faster. Now I think about making the experience better.

Optimizing a query or loop can help, but it doesn't fix waiting, failures, or scalability. If many users start the same report at once, a synchronous design breaks down fast. An asynchronous flow keeps the system responsive and resilient, no matter the load.

That shift from optimizing functions to designing scalable systems is the difference between a good developer and a great one.

If you want to go deeper into building systems that scale, my Clean Architecture course walks you through exactly that. You'll learn how to structure applications, separate concerns, and design systems that grow without breaking.

Hope this was helpful.

See you next week.