How do you make systems design decision given a task at your company as a Senior Engineer?

Does it vary for startups and FAANG+ companies?

Yes, 100%. At a high-level, Big Tech engineers need to be much more thorough and thoughtful when doing system design for the following reasons:

• There's many more ways to fail
• The stakes of failing are much higher (e.g. Meta's Cambridge Analytical scandal)

Startups should still do some proactive design thinking (we do this at Taro), but it's going to be much lighter than what a FAANG company does. Startups are at a stage where they need to move blisteringly fast and pump out features quickly, so it's a waste of time to go super deep on system design, especially to the degree of Big Tech.

For context and to put things in perspective:

• The system design phase of a project at Meta could easily take me 2-3 weeks.
• At Taro, we'll spend 2-3 days at most doing the technical design for a very large project.

How do you answer such a question if asked during an interview?

I recommend these:

• "Quality to demonstrate for staff MLE during interview?"
• [Masterclass] How To Ace Your Big Tech Interview - System Design

How much autonomy each senior engineer (L5 or L6) has in such decisions?

From my experience at Big Tech, an L6 (Staff Engineer) will have a lot of autonomy while an L5 would have a good amount (but generally won't be the largest voice in the room).

However, there's a ton of nuance to this:

• Some teams are more bottom-heavy, which means they'll have few or even 0 L6 engineers. This creates a power vacuum where the L5s have to step up and lead all of the system design. This was actually the case for me at Instagram - My initial team only had 1 L5 engineer (everyone else was L4), so she did everything! That engineer actually did a talk on Taro recently, so I recommend checking that out if you want to learn about how she grew hyper-fast: Growing To Meta Tech Lead And Then Entrepreneurship - By Jocelin Ho
• Projects are usually decomposed, so it's not like any 1 person is the boss. An L6 workstream will often be split into 2-3 L5 projects where each leading L5 can dictate the technical design of their portion.
• L3 and L4 engineers can do system design as well, especially if they're ambitious and have a nice, scoped out project on the smaller side they can really sink their teeth into.

Could you please share an example case study here? What does the entire process look like?

I highly recommend watching this series I made all the way to the end: System Design Masterclass: Taro Playlists

"Autonomy" is an interesting choice of word. I wonder what you mean exactly by this? Maybe, the ability to decide how design ought to be? Or how much input you need from higher level people to approve your design? Alex already gave an excellent answer overall but I want to dive into this a bit more...

I think no matter your level, designs are collaborative experiences where your most of your engineering colleagues needs to be convinced that you are proposing a good solution. Higher levels by no means enables people to dictate unilaterally what stack or what technology to use. See "Material but not magic" section of the Staff Engineer Book.

I think the difference in levels at FAANG for design has to do the level of ambiguity and scope of the project rather than their ability to more unilaterally decide which direction to go. For example, at Google:

• L4: Generally gets projects with known problem and relatively obvious solution, L4s mainly just need to talk to the relevant people to find a reasonable solution that everyone agrees on and document it well in a design doc. The hardest things here are usually clearly describing the solution chosen and the tradeoffs. It's rare the decision is controversial.
• L5: Generally gets projects with known problems but unknown solutions. So the hardest part is usually finding the right solution (which can sometimes be entirely a new thing to the organization) and also convincing everyone that this is the right path to go. Decisions on the right solution might be controversial and require lots of consensus building.
• L6: Projects with unknown problems. L6s typically handle projects where finding and defining the problem is typically the critical factor in its success (e.g. the organization knows they needs to cut cost and infra cost a lot, but they don't actually know whether that's a problem or the problem is elsewhere, so they task an L6 to investigate). So sometimes L6s don't even write design docs, they simply write problem statements or vision docs or something that becomes the core motivating force behind giant projects. Once they define a problem, they may delegate the finding of exact solutions to the defined problems to L5s. I see L6s reviewing more designs docs than they write them.

Having said that, higher level ICs do tend to have more influence. But this is more of a result of their continued good judgement rather than their title or level - e.g. other engineers simply agree that the solutions they propose have been good and give the benefit of doubt that their new solution is going to be good. It's entirely possible for high level ICs to continually display poor judgement and propose bad solutions, to the point where they have no influence despite being at higher levels. Any proposal, no matter who proposes it, will be scrutinized at the end of the day, but having more, shall we call it, "street cred" can definitely help.

@Kuan: I didn't mean "autonomy" it in a negative way. I wanted to understand how much and what I need to contribute or bring to the table depending on what level I am at.

Thank you for sharing your responses, they are very insightful and helpful.