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.
Looks like … consumer suggestibility exploitation tools for margin-strapped cash-cow retail. The reason I use an adblocker that has an “additional annoyances” redaction tool. A company no-one with a shred of utilitarianism in their soul should even imagine supporting through their effort. Rent-seeking economic benthos scraping up the last shreds of residual value from a transaction and assigning it to private equity. Most assuredly, not worth the sweat from one’s brow.
Are you sure you wanted to ask that question in public?
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.
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.
> “So, what do you know about Rokt?”
Looks like … consumer suggestibility exploitation tools for margin-strapped cash-cow retail. The reason I use an adblocker that has an “additional annoyances” redaction tool. A company no-one with a shred of utilitarianism in their soul should even imagine supporting through their effort. Rent-seeking economic benthos scraping up the last shreds of residual value from a transaction and assigning it to private equity. Most assuredly, not worth the sweat from one’s brow.
Are you sure you wanted to ask that question in public?
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.