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

आधुनिक साक्षात्कार के बारे में

उपरोक्त लेख के लेखक की शिकायत है कि साक्षात्कार के दौरान उनसे तकनीकी प्रश्न नहीं पूछे गए थे। क्या यह बुरा है? हम में से कितने लोग हर दिन काम पर लाल-काले पेड़ लिखते हैं या आभासी वंशानुक्रम का उपयोग करते हैं (ये सिर्फ उदाहरण हैं, कृपया, टिप्पणियों में उनकी उपयोगिता पर चर्चा न करें)?

मुझे ऐसा लगता है कि ऐसे बहुत से लोग नहीं हैं जिन्होंने अंतिम प्रश्न का उत्तर सकारात्मक रूप से दिया है। लेकिन यह वही है जो वे तकनीकी साक्षात्कार में पूछना पसंद करते हैं। क्या व्यवसाय को बहुत नुकसान होगा अगर यह एक ऐसे व्यक्ति को काम पर रखता है जो बिना खोज इंजन के इस तरह के सवाल का जवाब नहीं दे सकता है?

समस्या यह है कि तकनीकी साक्षात्कार में प्रश्न डेवलपर के वास्तविक कार्यों से बहुत अलग हैं । साक्षात्कार चरण गुजरने पर उम्मीदवार कंपनी में प्रदर्शन करेंगे कि कार्यों से भी शामिल है। तो यह क्यों है? क्यों LeetCode के साथ समस्याओं को हल करने की क्षमता या विदेशी भाषा के उपकरण के ज्ञान का परीक्षण करें? यह क्यों आवश्यक है अगर यह भविष्य में शायद ही उपयोगी है, और यदि यह उपयोगी है, तो आप हमेशा इन एल्गोरिदम और सिद्धांतों का विस्तृत विवरण पा सकते हैं?

और सबसे महत्वपूर्ण बात: यह सिर्फ एक बेकार परीक्षा नहीं है। वह साक्षात्कार को व्यर्थ और निर्दयी नरक में बदल देती है। इस वजह से, एक साक्षात्कार की तैयारी वास्तव में, समस्याओं का एक निरर्थक समाधान बन जाती है। स्वयं साक्षात्कार में, तंत्रिका अपने टोल लेते हैं और यहां तक ​​कि सबसे योग्य उम्मीदवार कभी-कभी सरल कार्यों को हल करने में खो जाते हैं।

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

एक बार फिर, मैं निम्नलिखित पर ध्यान आकर्षित करना चाहता हूं: कार्यों का साक्षात्कार करना सामान्य है, लेकिन केवल अगर ये कार्य सरल हैं और इसका समाधान साक्षात्कारकर्ता और साक्षात्कारकर्ता के बीच बातचीत में बदल जाता है । यहां मुख्य बात यह जांचना है कि उम्मीदवार कैसे सोचता है। कैसे वह समस्या के समाधान के लिए संपर्क करता है। यही मायने रखता है, न कि वह इस समस्या को हल करेगा या नहीं। आप उन डेवलपर्स की तलाश नहीं कर रहे हैं जिनके एकमात्र कौशल LeetCode के साथ समस्याओं को हल कर रहे हैं?

कठोर और नरम कौशल

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

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

प्रचार तकनीक के बारे में

एकमात्र बिंदु जिसमें मैं लेख के लेखक से सहमत हूं, लेकिन यह अंत नहीं है। हां, औसत दर्जे और पीआर प्रौद्योगिकियों के साथ एक समस्या है। लेकिन यहां यह ध्यान रखना महत्वपूर्ण है कि यह बेहतर है कि हर कोई एक चीज का उपयोग करे। एकमात्र समाधान जल्द या बाद में सबसे विस्तृत हो जाएगा। यदि केवल इसलिए कि इसके डेवलपर्स के पास इसके लिए धन और संसाधन हैं। अन्यथा, हम कई समाधान प्राप्त करेंगे जो अच्छी तरह से शुरू हुए, लेकिन विकास के दौरान विभिन्न समस्याओं का अधिग्रहण किया। मामलों की यह स्थिति केवल "14 वें मानक" के विकास को प्रोत्साहित करती है। और इसी तरह। चलो सब एक समाधान का उपयोग करें। किसी दिन, उनकी समस्याओं का समाधान किया जाएगा, जो एकल उपयोगकर्ताओं के साथ 10 अलग-अलग समाधानों में से प्रत्येक के बारे में नहीं कहा जा सकता है।