In my five years of teaching systems design, I have come to the following conclusion:
Junior engineers focus on solutions.
Senior engineers focus on problems.
Junior engineers tend to be eager to show how much they know. They quickly move to solution building to discuss popular design patterns (load balancing, partitioning, etc).
The seniors cook their thoughts over the given requirements, and start with a skeletal solution. They then tackle design tradeoffs and extensibility.
For example, how would you tag emails in an emailing service?
Possible Tags: Primary, Social, Promotions, Updates, Forums.
Option-1: "I would run a batch job to tag emails every hour."
But emails are tagged in seconds.
Option-2: "I would run a stream pipeline to tag emails in seconds."
But the email stream would be very long and hence flows difficult to orchestrate.
Option-3: "I would have a request-response contract with an email tagging service settings tags for every email request."
Yes, that sounds about right.
Senior engineers tend to reach Option-3 sooner, with fewer hints. They prove and disprove their architectures independently, protecting their teams from their half-baked ideas.
So if you are looking to command design reviews and technical discussions, I would suggest Josh Waitzkin's advice:
You might find a good solution. Then you may find a better solution.
But take your time.
Find the best solution.
1. Email Service System Design Architecture Diagram