Anthropic के ‘फ़ॉरवर्ड डिप्लॉयड इंजीनियर’ (FDE) उस जगह काम करते हैं जहाँ प्रोडक्ट, कस्टमर की असलियत और मॉडल का व्यवहार आपस में मिलते हैं। आपकी तैयारी तब बेहतर होती है जब आप इंटरव्यू को मॉडल के बारे में सामान्य जानकारी (ट्रिविया) का टेस्ट नहीं, बल्कि मुश्किल हालात में डिप्लॉयमेंट से जुड़े फ़ैसले लेने की आपकी क्षमता का मूल्यांकन मानते हैं।
इस स्थिति पर विचार करें। एक बड़ी सपोर्ट कंपनी अपने एजेंट की मदद के लिए Claude को लागू करना चाहती है ताकि वे कस्टमर के टिकटों का जवाब दे सकें, लेकिन उनके पास डेटा से जुड़े कड़े नियम, पहले से मौजूद आइडेंटिटी सिस्टम और इंटरनल टूल्स का एक बड़ा भंडार है जिसमें असली जवाब मौजूद हैं। FDE के तौर पर आपका काम इसे एक सुरक्षित और काम करने वाले डिप्लॉयमेंट प्लान में बदलना है, जिसमें फ़ायदों और चुनौतियों (trade-offs) का साफ़ पता हो।
Anthropic के प्रोडक्ट का दायरा उन चीज़ों का समूह है जिनसे कस्टमर असल में तब जुड़ते हैं जब वे Claude का इस्तेमाल करके कुछ बनाते हैं। असल में, इसका मतलब है - एक मॉडल के तौर पर Claude, ऐप और मॉडल के बीच बातचीत का ज़रिया यानी Claude API, और वे एंटरप्राइज़ कंट्रोल जो सिक्योरिटी टीम को इसे मंज़ूरी देने के लिए तैयार करते हैं।
सपोर्ट-टिकट वाले उदाहरण में, कस्टमर सिर्फ़ “एक चैटबॉट” नहीं मांग रहा है। वे एक ऐसे AI सिस्टम की मांग कर रहे हैं जो टिकट के संदर्भ (context) को पढ़ सके, सही पॉलिसी की जानकारी निकाल सके, ज़रूरत पड़ने पर इंटरनल टूल्स का इस्तेमाल कर सके, और संवेदनशील डेटा को ऐसी जगहों पर लीक होने से रोक सके जहाँ उसे नहीं जाना चाहिए।
यहाँ FDE का ज़्यादातर काम बिज़नेस के लक्ष्यों को ठोस ‘बिल्ड टास्क’ (बनाने के कामों) में बदलना होता है। आखिर में आप यह तय करते हैं कि Claude कौन सा डेटा देख सकता है, क्या काम कर सकता है, और बड़े पैमाने पर लॉन्च करने से पहले आप यह कैसे साबित करते हैं कि उसका व्यवहार सही है।
देखें कि डिप्लॉयमेंट से जुड़ी ये चिंताएँ असल ‘बिल्ड टास्क’ से कैसे जुड़ती हैं।
एंटरप्राइज़ की असलियत मायने रखती है इंटरव्यू के जवाब में, जूनियर लगने का सबसे आसान तरीका है आइडेंटिटी, डेटा एक्सेस और रोलआउट कंट्रोल को छोड़कर सीधे प्रॉम्प्टिंग पर आ जाना।
Anthropic का इंटरव्यू प्रोसेस समय के साथ बदलता रहता है, लेकिन कैंडिडेट अक्सर ऐसे राउंड के बारे में बताते हैं जो मुख्य FDE काम से जुड़े होते हैं। मकसद किसी “सही” क्रम को याद करना नहीं है। मकसद यह समझना है कि हर राउंड यह कैसे पता लगाने की कोशिश कर रहा है कि आप सपोर्ट-टिकट रोलआउट जैसे काम में कैसा प्रदर्शन करेंगे।
रिक्रूटर स्क्रीनिंग में आमतौर पर यह देखा जाता है कि क्या आप कस्टमर से जुड़े अपने पिछले टेक्निकल काम को साफ-साफ समझा सकते हैं और क्या आपकी प्रेरणा इस रोल के लिए सही है। केस-स्टाइल राउंड में अक्सर ‘डिस्कवरी’ की जांच की जाती है; यह एक अस्पष्ट रिक्वेस्ट को साफ समस्या के बयान, सीमाओं और अगले कदमों में बदलने का हुनर है, जिसमें कस्टमर को आपके लिए इंजीनियरिंग का काम नहीं करना पड़ता।
सिस्टम डिज़ाइन राउंड अक्सर Retrieval-augmented generation (RAG) पर केंद्रित होता है। इसमें मॉडल के जवाब देने से पहले कस्टमर डेटा पर सर्च स्टेप का इस्तेमाल करके जवाब को ठोस आधार दिया जाता है। हमारे उदाहरण में, इसका मतलब हो सकता है कि मौजूदा रिफंड पॉलिसी और क्षेत्र-विशिष्ट अपवादों को निकाला जाए, ताकि एजेंट को ऐसा जवाब मिले जो आज के नियमों से मेल खाता हो, न कि सिर्फ़ सुनने में सही लगने वाला अंदाज़ा।
इम्प्लीमेंटेशन या डीबगिंग राउंड में आमतौर पर यह देखा जाता है कि क्या आप असल में काम को डिलीवर कर सकते हैं। इसमें लॉग पढ़ना, टूल टाइमआउट या खराब रिट्रीवल जैसी फेलियर की वजहों का पता लगाना और पूरे सिस्टम को दोबारा लिखे बिना खास सुधार करना शामिल है।
बिहेवियरल या राइटिंग राउंड में अक्सर यह देखा जाता है कि क्या आप ट्रेड-ऑफ, जोखिम और स्टेटस के बारे में इस तरह बता सकते हैं जिससे इंजीनियर और नॉन-इंजीनियर दोनों का भरोसा बने। रोलआउट के मामले में, यह एक छोटा सा ब्रीफ हो सकता है जिसमें बताया जाए कि आप टूल के इस्तेमाल को अलाउलिस्ट (allowlists) के ज़रिए क्यों सीमित कर रहे हैं और विस्तार करने से पहले एक ही क्यू (queue) से क्यों शुरुआत कर रहे हैं।
आम राउंड के प्रकारों और हर राउंड से क्या मापने की कोशिश की जा रही है, इसके बारे में जानें।