Calvin Barker

Reflections and rantings from a system design interviewer

2025-12-22

I've given hundreds of technical interviews in my career, largely on system design this past year.

When I interview, I'm looking for signals to answer:

  • What's the true breadth and depth of your knowledge in this space?
  • How much trust and independence can I give you? Do you know when to ask for help?
  • What are you like to work with? Do I want to work with you?
  • How do you define importance, triage, and make tradeoffs?
  • To what extent do you think about why you're doing something?
  • Can you make and commit to a decision knowing that data is imperfect and ever-changing?

I want people to succeed. This list exists because I kept seeing the same avoidable mistakes get in the way of strong responses.

It frustrated me to now end that people would get in their own way of positive responses to my questions above.

Egregious use of AI

You are not sly.

Your glasses betray you. I see the reflection of you switching between ChatGPT and our Excalidraw board.

When I ask, "So, what do you know about Rokt?" and you respond with, "Oh, uh, not much, it's, um . . . the global leader in commerce-driven personalization, transforming the transactional moment into a high-value, performance-optimized revenue engine for the world’s most innovative brands," I want to roll my eyes out of the back of my skull.

I want to know you. I want to hear your voice. How you think about the world, the problems you see, and the approaches you take.

I do not expect you to know everything about everything. In the real world, I would want you to ask for help when you need it; a technical interview should be no different. I've written about the value of admitting, "I don't know, yet", and it's a positive signal to me if a candidate recognizes the limits of their knowledge.

Reducing yourself to an LLM's mouthpiece without sharing your own thoughts signals that you likely won't come up with novel solutions as you defer to the wisdom of a model whose purpose is to provide the next most expected string of words.

Zero research about the company prior to the interview

I care deeply about what I do, and I want to work with others who feel the same. Getting to an interview and not having a basic understanding of what the company does is a bad sign.

Doing your homework before interviewing also benefits you by filtering out obvious values mismatches and considering the advice of Warren Buffett to "[n]ever invest in a business you cannot understand" when allocating the investment of your most precious commodity of all -- time.

Before going into an interview, I recommend you spend some time researching the company, learning about its main products, wrapping your head around its long-term economic model, and coming to a conclusion as to whether or not you think it makes sense. (LLMs can be great tutors for this exercise.)

Note: If you specifically found this post by Googling my name before an interview with me, then great! You're doing exactly what you should be doing, and consider yourself rewarded with a cheat sheet on how to succeed with me.

Not starting with the customer

There is no purpose in building anything if nobody's going to use it. If nobody notices that your system exists, then you've committed the economic equivalent of digging a hole and filling it back in.

Tinkering with tools for the sake of learning those tools is totally fine with a personal hobby project. On the other hand, a successful commercial system requires starting with the human being who it's meant to benefit, and a quick exercise to flesh out your view of this abstract entity is by answering some of the Five Ws:

  • Who are they?
  • Where are they located?
  • What are they doing while using it?
  • When are they using it?
  • Why are they using it?
  • How are they using it?

The questions could be infinite, but it's important to at least ask the basics. Some examples of how this might impact your design:

  • If your customers are only in the United States, then your system's off-peak hours are highly predictable.
  • If your customers log in once a day, then you probably don't need up-to-the-minute data refreshes in the interim.
  • If they're largely in rural areas that only have 3G internet speeds, then you need to be extremely judicious about the assets you're loading in the interface.

My simple advice is to literally draw a stick figure representing your customer on your whiteboard before doing anything else to remind you of the humans your system will impact.

A very bareboned example of a system diagram including a draw person as the customer You don't need to be an exceptional artist to draw a simple stick figure.

Skipping the most important nonfunctional requirement of all: making money

This may be controversial and overly simplified, but at a for-profit company, a system's ultimate goal should be to enable profits.

If your system generates $500k but costs $5 million to run, then money may very quickly become your bottleneck. A system built with a skeleton crew at a pre-revenue startup will look dramatically different than one at Google, and it's important to recognize the context and constraints in which the system exists.

My gripe is likely most relevant for differentiating between senior and staff candidates, but if you can't ignore the economic impact while designing a real-life system, then you shouldn't ignore it for a mock one either.

Inflexibly following the Hello Interview delivery framework

Don't let my complaints fool you - I find system design reviews and interviews intellectually stimulating and, I daresay, fun.

At the time of this writing, Hello Interview seems to be the most popular website for system design prep, and I've noticed that candidates following its delivery framework tend to come up with better solutions than those who don't. For this reason, I am glad that it exists, and I recommend people use it.

I've occasionally noticed an issue with candidates, though, struggling to deviate from the framework if I ask certain follow-up questions from my curiosity or if I ask to cut a certain section short (usually the API design) to save time for heavier sections. It can feel like a minor panic that the interview isn't going exactly to plan.

I don't notice it frequently, but my recommendation is more practice until you're consistently comfortable.

The Hello Interview delivery framework makes this statement on capacity estimation:

Many guides you've read will suggest doing back-of-the-envelope calculations at this stage. We believe this is often unnecessary. Instead, perform calculations only if they will directly influence your design. In most scenarios, you're dealing with a large, distributed system – and it's reasonable to assume as much. Many candidates will calculate storage, DAU, and QPS, only to conclude, "ok, so it's a lot. Got it." As interviewers, we gain nothing from this except that you can perform basic arithmetic.

I was surprised by the advice to "perform calculations only if they directly influence your design" because calculations should always directly influence your design.

I am of the Grug Brained Developer cult regarding complexity. I firmly believe that strong software engineers should only add complexity when absolutely necessary. Tying back to the original questions I'm trying to answer during an interview, I need to figure out how much I can trust you to avoid needless complexity in my already-complex systems.

Your calculations don't have to be perfect. Just use realistic powers of 10 for your values and consider what happens with 10x growth.

Spend a few minutes with your initial BOE calculations. If you find out that you are, in fact, dealing with a large, distributed system, then fine. Add your Kubernetes clusters. Throw in your multi-region Redis caches. Invite the complexity demon right inside the house and offer him a comfy seat and a warm cup of Kafka.

But if you question the reasonable assumption that you're dealing with a large system, and suss out that your app will only deal with 10 QPS at peak load and ingest 1GB of data per year, then you've uncovered a dramatically different question than what you might have seen at first glance.

Either way, if you shoot from the hip during system designs, I fear you.

What's the point of all this if I don't try to point people towards making themselves better? Start here and see where they take you: