System Design Monster: Learning to design systems like a monster!

I want to announce my training service on system design interview.

How it began?

After coaching several friends and helping them to harvest L6 (Staff engineer) offers, I realized there is a significant gap in the market. Although there are tons of system design training course if you Google and there are books on this topic, none is even close for the technical depth required by senior levels — Staff level or above.

After carefully reading the existing training courses — to make sure others didn’t come up with good materials overnight — I decide to scale the impact of my past coaching by offering it to the public.

You can reserve the service or find more details on the dedicated website.

Why learn from me

Simple, because other materials don’t work.

Existing materials on System Design Interviews (SDI) has two categories, neither is sufficient for Staff+ level interviews. Not even close.

The first category is books, papers, and blogs from industrial and academical experts. For example, DDIA and All Things Distributed. While they have some academic merits, the contents are not intended for the system design skills we apply in daily jobs (hence in SDI). For example, the famous CAP theorem everyone loves teaching is useless. Because in all distributed system, network partition — or failures in general — is a given fact rather than a factor you can trade off with. In reality, a much better model is the trade off between the speed of eventual consistency convergence, the speed of response, throughput, and availability. More on this here and here.

The second category is online courses claimed to teach you SDI. For example, Grokking the System Design Interview, ByteByteGo and its book, Interviewing.io, and many others. Those contents are beautifully presented and logically organized. I believe those materials are sufficient for entry level jobs like L3 and L4. Sometimes you can pass L5 interviews too with enough luck. But if a job candidate presented same level solutions as in those courses, he will fail almost 100% of the times for L6+ interviews.

For example, one Ticket Master solution suggested using a distributed lock like Zookeeper to solve the race condition when multiple users try to book the same seat. Firstly, it’s wrong because Zookeeper is too slow and can’t scale big enough. Secondly, the interviewer will ask how it’s implemented. No one can explain such complex algorithms (Paxos or Raft) in a short time. It’s like suggesting to use A* search or Suffix Tree in a coding interview. Obviously, the author didn’t understand what are acceptable building blocks in SDI.

Another very common mistake is using a distributed KV store as if it can horizontally scale and be faster than relational DB. In fact, those KV engines scale the same as relational DB, but are much slower to update (because of replicas) and much harder to maintain. The reason of choosing them is availability rather than speed.

Bridging the gap via apprenticeship

The reason one struggles at System Design Interviews is a lack of work experience building those systems. Why someone with 8 YOE hasn’t accumulated enough hours to be an expert? It’s not a surprise because most of our working hours, as a software engineer, are spent on meetings, writing docs, coding, learning the domain knowledge and business logic. All are necessary for career growth, but as a result, the time we spent on architecting distributed systems is a tiny fraction.

From my coaching experience, this gap can be bridged efficiently through a focused apprenticeship. For example, engineers with 5–10 years of experience, after around three months of coaching, gained the expertise level required by the Staff level. I think it’s because most qualified staff engineers have a similar number of effective hours on system design practice, regardless of their actual YOE.

During the coaching, I found some engineers have other gaps in behavior skills like communication. They will also be addressed. Like system design skills, communication, collaboration, and leadership are all critical for Staff+ level positions. (That why many says L3, L4, and L5 are the same job, L6+ is another.) Some behavioral signals are sought after in interviews. Interestingly, none of my coachees need improvement on coding.

How did I justify the price?

I calculated the average and median of salary jump from L5 to L6 and charge a percentage of it. Since the promotion path for already qualified engineers takes 1 to 3 years and the interview path for anyone with a gap in technical capacity takes similar time, the price is a wonderful deal given it delivers the same in 3 to 6 months..

How can I prove if it works? Like most judgement in life, we can’t be 100% sure. However, by the relatively cheap $120 consultation — the rough hourly rate of a handyman or a plumber if you live in the Bay Area — or the still cheap mock interview, you will be fairly confident about the value, more confident than your average decision with similar expected returns, costs, and risks. RSVP here.

Who shouldn’t use this service?

For engineers targeting L3, L4, or junior L5, I recommend the much cheaper and mature existing materials you found on Google Search.

There are another group of people who can learn enough from my free contents, like those sample designs. They can learn from those and test their skill in interviews before deciding if the service is necessary.

Other offerings

I would prefer to scale things on steady small steps. I offer this training service because of previous successful coaching for my acquaintances. With further solid results, I will further scale by recording video courses and making some free contents on Youtube.

In the meantime, I will keep on posting interesting designs on this blog. Stay tuned!