जब आप खुद टेक्निकल न हों तो डेवलपर कैसे हायर करें

वह पल जब एहसास होता है कि आप गहरे पानी में हैं

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

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

टेक्निकल जानकारी का दिखावा न करें — यह उल्टा पड़ता है

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

इसके बजाय ईमानदार रहें। "मैं टेक्निकल नहीं हूँ, इसलिए मैं चाहूँगा कि आप चीज़ों को आसान भाषा में समझाएँ, और इस प्रक्रिया के कुछ हिस्से के लिए मैं किसी टेक्निकल व्यक्ति की मदद भी लूँगा।" यह कमज़ोरी नहीं है — यह वही है जो एक सक्षम हायरिंग मैनेजर किसी भी ऐसे क्षेत्र में हायरिंग करते समय करता है जिसे वह खुद प्रैक्टिस नहीं करता।

किसी और की टेक्निकल नज़र उधार लें — पूरी प्रक्रिया के लिए नहीं, सिर्फ एक घंटे के लिए

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

यह कोई भी हो सकता है:

• कोई फ्रीलांस डेवलपर जिसे आप दो घंटे की सलाह के लिए भुगतान करते हैं
• कोई दोस्त या सलाहकार जिसने पहले सॉफ्टवेयर बनाया हो
• कोई कॉन्ट्रैक्टर जिसे आप पहले से किसी और काम के लिए इस्तेमाल करते हैं

आप उनसे जो काम कराना चाहते हैं, वह बहुत सीमित होना चाहिए: "इस कैंडिडेट का इस खास सवाल का जवाब देखिए और बताइए कि क्या यह ठीक है।" यह मत कहें कि "इस व्यक्ति की पूरी जाँच कर दो" — यह बहुत अस्पष्ट है और किसी उपकार के लिए बहुत ज़्यादा माँगना है।

कैंडिडेट्स से उनका खुद का काम समझाने को कहें, काल्पनिक सवाल नहीं

जिस डेवलपर ने वाकई कुछ बनाया है, वह उसे आसान भाषा में समझा सकता है, चाहे आप कितनी भी गहराई में जाना चाहें। जो व्यक्ति अपने CV में पानी भर रहा होता है, वह आमतौर पर सतह से आगे नहीं जा पाता।

अच्छे सवाल, इस क्रम में कि वे कितना खोलकर सामने रखते हैं:

1. "मुझे कुछ ऐसा बताइए जो आपने बनाया और जिस पर आपको गर्व है। उसने क्या किया, और उसमें आपकी भूमिका क्या थी?"
2. "उस प्रोजेक्ट में सबसे कठिन टेक्निकल समस्या क्या थी, और आपने उसे कैसे हल किया?"
3. "अगर मैं उस टीम के बाकी इंजीनियरों से पूछूँ कि आपके साथ काम करना कैसा था, तो वे क्या कहेंगे — और क्यों?"
4. "एक ऐसा वाकया बताइए जब आपके कोड ने प्रोडक्शन में कुछ बिगाड़ दिया हो। क्या हुआ और आपने क्या किया?"

चौथा सवाल सबसे ज़्यादा काम का है। लगभग हर असली डेवलपर ने कभी न कभी कुछ बिगाड़ा होता है। जो व्यक्ति कुछ साल के दावे किए गए अनुभव के बाद कहता है "मेरे साथ ऐसा कभी नहीं हुआ", वह या तो झूठ बोल रहा है या उसने कभी कोई ऐसी चीज़ शिप ही नहीं की जो मायने रखती हो।

एक छोटा, असली वर्क सैंपल इस्तेमाल करें

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

इसे निष्पक्ष रखें:

• इसके लिए भुगतान करें, या इसे वाकई इतना छोटा रखें कि बिना भुगतान के भी उचित लगे (ज़्यादातर कैंडिडेट्स आपको बता देंगे कि कौन-सी स्थिति सही है)
• उस चरण पर सभी को एक जैसा टास्क दें
• बाद में उनसे अपने समाधान पर बातचीत करने को कहें — यहीं आपको पता चलेगा अगर किसी को ऐसी मदद मिली हो जिसका उसने ज़िक्र नहीं किया

अगर आपके पास खुद परिणाम की समीक्षा करने के लिए टेक्निकल समझ नहीं है, तो यही वह पल है जब आपको अपना उधार लिया हुआ टेक्निकल घंटा खर्च करना चाहिए।

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

यह देखें कि उन्होंने क्या शिप किया, न कि वे क्या जानने का दावा करते हैं

टेक्नोलॉजी के नामों से भरा CV आपको बस यह बताता है कि किसी ने किन चीज़ों को छुआ है, यह नहीं कि वह किसमें अच्छा है। इसके बजाय सबूत माँगें:

• GitHub प्रोफाइल, पोर्टफोलियो, या किसी लाइव चीज़ का लिंक जो उन्होंने बनाई हो
• कंपनी और प्रोडक्ट का नाम, ताकि आप खुद उसे देख सकें
• किसी प्रोजेक्ट का कितना हिस्सा वाकई उनका था, बनाम टीम का

टूल्स की लंबी सूची से प्रभावित न हों। एक या दो ऐसी चीज़ों में दिलचस्पी लें जिनमें वे गहराई से जा सकते हैं। गहराई ही असली संकेत है; बज़वर्ड्स की चौड़ाई अक्सर इसका उलटा होती है।

रेफरेंस चेक: स्किल के बारे में नहीं, डिलीवरी के बारे में पूछें

आप किसी रेफरेंस से "क्या उनका कोड अच्छा था?" नहीं पूछ सकते और उपयोगी जवाब की उम्मीद नहीं कर सकते, जब तक कि रेफरेंस भी टेक्निकल न हो — और तब भी, यह एक नरम, उदार सवाल है जिस पर लोग शायद ही कभी सवाल उठाते हैं।

इसके बजाय पूछें:

• "क्या उन्होंने वह पूरा किया जो उन्होंने कहा था कि पूरा करेंगे, उसी समयसीमा में जिसका अनुमान उन्होंने लगाया था?"
• "जब कुछ गड़बड़ हुआ, तो क्या उन्होंने आपको पहले ही बता दिया या आपको बाद में पता चला?"
• "क्या आप उन्हें कोई अस्पष्ट काम सौंपकर भरोसा कर सकते हैं कि वे खुद रास्ता निकाल लेंगे, या हर चीज़ बिल्कुल साफ-साफ बतानी पड़ती है?"

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

यहाँ की ईमानदार सीमा

इनमें से कोई भी तरीका किसी ऐसे टेक्निकल व्यक्ति की जगह नहीं ले सकता जिस पर आप अंततः भरोसा करें। अगर यह हायर आपका पहला इंजीनियर है और आपके नेटवर्क में वाकई कोई ऐसा नहीं है जो उनकी जाँच-परख कर सके, तो इसे एक जोखिम के तौर पर खुलकर स्वीकार करना बेहतर है — खुद से, और शायद किसी शुरुआती निवेशक या सलाहकार से भी, जो किसी को जानता हो। साफ, गैर-टेक्निकल डिलीवरी माइलस्टोन्स (चीज़ शिप हुई या नहीं, वह काम करती है या नहीं, यूज़र्स ने शिकायत की या नहीं) के साथ 90 दिन की प्रोबेशन अवधि आपका बैकस्टॉप है, अगर हायर इंटरव्यू में दिखे प्रदर्शन से कमज़ोर निकले।

आप डेवलपर बनने की कोशिश नहीं कर रहे। आप एक ऐसी प्रक्रिया बनाने की कोशिश कर रहे हैं जो उस फर्क को पकड़ सके जो किसी ऐसे व्यक्ति के बीच होता है जिसने वाकई चीज़ें बनाई हैं, और किसी ऐसे व्यक्ति के बीच जिसने बस उसके लिए शब्द रट लिए हैं।