คำถามสัมภาษณ์ System Design ของ Meta
โดย Aaron Cao · อัปเดตเมื่อ
รอบ Design ของ Meta มักจะขอให้คุณออกแบบระบบผลิตภัณฑ์สำหรับผู้บริโภค เช่น ฟีดข่าว บริการส่งข้อความ ไปป์ไลน์การแจ้งเตือน หรือฟีเจอร์ «เพื่อนที่อยู่ใกล้เคียง» ผู้สัมภาษณ์ให้น้ำหนักกับความต้องการของผลิตภัณฑ์และโมเดลข้อมูลพอ ๆ กับความสามารถในการสเกล และรอบนี้เป็นมาตรฐานตั้งแต่ระดับซีเนียร์ขึ้นไป ไม่ใช่สำหรับตำแหน่งระดับเริ่มต้น
Meta ถามคำถาม Design แบบไหนบ้าง
คุณอาจเตรียมตัวมาด้วยการท่องจำรายละเอียดเกี่ยวกับ distributed systems แต่รอบนี้ไม่ได้ให้รางวัลกับสิ่งนั้น ส่วนนี้จะพูดถึงรูปแบบคำถามจริง ๆ ที่ใกล้เคียงกับ product engineering มากกว่า infrastructure รูปแบบที่เกิดซ้ำ ๆ คือฟีเจอร์ระดับผู้บริโภคที่คุณใช้อยู่แล้ว ถูกยื่นให้คุณในฐานะโจทย์เปิด
- ออกแบบฟีดข่าว การจัดอันดับ fanout ตอนเขียนเทียบกับ fanout ตอนอ่าน และสิ่งที่เกิดขึ้นกับบัญชีที่มีผู้ติดตามหลักล้าน
- ออกแบบระบบส่งข้อความหรือแชท การรับประกันการส่งถึง ลำดับ สถานะออนไลน์ และการซิงก์แบบออฟไลน์ระหว่างอุปกรณ์
- ออกแบบระบบแจ้งเตือน การลดข้อมูลซ้ำ การประมวลผลเป็นชุด การจำกัดอัตราต่อผู้ใช้ และการส่งผ่าน push อีเมล และในแอป
- ออกแบบฟีเจอร์เพื่อนใกล้เคียงหรือฟีเจอร์ตำแหน่งที่ตั้ง การทำดัชนีเชิงภูมิศาสตร์ ความถี่ในการอัปเดต และโมเดลความเป็นส่วนตัว
- ออกแบบคอมโพเนนต์ค้นหาหรือเทรนด์ ความสดใหม่ของดัชนีเทียบกับ latency ของ query
บางกระบวนการสัมภาษณ์จะแยกส่วนนี้ออกเป็น variant ของ product architecture ที่ใกล้เคียงกับพฤติกรรมที่ผู้ใช้มองเห็นมากกว่า ลองถามผู้สรรหาว่าคุณจะได้แบบไหน เพราะการเตรียมตัวจะต่างกัน
ควรใช้เวลา 45 นาทีนั้นอย่างไร
รูปแบบความล้มเหลวทั่วไปคือการเริ่มวาดกล่องตั้งแต่นาทีที่สอง การแบ่งเวลาที่ใช้ได้ผลคือ ทำความชัดเจนเรื่อง requirements และ scope ก่อน แล้วร่าง API และ data model จากนั้นวาด architecture ระดับสูง แล้วค่อยเจาะลึกในจุดที่ผู้สัมภาษณ์ชี้ไป
- Requirements ก่อน ผู้ใช้กลุ่มไหน แพลตฟอร์มไหน เน้นอ่านหรือเน้นเขียน และสิ่งที่คุณจะไม่สร้างอย่างชัดเจน
- ตัวเลขต่อมา ประมาณการคร่าว ๆ ของผู้ใช้ที่ active รายวัน อัตรา request และขนาด payload เพื่อให้การแลกเปลี่ยนในภายหลังมีฐานอ้างอิง
- Data model ก่อนไดอะแกรม หน้าตาของ entity หนึ่งตัวและวิธีที่มันถูก query มักเป็นตัวตัดสิน architecture
- เจาะลึกหนึ่งจุด เตรียมใจไว้ว่าคุณจะถูกโยงให้เจาะลึกในคอมโพเนนต์เดียว แล้วถูกถามว่ามันล้มเหลวอย่างไร
พูดสมมติฐานของคุณออกมาดัง ๆ ถ้าผู้สัมภาษณ์ไม่เห็นด้วยกับสมมติฐานใด เขาจะแก้ไขให้ ซึ่งเป็นข้อมูลฟรี ส่วนสมมติฐานที่ไม่ได้พูดออกมาจะดูเหมือนเป็นช่องโหว่เฉย ๆ
อะไรที่แยกคำตอบที่ดีออกจากคำตอบทั่วไป
คำตอบทั่วไปอธิบาย architecture ที่ถูกต้อง คำตอบที่ดีจะระบุชื่อ trade-off ที่ยอมรับ และความล้มเหลวที่ยอมทน การพูดว่า «ผมเลือก fanout ตอนเขียนเพราะที่นี่การอ่านครองส่วนใหญ่ และผมยอมรับการเขียนที่ช้าลงสำหรับบัญชีคนดัง ซึ่งผมจะจัดการด้วย pull path แยกต่างหาก» มีน้ำหนักมากกว่าไดอะแกรมที่สมบูรณ์แบบ
ลองนึกถึงวิศวกร backend คนหนึ่งที่กำลังสัมภาษณ์ตำแหน่งซีเนียร์ เธอถูกขอให้ออกแบบระบบแจ้งเตือน และใช้เวลาหกนาทีแรกไปกับ requirements เท่านั้น ผู้ใช้คนหนึ่งจะได้รับการแจ้งเตือนสองครั้งสำหรับเหตุการณ์เดียวได้หรือไม่ ลำดับสำคัญหรือไม่ retention window นานแค่ไหน ผู้สัมภาษณ์บอกในภายหลังว่าการพูดคุยเรื่อง deduplication คือส่วนที่ตัดสินผลของรอบนี้ และเธอไม่เคยไปได้ไกลกว่าไดอะแกรมหน้าเดียว
การซ้อมการเล่าเรื่องแบบนี้คนเดียวหน้าโต๊ะคือส่วนที่ยากที่สุด คุณสามารถลองทำโจทย์ design กับผู้สัมภาษณ์ AI ได้ที่หน้า /mock-interview และฝึกให้ชินกับการพูดไปพร้อม ๆ กับการคิด
ผู้ช่วยแบบสดช่วยตรงไหนได้บ้าง และไม่ช่วยตรงไหน
ในรอบสัมภาษณ์วิดีโอแบบพูด SubcueAI จะถอดเสียงคำถามของผู้สัมภาษณ์และแสดงโครงสร้างที่แนะนำในฝั่งของคุณ ผ่าน overlay บนเดสก์ท็อปบน macOS และ Windows หรือผ่านแผงด้านข้างของส่วนขยายเบราว์เซอร์ Chromium ไม่มีบอทเข้าร่วมประชุม และไม่มีอะไรถูกแทรกเข้าไปในหน้าประชุม สำหรับรอบ design คุณค่าที่แท้จริงคือเช็กลิสต์ของสิ่งที่คุณมักลืมเมื่ออยู่ภายใต้แรงกดดัน เช่น capacity estimate หรือ failure mode ไม่ใช่คำตอบที่คุณอ่านออกเสียง
ข้อจำกัดค่อนข้างชัดเจน รอบ design มักจะใช้เครื่องมือ whiteboard ที่แชร์ร่วมกัน พร้อมกับหน้าจอของคุณที่ถูกแชร์ และทุกอย่างบนหน้าจอของคุณจะมองเห็นได้โดยกรรมการ การอ่านคำตอบที่สร้างขึ้นมาก็พังทลายทันทีเช่นกัน เพราะคำถามถัดไปของผู้สัมภาษณ์คือ «ทำไมไม่ใช้แนวทางอื่น» รอบที่เกี่ยวข้องสำหรับนายจ้างรายอื่นอยู่ใน หัวข้อการสัมภาษณ์แต่ละบริษัท