HwangR's honest review, U.S. Big Tech Frontend System Design in Practice: For Frontend Developers Who Don't Want to Remain Just Simple Implementers course
Reviews 1
Average rating 2
The actual direction of the lecture was quite different from what I expected after reading the title and introduction. Above all, I was looking for a methodology or thought process for approaching system design, but the actual lecture mostly followed a pattern of listing and addressing requirements already in the instructor's head. I felt that the explanation of why those requirements are derived, or what frameworks and criteria are used to organize and prioritize them, was lacking. Ultimately, while "what to consider" was mentioned repeatedly, it was difficult to learn the methodology for "how to derive those requirements on one's own." The case studies also followed a repetitive flow of listing requirements, which made it quite disappointing for someone trying to learn system design for the first time or looking to acquire a mindset applicable to real-world practice. What I expected from this course was not the correct answers to specific cases, but a thinking framework to approach new problems independently, and that aspect was not fulfilled.
2
Thank you, HwangR, for pointing that out specifically. First, I would like to be honest about what you expected. Regarding "the thinking process to approach new problems on your own," there are parts that a procedural thinking process can handle and parts it cannot. The insight to see core requirements as soon as you receive a new problem does not come from memorizing procedures, but from accumulating cases. This is a consistent conclusion in learning research and the reason why this course chose a case study format rather than a theoretical one. The focus of the lecture will remain on case studies, and I plan to keep adding more. This is because learning a methodology doesn't mean you can immediately design a new system; the insight gained through thinking through numerous cases yourself is proportional to the number of cases. Nevertheless, it is a valid point that there is no specific procedure for requirement elicitation. However, I would like to say that functional requirements do not require a separate methodology. While thinking process methodologies for non-functional requirements do exist and can be applied, I personally learned through system design interviews and discussions with engineers from US Big Tech companies like Meta, Apple, Google, OpenAI, Adobe, and Oracle, and I did not learn by applying such separate requirement elicitation methodologies. Therefore, I judged that providing a methodology in the lecture was unnecessary. I also felt that lecturing on methodologies could actually trap one's thinking, which doesn't align with the philosophy of this course—to bring out the greatness in students—so I did not include it. Thus, as mentioned in the course introduction, the content will be provided in a way that studies system design cases of various US Big Tech services. Regarding your feedback, I will make improvements by briefly touching upon the methodology at a minimum level that aligns with the course philosophy. If you still feel it deserves 2 stars after that, I ask for your understanding in recommending that you take other lectures on methodologies or study separately through other search methods. Thank you for taking the course, and I will try to improve it so that you can be as satisfied as possible. I apologize for the lecture not meeting your expectations, and I wish you a good day.
0