Generally sound advice, if elementary.

However, making money is not an engineering problem. My previous employer 5x’ed their revenue with a largely feature-complete Rails application by hiring a kick-ass marketing team and actually looking at the usage analytics to tweak small things like form structure, the on-boarding flow, etc. The system design solves problems like scaling performance, avoiding tech debt, scaling headcount (microservices let multiple teams work on the code in parallel), and providing resilience, all of which have business value that is harder to quantify as easily.

I find it strange, to what extent people dive into the process of software design while calling it system design. Is your dev team junior or senior? Are they all in an office somewhere or divided between two sites 4 timezones appart? How’s the leadership structure? Your software architecture must form a coherent part of the organizational, dare I say Enterprise, architecture. And since the latter is rarely sensibly managed, there’s a limit to what you actually can do with software. Heck, the knowledge, that some time within next 6 months someone is going to make a really random strategic decision nullifying most of your design is a really important input to your design process.

Your system very rarely is just the software and at the very least the system context (of which customers are a part) is a major driver of your decisions. This boundary between software and organization architecture is where engineering fails and that truly good architects excel at: they understand what they cannot influence and go deliberately after what they can.

This post is woefully one-sided. There's no mention of the negative aspects of system design interviews, or the shortcomings of those conducting them, so I'll provide the missing balance:

### Not enough use of AI

I once had an interviewer tell me I wouldn't be advancing to the next round because I didn't use enough AI. My approach was to consult AI about every 10 minutes during a 45-minute interview. To this day I wonder just how many more prompts would have been "right" and how many would have been too many. Either way, it was ridiculous.

### Zero research about the candidate prior to the interview

Interviewers almost invariably ask questions that are literally answered on my resume—so they clearly haven't read it. I also like to keep a few subtle differences between my resume and my LinkedIn page to see if the interviewer is astute enough to discover something about me. They never do—they can't be bothered to spend 60 seconds perusing my LinkedIn page.

### Not starting with the customer

System design interviews often start with little more than API requirements and a drawing app. There's no mention of any customer. It's a fake scenario, lacking any real depth, usually conducted in a way that stigmatizes candidate mistakes.

### Hypocritical expectations on spend

Many companies spend 10x more on AWS than they should, and simultaneously have no appetite for refactoring or technical debt. Your company is probably no different, so please spare me the lecture about making money.

### Inflexibly following the corporate interview prompt

System design interviewers often have a reference diagram of the completed problem, and a set of answers to common questions. If your diagram doesn't match theirs enough, or you don't ask some arbitrary percentage of their questions, you don't advance. Ironically, if you ask a question not in their list, they don't know how to answer but you don't get any bonus points for stumping them.