तकनीकी इंटरव्यू गलत इंजीनियरों को अस्वीकार कर देते हैं
अव्यक्त ज्ञान, तर्क, और संचार
- कई टिप्पणियाँ इस बात पर ज़ोर देती हैं कि बहुत-सा इंजीनियरिंग कौशल अव्यक्त होता है: पैटर्न पहचानना, समस्याएँ महसूस करना, और स्थितिजन्य जागरूकता बनाए रखना।
- इस पर असहमति है कि क्या “तुरंत स्पष्ट रूप से बोल पाना” ही काम है:
- एक पक्ष: तकनीकी तर्क को रीयल टाइम में संप्रेषित करना इस भूमिका का मुख्य हिस्सा है।
- दूसरा पक्ष: स्पष्ट अभिव्यक्ति गहरी समझ से आती है; उच्च दबाव वाले माहौल में तुरंत व्याख्या करवाना वास्तविक क्षमता का सही माप नहीं है।
- कुछ लोग तर्क देते हैं कि अच्छे इंजीनियरों को अक्सर अकेले सोचने, और बाद में ठोस योजनाओं के साथ लौटने के लिए समय चाहिए, न कि तुरंत समाधान देने के लिए।
इंटरव्यू के प्रारूप और स्वर
- प्रस्तावित “अनुभवी” इंटरव्यू: उम्मीदवार को कंपनी के लक्ष्यों को आगे बढ़ाने के अपने तरीके प्रस्तुत करने का समय मिले, उसके बाद तकनीकी पूछताछ हो।
- इस बात का विरोध कि टकरावपूर्ण framing (“हम आपका मूल्यांकन करेंगे”, “जैसा हमें उचित लगे”) चिंता बढ़ाती है और संकेतों को खराब करती है; सुझाव है कि इसे tradeoffs की सहयोगी समीक्षा के रूप में प्रस्तुत किया जाए।
- सिस्टम डिज़ाइन और take-home अभ्यास व्यापक रूप से ज्ञात हैं:
- समर्थकों के अनुसार ये वास्तविक काम से बेहतर मेल खाते हैं और सहयोग व संचार पर ज़ोर दे सकते हैं।
- आलोचक नोट करते हैं कि उम्मीदवार अक्सर लंबे take-home को “मुफ़्त काम” कहकर शिकायत करते हैं, और इंटरव्यू लेने वाले समस्याओं से बहुत परिचित हो जाते हैं, जिससे वे यह गलत आंकते हैं कि समाधान कितना “स्पष्ट” था।
लंबाई, नौकरशाही, और इंटरव्यू किसे चुनते हैं
- एक पक्ष का तर्क है कि 2–3 घंटे और कई राउंड उचित हैं, खासकर उच्च वेतन वाली भूमिकाओं के लिए; प्रयास प्रेरित उम्मीदवारों को छाँटता है।
- दूसरा पक्ष लंबे, बहु-चरणीय प्रक्रियाओं को “hoop-jumping” मानता है, जो:
- मजबूत लेकिन गैर-हताश इंजीनियरों को बाहर कर देती हैं।
- संगठन की धीमी गति और नौकरशाही का संकेत देती हैं।
- यह दृष्टिकोण कि इंटरव्यू डिज़ाइन स्वभावतः कुछ गुणों का चयन करता है (नौकरशाही सहनशीलता, तनाव में प्रदर्शन आदि), न कि केवल शुद्ध क्षमता का।
अनुभव-आधारित बनाम कोडिंग चुनौतियाँ
- कई लोग पिछले प्रोजेक्ट्स पर गहराई से चर्चा करने की वकालत करते हैं: भूमिका, निर्णय, tradeoffs, व्यवसायिक प्रभाव, और आर्किटेक्चर।
- अन्य चेतावनी देते हैं कि यह “failed up” उम्मीदवारों और अच्छी बात करने वालों को ज़्यादा महत्व देता है; इंटरव्यू लेने वाले दावों को विश्वसनीय रूप से सत्यापित नहीं कर सकते।
- कोडिंग/व्हाइटबोर्ड इंटरव्यू को नौकरी के प्रदर्शन से कम-संबंधित माना जाता है, फिर भी इन्हें कुछ बुनियादी कौशल पकड़ने के लिए उपलब्ध कुछ औज़ारों में से एक के रूप में बचाव किया जाता है, जब प्रमाणपत्र और कार्यकाल भरोसेमंद न हों।
AI का प्रभाव
- कुछ इंटरव्यू लेने वाले रिपोर्ट करते हैं कि उम्मीदवार LLMs के बिना जटिल समस्याओं में संघर्ष करते हैं।
- सुझावों में शामिल हैं:
- उम्मीदवारों को AI उपयोग करने देना और समस्या-खंडन, आवश्यकता विश्लेषण, और कोड समीक्षा का मूल्यांकन करना।
- कच्ची मैनुअल कोडिंग के बजाय सत्यापन, परीक्षण, और टूलिंग पर ज़ोर देना।
- इस बात पर स्पष्ट सहमति नहीं है कि मूल्यांकन का कितना हिस्सा AI सहायता होना चाहिए।