AI इंजीनियर को बिना नुकसान के कैसे नियुक्त करें

उस निर्णय के लिए नियुक्ति करें जो लगातार सामने आता है

डेमो काम करता है। रिज़्यूमे प्रभावशाली है। हर कोई इंटरव्यू से उत्साहित होकर निकलता है।

फिर कोई पूछता है कि अगर सिस्टम एक ही रिफंड दो बार जारी करे तो क्या होगा।

चुप्पी एक महंगा जवाब है।

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

आपको अटेंशन हेड्स के बारे में तर्क जीतने की जरूरत नहीं है। आपको पर्याप्त साक्ष्य चाहिए ताकि आप तय कर सकें कि इन निर्णयों को आपके behalf पर कौन संभालेगा।

डेमो के पीछे के निर्णय के लिए भर्ती करें। वह निर्णय ऑफ़र देने से पहले देखे जाने योग्य बनाएं।

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

रिज़्यूमे खरीदने से पहले नौकरी लिखें

“हमें एक AI इंजीनियर चाहिए” उतना ही उपयोगी है जितना “हमें पैसे संभालने वाला चाहिए”। अकाउंटेंट? CFO? वह व्यक्ति जो संस्थापक को डोमेन खरीदना बंद करने को कहता है?

उस समस्या को चुनें जिसे आप किसी को सौंपने के लिए भर्ती कर रहे हैं।

एक व्यक्ति कई पंक्तियों को कवर कर सकता है। सभी पाँच में समान गहराई की उम्मीद करना वह तरीका है जिससे नौकरी विवरण एक वेतन के साथ इच्छा सूची में बदल जाता है।

इंटरव्यू खोलने से पहले पहले-90-दिनों का परिणाम लिखें। उदाहरण के लिए:

यह स्थापित करें कि क्या एक सपोर्ट-ड्राफ्टिंग असिस्टेंट हैंडलिंग टाइम को कम करता है बिना नीति त्रुटियों को बढ़ाए। एक मापी गई पायलट, एक मानव समीक्षा पथ, और विस्तार, संशोधन, या रोकने की सिफ़ारिश प्रदान करें।

यह उम्मीदवार को कुछ ऐसा देता है जिस पर वह प्रतिवाद कर सके, यही बिंदु है। एक मजबूत उम्मीदवार पूछेगा कि हैंडलिंग टाइम कैसे मापा जाता है, नीति का स्वामित्व कौन रखता है, और क्या किसी ने वर्तमान मानव उत्तरों की गुणवत्ता जाँची है। एक कमजोर उम्मीदवार कहेगा कि यह रोमांचक लगता है।

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

उन्हें हुड खोलने को कहें

एक प्रसिद्ध नियोक्ता आपको बताता है कि कोई व्यक्ति कहाँ काम करता रहा। एक डेमो आपको बताता है कि कुछ एक बार, लैपटॉप पर, अच्छे मूड में काम किया। दोनों यह नहीं बताते कि यह व्यक्ति आपकी टीम में क्या स्वामित्व ले सकता है।

एक प्रोजेक्ट के बारे में पूछें जिसके बारे में वह पूरी तरह से बात कर सके:

“ऐसे किसी काम के बारे में बताइए जिसे आपने व्यक्तिगत रूप से शिप किया। आपने क्या स्वामित्व लिया, क्या टूट गया, और साक्ष्य के कारण क्या बदला?”

फिर एक निर्णय को पूरे आर्क में फॉलो करें। पहला दृष्टिकोण क्या था? उन्होंने क्या मापा? किस वैकल्पिक को उन्होंने अस्वीकार किया, और क्यों? एक सहयोगी ने क्या योगदान दिया? अब वे क्या अलग करेंगे?

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

एक उम्मीदवार जो पूर्व नियोक्ता के ग्राहक डेटा को सौंपने से इनकार करता है, वह टेस्ट पास कर रहा है, फेल नहीं।

इसके बजाय एक पुनर्निर्मित उदाहरण लें, या नीचे दिया गया साझा अभ्यास उपयोग करें। “साक्ष्य दिखाइए” कभी भी “किसी और के रहस्य लाएँ” नहीं बनना चाहिए।

एक शुरुआती‑करियर हायर के लिए, साक्ष्य छोटा हो सकता है और यह ठीक है। अपेक्षित दायरे और निगरानी को भूमिका के अनुसार स्केल करें। आप समझ और स्वामित्व का परीक्षण कर रहे हैं, प्रसिद्ध लोगो तक पहुँच का नहीं।

इंटरव्यू समय के लायक पाँच प्रश्न

ये जाँच के लिए प्रॉम्प्ट हैं, ट्रिविया नहीं। यदि उत्तर याद करना पास करने के लिए पर्याप्त है, तो प्रश्न कुछ नहीं कर रहा है।

1. “आप कैसे बताएँगे कि यह एजेंट सुधरा है?”

जॉब की भाषा में सफलता को सुनें: सही तरीके से हल किए गए टिकट, एजेंट द्वारा वास्तव में भेजे गए ड्राफ्ट, उन एस्केलेशन जो नहीं होने चाहिए थे। फिर पूछें कि कौन‑सी विफलताएँ औसत स्कोर में छिपी होंगी, और वे नई संस्करण की तुलना किससे करेंगे।

एक अच्छा उत्तर माप को निरीक्षण योग्य बनाता है। उनसे तुरंत तीन टेस्ट केस स्केच करने को कहें और बताएँ कि कौन तय करेगा कि प्रत्येक पास हुआ या नहीं। यदि मॉडल उत्तरों को ग्रेड करता है, तो पूछें कि वे ग्रेडर को कैसे जांचते हैं। “यह 94 % स्कोर करता है” एक माप नहीं है यदि वही रन मंगलवार को 82 % स्कोर करता है.

Anthropic की एजेंट इवैल्यूएशन गाइड वह अंतर दर्शाती है जो आपके इंटरव्यू में होना चाहिए: एक एजेंट ने क्या किया इसका रिकॉर्ड परिणाम के समान नहीं है। एजेंट का कहना “मैंने रिफंड जारी किया” एक वाक्य है, रिफंड नहीं।

2. “टूल ने रिफंड सबमिट करने के बाद टाइम‑आउट कर दिया। अब क्या?”

“रीट्राई” एक गलत प्रतिक्रिया है। पैसा पहले ही जा चुका हो सकता है।

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

3. “यह सिस्टम क्या पढ़ सकता है, क्या बदल सकता है, और क्या खर्च कर सकता है?”

सीमा के बारे में पूछें: यह कौन से रिकॉर्ड पढ़ सकता है, कौन सी कार्रवाइयां कर सकता है, मानव अनुमोदन कहाँ आवश्यक है, और आपके क्रेडिट कार्ड पर रात भर किसी लूप को चलने से क्या रोकता है।

फिर पूछें कि वह सीमा कहाँ लागू होती है। मॉडल को सावधान रहने का निर्देश देने वाला प्रॉम्प्ट नीति पाठ से बनी फ़ायरवॉल की तरह है — मंशा मौजूद है, प्रवर्तन नहीं। उनसे सीमा खींचने और उसे पार करने की कोशिश करने वाला एक टेस्ट प्रस्तावित करने को कहें।

साथ ही डेटा एक्सपोज़र की भी जाँच करें: मॉडल प्रदाता के पास क्या जाता है, लॉग्स में क्या लिखा जाता है, और उन लॉग्स को कौन पढ़ सकता है। “हम सब कुछ लॉग करते हैं” एक ऐसा बयान है जो सीधे कम्प्लायंस की समस्या बन सकता है।

4. “कौन‑सा भाग आप बिना LLM के बनाएँगे?”

एक सक्षम इंजीनियर अपने प्रस्ताव के कुछ हिस्सों से AI को निकाल सकता है। पात्रता नियम, अंकगणित, और अनुमति जाँचों के नीरस कार्यान्वयन कभी भी hallucinate नहीं होते। लेकिन एक निराश ग्राहक का मतलब समझना ऐसा नहीं है।

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

5. “ऐसे किसी दृष्टिकोण के बारे में बताइए जिसे आपने छोड़ दिया।”

सुनें कि कौन‑सी अवलोकन ने उनका विचार बदल दिया। उपयोगकर्ता चाहते थे सर्च, चैट नहीं। महँगा मॉडल कुल हैंडलिंग लागत को घटा देता है। फीचर शिप करने लायक नहीं था और उन्होंने यही कहा।

एक ईमानदार नकारात्मक परिणाम एक चमकदार सफलता कथा से बेहतर होता है, क्योंकि सफलता कथा अक्सर निर्णय नियम नहीं दिखाती। पूछें कि उन्होंने क्या बंद किया, और इसे बंद करने में उन्हें कितना समय लगा।

छोटे कार्य‑सत्र के लिए भुगतान करें

सिंथेटिक डेटा पर सीमित, भुगतान‑युक्त अभ्यास का उपयोग करें। ब्रीफ़ और स्कोरिंग मानदंड पहले से भेजें — आप निर्णय‑क्षमता की तलाश में हैं, न कि घात‑परीक्षण की। लोगों को वही टूल्स इस्तेमाल करने दें जो वे नौकरी में उपयोग करेंगे, AI सहित, और फिर उनसे पूछें कि उन्होंने क्या निकाला और क्यों।

एक एप्लिकेशन इंजीनियर के लिए 90‑मिनट का उदाहरण‑सत्र:

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

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

आप देख रहे हैं कि वे कौन‑से प्रश्न पूछते हैं, कौन‑से प्रमाण खोलते हैं, और किस जोखिम को पहले उठाते हैं। क्या उन्हें पता चलता है कि बारह टिकटों से विश्वसनीयता स्थापित नहीं की जा सकती? क्या वे एक संकीर्ण सुधार शिप कर सकते हैं बिना यह कहे कि सिस्टम अब ठीक है? क्या वे बता सकते हैं कि अगले हफ़्ते क्या होना चाहिए?

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

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

हायरिंग स्कोरकार्ड

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

1 = असमर्थित या मूल रूप से त्रुटिपूर्ण, 2 = पर्याप्त मार्गदर्शन के साथ कार्यशील, 3 = भूमिका के दायरे में उचित, 4 = उचित निर्णय के साथ प्रदर्शित सत्यापन का उपयोग करें। जब इंटरव्यू में कभी प्रमाण नहीं मिला हो तो N/O = not observed का प्रयोग करें। N/O एक खाली जगह है जिसे भरना है, शून्य नहीं जिसे औसत में घटाया जाए।

यह एक निर्णय‑सहायक है, न कि नौकरी प्रदर्शन का प्रमाणित भविष्यवक्ता। इसे अपनी भूमिका के अनुसार कैलिब्रेट करें, और लोगों के जुड़ने के बाद वास्तविक परिणामों से तुलना करें — अन्यथा आप ऐसे जज को ट्यून कर रहे हैं जिसे आपने कभी स्कोर नहीं किया।

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

डिब्रीफ़ को तीन वाक्यों के साथ समाप्त करें: यह व्यक्ति क्या स्वामित्व ले सकता है? उसे किस समर्थन की आवश्यकता होगी? हमें अभी किस बात पर अनिश्चितता है? यदि पैनल इन प्रश्नों का उत्तर नहीं दे पाता, तो वह एग्जीक्यूटिव प्रेज़ेंस पर 40‑मिनट की बातचीत करने वाला है।

लाल झंडे एक अतिरिक्त प्रश्न के लायक होते हैं

ध्यान रखें जब उम्मीदवार अपने योगदान को टीम से अलग नहीं कर पाता, हर पिछले प्रोजेक्ट को अटूट सफलता मानता है, या माप‑संबंधी प्रश्नों का उत्तर विशेषणों से देता है। “उच्च सटीकता” के लिए हर बार हर का उल्लेख आवश्यक है।

अन्य धुंध: एजेंट समस्या को समझे बिना डिज़ाइन में प्रकट होते हैं; संचालन लागत की कोई सीमा नहीं होती; विफलता पुनर्प्राप्ति किसी अन्य टीम की जिम्मेदारी बन जाती है; सुरक्षा पूरी तरह प्रॉम्प्ट में ही रहती है।

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

पहले ही भर्ती को लेकर चिंतित हैं? काम का ऑडिट करें

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

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

कुछ प्रतिनिधि वर्कफ़्लो पर स्वतंत्र पढ़ाई करवाएँ। क्या काम करता है? क्या विफल होता है? कौन‑से दावे दोहराते हैं? अनिश्चित व्यवहार की जाँच के दौरान जोखिमपूर्ण कार्यों को प्रतिबंधित करें, और काम को रख‑रखाव, मरम्मत और प्रतिस्थापन में वर्गीकृत करें।

एक छोटा पुनर्प्राप्ति योजना माँगें जिसमें स्वीकृति‑परीक्षण, नामित मालिक और निर्णय तिथि शामिल हो। “हमें नया फ्रेमवर्क चाहिए” एक निदान नहीं, बल्कि जांचने के लिए प्रस्ताव है।

भर्ती को रोडमैप को निराश करने की अनुमति दें

यदि आपकी कंपनी उस निर्णय को दंडित करती है जिसे उसने छह हफ़्ते में चुनने में खर्च किया है, तो यह सब व्यर्थ है।

वह इंजीनियर जो कहता है “मानव अनुमोदन इस चरण पर रहना चाहिए” या “पायलट अभी विस्तार को उचित नहीं ठहराता” को ऐसे नेता की जरूरत है जो इसे दूसरों के सामने सुन सके। साक्ष्य के आधार पर भर्ती करें, फिर असुविधाजनक निष्कर्षों को दबा दें, और आप एक महँगा मशीन बना रहे हैं जो वही उत्तर उत्पन्न करती है जो आप पहले से चाहते थे।

अगली AI भूमिका के लिए: परिणाम लिखें, स्कोरकार्ड का उपयोग करें, और देखें कि उम्मीदवार असंपूर्ण चीज़ में कितनी गहराई तक जाता है।

आपको वह व्यक्ति चाहिए जो आपको बता सके कि सिस्टम क्यों तैयार है — और जो खुले तौर पर, जब वह तैयार न हो, तो उसी दिन आपको सच बताए।