Meta सिस्टम डिज़ाइन इंटरव्यू के सवाल

हो सकता है आपने डिस्ट्रिब्यूटेड सिस्टम्स की बारीकियाँ रटकर तैयारी की हो, लेकिन यह राउंड उसका इनाम नहीं देता। यह सेक्शन असली सवालों के फ़ॉर्मैट को कवर करता है, जो इन्फ्रास्ट्रक्चर से ज़्यादा प्रोडक्ट इंजीनियरिंग के करीब होते हैं। बार-बार आने वाला पैटर्न एक ऐसा कंज़्यूमर-स्केल फ़ीचर है जिसे आप पहले से इस्तेमाल करते हैं, और उसे एक ओपन प्रॉब्लम के रूप में आपके सामने रखा जाता है।

• न्यूज़ फ़ीड डिज़ाइन करें। रैंकिंग, राइट पर फ़ैनआउट बनाम रीड पर फ़ैनआउट, और लाखों फ़ॉलोअर्स वाले अकाउंट्स के लिए क्या होता है।
• मैसेजिंग या चैट सिस्टम डिज़ाइन करें। डिलीवरी गारंटी, ऑर्डर, प्रेज़ेंस, और डिवाइसेज़ के बीच ऑफ़लाइन सिंक।
• नोटिफ़िकेशन सिस्टम डिज़ाइन करें। डिडुप्लिकेशन, बैचिंग, प्रति-यूज़र रेट लिमिट, और पुश, ईमेल, और इन-ऐप के बीच डिलीवरी।
• नियरबाय फ्रेंड्स या लोकेशन फ़ीचर डिज़ाइन करें। जियोस्पेशियल इंडेक्सिंग, अपडेट फ़्रीक्वेंसी, और प्राइवेसी मॉडल।
• सर्च या ट्रेंडिंग कॉम्पोनेंट डिज़ाइन करें। इंडेक्स की ताज़गी बनाम क्वेरी लेटेंसी।

कुछ इंटरव्यू प्रोसेस इसे एक प्रोडक्ट आर्किटेक्चर वैरिएंट में बाँट देते हैं, जो यूज़र-फ़ेसिंग व्यवहार के करीब रहता है। अपने रिक्रूटर से पूछें कि आपको कौन-सा मिल रहा है, क्योंकि तैयारी अलग होती है।

सबसे आम गलती यह है कि दूसरे मिनट में ही बॉक्स बनाने लगें। एक कारगर बँटवारा यह है: पहले रिक्वायरमेंट्स और स्कोप साफ़ करें, फिर API और डेटा मॉडल स्केच करें, फिर हाई-लेवल आर्किटेक्चर बनाएँ, और फिर वहाँ गहराई में जाएँ जहाँ इंटरव्यूअर इशारा करे।

• पहले रिक्वायरमेंट्स। कौन-से यूज़र्स, कौन-से प्लेटफ़ॉर्म, रीड-हैवी या राइट-हैवी, और साफ़ तौर पर आप क्या नहीं बना रहे।
• फिर नंबर्स। मोटा-मोटा डेली एक्टिव यूज़र्स, रिक्वेस्ट रेट्स, और पेलोड साइज़, ताकि बाद के ट्रेड-ऑफ़ के पीछे कोई आधार हो।
• डायग्राम से पहले डेटा मॉडल। कोई एंटिटी कैसी दिखती है और उसे कैसे क्वेरी किया जाता है, यह अक्सर आर्किटेक्चर तय करता है।
• एक डीप डाइव। उम्मीद रखें कि आपको किसी एक कॉम्पोनेंट की ओर मोड़ा जाएगा और पूछा जाएगा कि वह कैसे फ़ेल होता है।

अपनी असम्पशंस ज़ोर से बोलें। जो इंटरव्यूअर किसी असम्पशन से असहमत होगा वह उसे ठीक कर देगा, जो एक तरह की मुफ़्त जानकारी है; बिना बोली गई असम्पशन सिर्फ़ एक कमी जैसी लगती है।

औसत जवाब सिर्फ़ एक सही आर्किटेक्चर बताते हैं। मज़बूत जवाब उस ट्रेड-ऑफ़ का नाम लेते हैं जिसे उन्होंने स्वीकार किया, और उस फ़ेलियर का जिसे वे बर्दाश्त करने को तैयार हैं। यह कहना कि "मैं राइट पर फ़ैनआउट चुन रहा हूँ क्योंकि यहाँ रीड्स हावी हैं, और सेलिब्रिटी अकाउंट्स के लिए धीमी राइट्स स्वीकार कर रहा हूँ, जिसे मैं एक अलग पुल पाथ से हैंडल करूँगा" एक परफ़ेक्ट डायग्राम से कहीं ज़्यादा असर डालता है।

एक बैकएंड इंजीनियर के बारे में सोचें जो सीनियर रोल के लिए इंटरव्यू दे रही है। उससे एक नोटिफ़िकेशन सिस्टम डिज़ाइन करने को कहा जाता है, और वह पहले छह मिनट सिर्फ़ रिक्वायरमेंट्स पर बिताती है: क्या एक यूज़र को एक ही इवेंट के लिए दो नोटिफ़िकेशन मिल सकते हैं, क्या ऑर्डर मायने रखता है, रिटेंशन विंडो कितनी है। इंटरव्यूअर बाद में कहता है कि डिडुप्लिकेशन वाली चर्चा ही इस राउंड का निर्णायक हिस्सा थी, और वह कभी एक पेज के डायग्राम से आगे नहीं बढ़ पाई।

अकेले डेस्क पर बैठकर इस तरह की नैरेशन का अभ्यास करना सबसे मुश्किल हिस्सा है। आप /mock-interview पेज पर एक AI इंटरव्यूअर के सामने डिज़ाइन सवालों का अभ्यास कर सकते हैं और सोचते हुए बोलने की आदत डाल सकते हैं।

बोलकर होने वाले वीडियो राउंड में, SubcueAI इंटरव्यूअर के सवाल को ट्रांसक्राइब करता है और आपकी तरफ़ एक सुझाई गई स्ट्रक्चर दिखाता है — macOS और Windows पर डेस्कटॉप ओवरले में, या Chromium ब्राउज़र एक्सटेंशन के साइड पैनल में। कोई मीटिंग बॉट कॉल में शामिल नहीं होता, और मीटिंग पेज में कुछ भी इंजेक्ट नहीं किया जाता। डिज़ाइन राउंड के लिए असली फ़ायदा एक चेकलिस्ट है जिसे आप दबाव में भूलते रहते हैं, जैसे कैपेसिटी एस्टीमेट या फ़ेलियर मोड, न कि कोई जवाब जिसे आप ज़ोर से पढ़ें।

सीमाएँ साफ़ हैं। डिज़ाइन राउंड आमतौर पर एक शेयर की गई व्हाइटबोर्ड टूल पर आपकी स्क्रीन शेयर के साथ चलते हैं, और आपकी स्क्रीन पर जो कुछ भी है वह पैनल को दिखता है। जनरेट किए गए जवाब को पढ़ना भी तुरंत बिखर जाता है, क्योंकि इंटरव्यूअर का अगला सवाल होता है "दूसरा अप्रोच क्यों नहीं?"। दूसरे एम्प्लॉयर्स के लिए जुड़े राउंड्स कंपनी इंटरव्यू टॉपिक में मिलते हैं।