Preparing for Systems Design Interviews

Systems design interviews can feel like the hardest because you can’t really practice them. Or can you?

What is a systems design interview, anyway?

To get a software engineering job you will usually undergo a systems design interview. Unlike a coding exercise, you will be asked to design a distributed system. This typically means a service such as Airbnb or Uber where you have clients (mobile application or web) making requests to a backend. This backend will support a series of operations that may involve databases, queues, workers, caches, and, in general, other distributed systems.

System design interviews can also be the least fair. Interviewers are trained to distinguish lack of knowledge (understandable) from lack of intuition, or problem solving skills (less defensible). Yet, if you’ve used a queue and spent hours debugging pesky issues, your understanding is deeper and your intuition is just better. Muscle memory is real. If you haven’t been exposed to it, you are much more likely to be off-base.

What makes this interview hard

If you don’t have first-hand experience, it’s the toughest interview to prepare for. Many engineers don’t, and it’s not one’s fault! I experienced this at Microsoft back in the day. I implemented my data pipelines and algorithms in a “platform”, a proprietary service which later became Azure Cosmos DB. It’s certainly a distributed system, but you didn’t care: you just needed your pipeline to be correct and efficient. You barely ever had to think about the underlying service. The job of that platform team was precisely to give you this illusion that things “just work” so you can focus on your business logic. That’s a good abstraction and job specialization. Generally good things, except it can create blind spots in your skillset, which now come back to bite you.

Coding interviews can be prepared effectively with LeetCode, but these interviews are different. Sure there’s many preparation books, but it’s hard to rate your performance, much less give guidance. You are supposed to prepare your answer without peeking, and then compare it with the reference answer. But there’s too many degrees of freedom. Your answer might have little overlap with the proposed answer and still be correct. Or it might be fairly similar, but show a shallow understanding that will become apparent to the interviewer.

First try: LLM role-play

Once more, LLMs to the rescue. You can just ask your LLM of choice to role-play interviewer for you. That’s much better than answering a question in your head and then trying to compare it to a pre-existing written text.
If you find a PDF version of such books, or described in online articles, you can feed it to your chat and come with a prompt such as:

Read this system design problem and its solution.
You role-play the interviewer and I'll be the interviewee.
Never give away answers, but if you see I'm lost, nudge me subtlty towards the right direction.
When we are done, I will ask you to evaluate me against staff engineer standards.

This is a step up, but still not good enough. It will call you out if you are flat out wrong, or can probe you on topics you hadn’t anticipated. But LLMs have this tendency to compliment you (you are absolutely right!), when what you need is tough love.

Let’s do it for real

I believe AI can help you overcome this challenge, not as a role-playing game, but allowing you to build the service for real.
Say you want to “Implement Google Maps”. Start by simplifying: what’s the bare minimum? A web page where I enter a starting and end addresses, and hit Submit. You’ll have a server that receives the addresses, calculates the possible routes, and returns the best. Start all with mocked data.

Now, if you’ve asked the AI to do this, you’ll probably have an html page, and probably a nodejs server running locally. Great start, except we wanted to practice distributed systems, not prompt engineering.
The key now is to deploy this in any public cloud (AWS, Google Cloud, etc, just not your laptop).

Let’s begin by asking the LLM how to deploy this in the cloud. This help has lowered the bar drastically. If you plan on ever bringing up kubernetes in the interview, let’s use it here too. Don’t stop until you have it running somewhere and you can use curl or a webpage to get responses from it.

The word salad from hell

Engineers without first-hand experience sometimes bring up a word salad that includes load balancers, API gateway, DNS, Redis, CDNs, etc. without having really used them. The interviewer can tell quickly. But throwing all these words is usually not necessary, a self-inflicted wound from wanting to impress.

English is not my first language. Thus, I try to make my sentences simple and short. It suffices to write effective text that conveys my message. Apply the same principle. If you don’t know how load balancers work, don’t bring them up unless necessary. If you haven’t configured and fine-tuned auto-scaling, don’t try to impress the interviewer by name-dropping it. It’s counter-productive.

Here’s my challenge to you: try incorporating any concept you may want to bring up in the skeleton solution we created earlier. Again, now it’s easier than ever. Do you want Redis? The LLM will help you set it up, provide the correct SDK for your language and implement the code. Make sure you understand it. Challenge the LLM to discuss trade-offs.

Isn’t this too much work?

Even with LLMs doing the heavy lifting, it is indeed a lot of work.
However, unlike LeetCode, I consider it time well spent. Chances are that what you learned is useful to you at some point in the future.

First, you will see how LLMs can help you set up infrastructure easily and quickly, not just programming. Second, if you had no idea how you would implement a service to share with the world (such as the Google Maps example), now you know. Third, if this helps you land a job or get another competitive offer, it’s likely one of highest ROI activities you can do.

Design intuition isn’t learned by studying “best practices,” but by watching abstractions leak when you force yourself to own them end-to-end.