Steve Huynh Q&A and Videos

Amazon is well-known for its design doc reviews, which appear to be small-scale system design reviews. However, I'm having trouble understanding them, let alone recommending modifications.

I'm aware of Alex Xu's , but I'm skeptical using it as it's specifically for interview preparation. I want to learn for the workplace. I can definitely look at blog posts and current design documentation, but I'd prefer something more structured. How can a novice learn system design and grow to the advanced/intermediate level? What books or resources would you suggest?

Due to unforeseen circumstances from past 6 - 8 months, I've been the Senior most engineer in my team, (I have a total of just ~2.7 YOE). My team consists of ~12 SDE 1s (New Hires) and 2 SDE2s (The other SDE2 being promoted very recently). My manager does a great job filling the role of Senior Engineer which reduces bit of pressure off of me.

However, due to necessity in the team I've ended up being SME in all the services owned by our team. This leads to everyone reaching out to me to help them with their queries, I try to document some of these and add in the Wikis so that it can be easily accessible for others next time. However, when it comes to certain tickets and issues, I end up having to pick that task up myself (Manager does not ask me to, but at same time i know that for someone else the ramp up time required to fix the issue would be too high).

I recently tried to reduce this (2~ months ago), this led to our overall ticket health getting worse and I had to again start looking into them myself and guiding each on-call cycle with right action items for the tickets etc.

This involves me helping them to do the following :-

• Prioritize correct tickets to look into for the on-call cycle.
• A potential fix for the ticket so that they know where to look into.

Due to which it ends up taking 6+ hours weekly to keep this running. I don't really mind doing this; however, I don't feel like this is a scalable solution and would eventually want to slowly scale down from doing this and have my team being able to be self-sufficient.

What's the best way to go about this without affecting my team's ticket health?

I'm not sure exactly how to phrase this, but to give an analogy, I love card games (ex: Legends of Runeterra, Race for the Galaxy, Hearthstone, etc). There are a fixed set of rules and a fixed set of cards. I can "grind" games and get better by noticing patterns, picking up new strategies or tactics by playing against a diverse set of players. The outcome of an interaction is usually idempotent (i.e. card 1 interaction with card 2).

In real life, things are quite complicated. Asking a certain question in a certain way to person 1 and person 2 may give wildly different responses, and may even depend on your mood, their mood, your tone, time of day, etc. It's super messy and unpredictable.

I also feel a similar way about system design. The nearly infinite possibility of inputs, outputs, TPS, throughput, scenarios make it difficult to reapply the same set of rules to different scenarios. This is just talking about one component, when we bring in N components, the interaction gets very complicated and the "rules" change" case by case. I'm sure it gets better with practice, but I also feel I have a limited opportunity to learn or practice these on the job.

Has anyone found a way to structure these learnings in terms of a repeated "grind", because oftentimes I feel overwhelmed and don't know where to start. This is a complicated question, so answers regarding either a) soft skills or b) system design separately I will treat as valid answers.

I’ve been a senior FEE at Amazon for almost a year now, and I’m still figuring out time management.

Sometimes I get overly involved in others’ tasks, or have too many meetings, or get overwhelmed by all the new campaigns and estimation requests constantly coming through the door while we’re in the middle of meeting deadlines.

How do senior FAANG engineers balance their priorities without overworking or burning out?

P.S. it’d be amazing if Taro can get Steve Huynh (PE at Amazon) to talk about this topic in detail.

Big companies have multiple teams across. There will be a team just for the login, a team for backend logic, etc. There are so many teams and microservices and internal jargon all around.

Problem is during team meeting, seniors have more in depth discussion where I'm unable to provide value as good as them.

How do I get familiar with them fast? Or am I focusing on the wrong idea and should just narrow down what I'm working on and just let time do its thing?

Thanks