क्या मैं सिस्टम डिज़ाइन इंटरव्यू का अभ्यास AI से कर सकता हूँ?

यदि AI तुरंत पूरा आर्किटेक्चर दे देता है, तो आप निर्णय लेने के अभ्यास का अवसर खो देते हैं। नीचे दी गई व्यवस्था उत्तर की ज़िम्मेदारी आपके पास रखती है और इसमें ठोस इंटरव्यूअर प्रॉम्प्ट तथा संकेतों को देर से देने के नियम शामिल हैं।

इस प्रॉम्प्ट का उपयोग ऐसे AI टूल में करें जो संवादात्मक निर्देश स्वीकार करता हो:

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

भूमिका और समस्या को अपने लक्ष्य से बदलें। यदि AI आपके लिए डिज़ाइन पूरा करने लगे, तो उससे दोबारा प्रश्न पूछने को कहें। उत्तर ज़ोर से बोलें और बातचीत के साथ-साथ चित्र बनाएँ, भले ही आपको टूल में उसका सार टाइप करना पड़े।

SubcueAI की अभ्यास पेशकश के लिए मॉक इंटरव्यू पेज देखें।

शुरू करने से पहले अभ्यास की समय-सीमा तय करें। सुझाई गई यह 40-मिनट की संरचना अभ्यास योजना है, किसी नियोक्ता के इंटरव्यू प्रारूप के बारे में दावा नहीं:

• आवश्यकताएँ, 5 मिनट: उपयोगकर्ताओं, आवश्यक कार्रवाइयों, बाहर रखी गई सुविधाओं और स्वीकार्य विलंबों की पहचान करें। वेबहुक के लिए स्पष्ट करें कि क्रम मायने रखता है या नहीं और सफल डिलीवरी का अर्थ क्या है।
• अनुमान, 5 मिनट: इवेंट की मात्रा, पेलोड का आकार, प्रति इवेंट गंतव्यों की संख्या और पीक लोड की धारणा बताएँ। इकाइयाँ स्पष्ट रखें।
• प्रारंभिक डिज़ाइन, 15 मिनट: इवेंट इनजेशन, टिकाऊ स्टोरेज, डिलीवरी क्यू, वर्कर और ग्राहक एंडपॉइंट का खाका बनाएँ। सिस्टम में एक इवेंट का पूरा मार्ग दिखाएँ और प्रत्येक अभिस्वीकृति को समझाएँ।
• गहन चर्चा, 10 मिनट: डुप्लिकेट डिलीवरी, अत्यधिक भार वाले गंतव्य या वर्कर की विफलता जैसा कोई जोखिम चुनें। समाधान और उसकी लागत समझाएँ।
• पुनरावलोकन, 5 मिनट: डिज़ाइन, उसकी सबसे कमज़ोर धारणा और आगे जाँचने योग्य बात का सार बताएँ।

आवश्यकताओं से कॉम्पोनेंट का औचित्य सिद्ध होना चाहिए। उदाहरण के लिए, इवेंट को सुरक्षित रखने का तरीका चुनने से पहले समझाएँ कि प्रोसेस क्रैश होने पर क्या बचना चाहिए। यदि मॉक से ज्ञान की कोई कमी सामने आए, तो प्रयास पूरा करें, उस कमी का अध्ययन करें और व्याख्या का फिर अभ्यास करें।

कल्पना करें कि एक बैकएंड इंजीनियर वेबहुक डिलीवरी मॉक के साथ सीनियर प्लेटफ़ॉर्म भूमिका की तैयारी कर रहा है। काल्पनिक कार्यभार प्रतिदिन 10 मिलियन इवेंट, प्रति इवेंट एक गंतव्य और 1 KB पेलोड है। AI पूछता है कि किसी ग्राहक का एंडपॉइंट एक घंटे के लिए अनुपलब्ध हो जाए तो क्या होगा।

ऐसे अंकगणित से शुरू करें जिसे आप समझा सकें: 10,000,000 को 86,400 से विभाजित करने पर औसतन लगभग 116 इवेंट प्रति सेकंड मिलते हैं। औसत से दस गुना की अलग से चुनी गई पीक धारणा प्रति सेकंड लगभग 1,160 प्रारंभिक डिलीवरी प्रयास देती है। पुनः प्रयास इन प्रारंभिक प्रयासों के अतिरिक्त ट्रैफ़िक जोड़ते हैं।

दशमलव इकाइयों में, मेटाडेटा, इंडेक्स, प्रतिकृति और अन्य अतिरिक्त भार से पहले इवेंट पेलोड का कुल आकार लगभग 10 GB प्रतिदिन है। ये अभ्यास की धारणाएँ हैं, वास्तविक प्रोडक्शन माप नहीं। अनुपलब्ध ग्राहक के बैकलॉग का अनुमान लगाने के लिए पहले तय करें कि इवेंट का कितना अंश उस ग्राहक को लक्षित करता है।

फिर AI से इन मामलों को अलग-अलग जाँचने को कहें:

• अभिस्वीकृति खोना: रिसीवर इवेंट प्रोसेस करता है, लेकिन प्रेषक को उसका उत्तर कभी नहीं मिलता। समझाएँ कि पुनः प्रयास किसी साइड इफ़ेक्ट को कैसे दोहरा सकता है और डीडुप्लिकेशन कहाँ होना चाहिए।
• धीमा गंतव्य: एक ग्राहक वर्कर क्षमता का उपयोग करता है। समझाएँ कि समवर्तीता सीमाएँ, पुनः प्रयास बैकऑफ़ और पृथक्करण दूसरे ग्राहकों की रक्षा कैसे कर सकते हैं।
• वर्कर क्रैश: डिलीवरी के दौरान कोई वर्कर रुक जाता है। पहचानें कि क्या टिकाऊ बना रहता है, कार्य दोबारा प्रयास के योग्य कब होता है और डुप्लिकेट कैसे सँभाले जाते हैं।

अभ्यास की एक और समस्या के लिए इंटरव्यू प्रश्न बैंक गाइड देखें।

किसी स्कोर को स्वीकार करने से पहले प्रमाण माँगें। उपयोगी समीक्षा आपकी कही या छोड़ी हुई बात पहचानती है, उसका परिणाम समझाती है और दोबारा देखने के लिए विशिष्ट मुद्दा देती है।

• आवश्यकताएँ: क्या आपके डिज़ाइन ने सहमत दायरे और डिलीवरी अपेक्षाओं को संबोधित किया?
• संख्याएँ: क्या इकाइयाँ सुसंगत थीं और क्या आपने औसत लोड, पीक लोड और पुनः प्रयासों में अंतर किया?
• आर्किटेक्चर: क्या आप डायग्राम में सफल अनुरोध और विफलता, दोनों का पूरा मार्ग दिखा सके?
• समझौते: क्या आपने कोई व्यावहारिक विकल्प और उसे अस्वीकार करने का परिणाम समझाया?
• संवाद: क्या आपने किसी कॉम्पोनेंट के कार्यान्वयन पर चर्चा करने से पहले उसकी आवश्यकता का कारण समझाया?

AI सेवा की क्षमताएँ गढ़ सकता है, अनुमानों की गलत गणना कर सकता है या ऐसा कॉम्पोनेंट सुझा सकता है जो बताई गई समस्या हल नहीं करता। गणित की गणना स्वयं दोबारा करें और विवादित तकनीकी दावों को आधिकारिक दस्तावेज़ों से जाँचें। समीक्षक से कहें कि वह उल्लंघित आवश्यकता और मान्य डिज़ाइनों के बीच व्यक्तिगत पसंद को अलग-अलग बताए।

अभ्यास चक्र में चित्र बनाना जारी रखें। केवल टेक्स्ट वाला फ़ीडबैक ऐसे डायग्राम की जाँच नहीं कर सकता जो उसे मिला ही नहीं है, और इमेज-सक्षम फ़ीडबैक भी विसंगतियाँ चूक सकता है। जाँचें कि आपके तीर, डेटा स्टोर, अभिस्वीकृतियाँ और मौखिक व्याख्या परस्पर सुसंगत हैं।

सबसे कमज़ोर हिस्से को बिना संकेतों के दोहराएँ, फिर बदली हुई बाधा के साथ संबंधित समस्या का प्रयास करें। देखें कि क्या आप अपने निर्णय स्वतंत्र रूप से समझा सकते हैं। कोई सहकर्मी या अनुभवी इंटरव्यूअर अस्पष्ट तर्क की एक और जाँच कर सकता है; केवल AI स्कोर तैयारी प्रमाणित नहीं कर सकता।