System Design Q&A and Videos

I’ve been asked to write up some docs on coding standards and code review on behalf of a dev team that is stuck in its ways.

How could I facilitate that conversation?

How would I structure these docs as I seem to need to write a mix of documentation that includes high level goals with quite specific process docs

The CTO's perception is that code quality is low, but can’t or won’t articulate why he thinks that.

He also thinks the code review process is sloppy but again won’t articulate what has happened that has led him to think that.

he’s also said don’t go all war and peace on this

it’s all so vague.

I recently designed APIs for a new project. While I am very confident in the design I have developed. But I get some jitters when I plan to do readouts to leadership.
Is it because of the questions I would get? is it because I would like dumb?

is it because folks would look down upon me? What is it I wonder.

Any inputs folks?

Hi, Taro community:

I struggle with system design interviews (senior level).

I've spent a lot of time studying. I've read in-depth ByteByteGo System Design Vol1 and Vol2. I went through most of Gaurav Sen's videos, the "Top ways people fail system design" course, read all the guides in , and Hello interview. If you ask me how consistent hashing, partitioning, LSM tree, and quorum work, I can show you I know enough for product-based system design interviews.

I've also done some practice. I've done all the guided practice in Hello Interview, did 3 mocks, and 2 real system design interviews recently.

What I've found is I hesitate a lot at each step of the interview. For example

• For requirement gathering, I'm not sure if I have enough requirements, or asked enough questions, etc
• For non-functional requirements, I hesitate about how much latency should be, and if I'm missing something, etc
• For high level, I hesitate if I need to use 1 service or a separate service, or 1 db or separate db, which service is responsible for what, etc.
• For deep dive, I hesitate if I still need a message queue for a write-heavy system if I already have a distributed no-SQL database. Or if I need a Redis if I already have a relational DB that handles high reads. I like to keep things simple but I'm afraid the interviewer gonna think "he didn't use Redis!" or "he didn't use a message queue!"

Then it affects

• The interviewer would then perceive I'm not comfortable with designing the system
• It would look like I'm not familiar with basic system design concepts
• Time management. I usually spend too much time on high-level design and run out of time for deep dive
• I don't look confident.

I know in theory that in system design "there is no right answer", but I'm worried about providing some "wrong" answer unknowingly.

I'm not sure what to do next. Technically there's always more to study. For example, I could read DDIA (I've only read summary study notes before). But I don't know if the answer is to study more. It feels like studying more even reinforces the hesitation that maybe I'm not applying things right.

Any advice would be helpful on how to overcome this would be very appreciated!

Is there any other difference other than the number of rounds someone would need to give for system design at interviews of these levels.

are there any resources on how to improve my Request for Comment (RFC) and tech doc skills?

At my previous company, I proposed adding in some new JWT libraries. However, there was a lot of pushback from the principal engineers about security vulnerabilities in these libraries. We eventually figured out a path forward, but it took a long time - There was a huge back and forth on how to do things right.

How can I optimize future situations like these, so I can set myself up for success at my new company?