tl; dr पिछले दशकों में, प्रोग्रामर के साक्षात्कार के लिए फैशन कई बार बदल गया है, और उनमें से प्रत्येक पूर्वव्यापी में हास्यास्पद दिखता है। या तो हमने आखिरकार प्रभावी साक्षात्कारों का वास्तविक रहस्य पाया, या अगले फैशन ट्रेंड द्वारा दूर किया गया, जो दस से बीस वर्षों में बस उतना ही हास्यास्पद लगेगा।

जब मैं फैशनेबल बड़ी प्रौद्योगिकी कंपनियों के लोगों से पूछता हूं कि साक्षात्कार में एल्गोरिदम के बारे में पूछना इतना आवश्यक क्यों है, तो सबसे आम उत्तर कुछ इस तरह है: "हमारे पास यह पैमाना है, हम किसी को भी O(n^2) लिखने की अनुमति नहीं दे सकते हैं O(n^2) और पूरे सिस्टम को खटखटाया " ¹ । विशेष रूप से मजेदार है, हाल ही में मैंने इन एल्गोरिदम को बहुत अभ्यास में लागू किया है और वास्तविक समस्याओं को हल किया है, लेकिन मैं उन साक्षात्कारों से नहीं गुजर सकता जहां लोग उनके बारे में पूछते हैं! क्या आपको लगता है कि मैं आधा साक्षात्कार या कुछ और असफल कर रहा हूं? नहीं, आधे से ज्यादा। मैंने लगभग 40 "वास्तविक" साक्षात्कारों में भाग लिया और शायद एक या दो पास किए। या एक भी ^{2 नहीं} ।

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

आइए कुछ उदाहरण देखें।

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

बड़ी आईटी कंपनियों में, विशिष्ट टेलीफोन साक्षात्कार तीन श्रेणियों में आते हैं:

1. एक "सरल" प्रोग्रामिंग / एल्गोरिथ्म प्रश्न, शायद "बहुत सरल" वार्म-अप प्रश्न के साथ।
   
2. "बहुत ही सरल" प्रोग्रामिंग / एल्गोरिदम संबंधी प्रश्नों की एक श्रृंखला।
   
3. प्रसिद्ध तथ्यों का एक गुच्छा (शायद ही कभी अच्छे पदों के लिए, लेकिन अक्सर निम्न-स्तर या गैर-रचनात्मक पदों के लिए)।

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

सौभाग्य से, इस कार्यान्वयन का उपयोग एक सार्वभौमिक गतिशील सरणी के रूप में नहीं किया गया था, बल्कि केवल अर्ध-विशिष्ट शेल की मदद से बनाया गया था, इसलिए यह जीसी पर दबाव के "केवल" 1% के लिए जिम्मेदार था। यदि साक्षात्कार में पूछा जाता है, तो उस टीम के अधिकांश सदस्य इसका सही उत्तर देंगे। मेरे जीवन में मेरे द्वारा किए गए मुकाबले मेरे पैच ने नियोक्ता को एक साल में अधिक पैसा दिलाया।

यह स्मृति आवंटन का दूसरा सबसे बड़ा स्रोत था, मुख्य एक ही आधार पुस्तकालय से बाइट सरणियों में long मूल्यों की एक जोड़ी का रूपांतरण था। जाहिरा तौर पर, किसी ने एक हैश फ़ंक्शन को लिखा या कॉपी किया, जिसने एक सरणी को इनपुट के रूप में लिया, और फिर दो सरणियों को लेने के लिए कोड को बदल दिया और byte[], byte[] जैसे पुराने हैश फ़ंक्शन से एक अनुक्रम में उनके साथ काम किया। इस फ़ंक्शन को दो long पर कॉल करने के लिए, उन्होंने व्यापक रूप से उपयोग की जाने वाली उपयोगिता लाइब्रेरी में byte[] long byte[] में रूपांतरण समारोह का उपयोग किया। byte[] को हाइलाइट करने के अलावा byte[] और वहां long चिपकाने के अलावा, यह फ़ंक्शन long बाइट ऑर्डर को भी बदल देता है (जाहिर है, फ़ंक्शन को long बाइट को नेटवर्क बाइट ऑर्डर में बदलने के लिए डिज़ाइन किया गया था)।

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

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

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

एल्गोरिदम पर एक साधारण प्रश्न का एक और उदाहरण है बिंग ^{3 के} लिए खोज सूचकांक, बिटफुनलाइन के लिए वास्तविक कॉन्फ़िगरेशन ।

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

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

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

1. एक उदाहरण एक साक्षात्कार के लिए एक प्रश्न के रूप में तैयार किया जा सकता है।
   
2. यदि प्रश्न तैयार हो गया है, तो आप अपेक्षा करते हैं कि संबंधित टीम के अधिकांश (या सभी) कर्मचारी सही उत्तर जानेंगे।
   
3. इस फिक्स से पैसे की बचत से नियोक्ता को मेरे जीवन में एक साल में अधिक पैसा मिलेगा।
   
4. उदाहरण से समस्या लंबे समय तक बनी रही, अन्यथा इस पर ध्यान नहीं दिया जाता।

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

कारणों में से एक यह है कि बड़ी कंपनियां उन लोगों को खोजने की कोशिश कर रही हैं जो एल्गोरिथम पहेली को हल कर सकते हैं, लेकिन उत्पादन में इस तरह के तर्क को रोकते हैं।

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

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

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

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

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

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

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

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

यदि अन्य कंपनियां चाहती हैं कि लोग उसी स्तर के एल्गोरिदम की कार्य समस्याओं को हल करें जो वे साक्षात्कार में पूछते हैं, तो आपको मूल रूप से लोगों को एल्गोरिदम (जब उपयुक्त हो) की समस्याओं को हल करने के लिए प्रोत्साहित करना होगा। यह सैद्धांतिक समस्याओं के लिए उम्मीदवारों का चयन करने के बजाय या इसके अलावा भी किया जा सकता है।

परिशिष्ट: हमें यह कैसे मिला?

अच्छे पुराने दिनों में, "तुच्छ" प्रश्न साक्षात्कार में पूछे गए थे। आधुनिक संस्करण इस तरह दिख सकते हैं:

• MSI क्या है? MESI? MOESI? MESIF? MOESI पर MESIF का क्या फायदा है?
  
• एक विध्वंसक क्या करता है? और अगर यह C ++ 11 है? और यदि आप शीर्ष स्तर के विध्वंसक से उप-विध्वंसक को विध्वंसक कहते हैं, तो अन्य उप-विध्वंसक विध्वंसक को क्या अंजाम दिया जाएगा? और स्टैक के प्रचार के दौरान? किन परिस्थितियों में आप कॉल करने से बच सकते हैं std::terminate ?

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

12 अंक उत्कृष्ट हैं, 11 अंक सहनीय हैं, लेकिन 10 या उससे कम की रेटिंग से आपको गंभीर समस्याएं हैं। सच्चाई यह है कि अधिकांश सॉफ्टवेयर 2-3 बिंदुओं के स्तर पर काम करते हैं, और उन्हें गंभीर मदद की आवश्यकता होती है, क्योंकि Microsoft जैसी कंपनियां 12 पूर्णकालिक स्तर पर काम करती हैं।

उस समय के लोकप्रिय किंवदंतियों के अनुसार, Microsoft ने साक्षात्कारों में इस तरह के सवालों के बारे में पूछा (और मुझे 2001 के आसपास Microsoft में एक साक्षात्कार में इन कार्यों में से एक से पूछा गया था, जिसमें एल्गोरिदम या प्रोग्रामिंग के बारे में कोई सवाल नहीं है):

• यदि आपकी ऊंचाई 1 सेमी है, तो एक ब्लेंडर से कैसे बाहर निकलें?
  
• मैनहोल कवर गोल क्यों हैं?
  
• खिड़की रहित कमरे में तीन लैंप हैं, जिनमें से प्रत्येक को बाहर से एक स्विच द्वारा नियंत्रित किया जाता है। आप कमरे के बाहर हैं और केवल एक बार अंदर जा सकते हैं। कैसे निर्धारित करें कि कौन सा स्विच किस दीपक को नियंत्रित करता है?

चूँकि मुझे बदलाव के युग में साक्षात्कार दिया गया था, इसलिए मुझे बहुत सारे सरल प्रश्न और कार्यों का एक गुच्छा (उपरोक्त सभी सहित) पूछा गया था। उस समय के साक्षात्कार में, फ़र्मी के प्रश्न , जो तकनीकी रूप से पहेली नहीं थे, अभी भी लोकप्रिय थे। समय का एक और चलन एक तकनीकी मुद्दे के बिना व्यवहार साक्षात्कार था।

जैसा कि हो सकता है, तब लोगों ने माइक्रोसॉफ्ट-शैली के साक्षात्कार की नकल करने की कोशिश की। जब मैंने पूछा कि कौन सी पहेलियाँ या फरमी के प्रश्न अच्छे थे, तो उन्होंने मुझे उत्तर दिया कि इस तरह यह जांचना संभव है कि क्या उम्मीदवार प्रतिबिंब के लिए सक्षम है, जैसा कि ज्ञान के सवालों के विपरीत है, जो केवल यह कहता है कि किसी व्यक्ति को कुछ जानकारी याद थी। और हमें ऐसे उम्मीदवारों की आवश्यकता है जो वास्तव में सोच सकें!

पीछे देखते हुए, अब यह सभी के लिए स्पष्ट है कि यह अक्षम था, और प्रत्येक Microsoft ट्रिक को कॉपी करने से आपकी कंपनी सफल नहीं होगी, क्योंकि Microsoft ने कई अन्य ट्रिक्स का उपयोग किया - वे केवल नेटवर्क प्रभाव के कारण एक साथ प्रभावी थे। Microsoft साक्षात्कारों की प्रतिलिपि बनाकर, आप एक ऐसी कंपनी बन जाएंगे जो बस उसी शैली में साक्षात्कार आयोजित करती है, लेकिन Microsoft द्वारा उपयोग किए जाने वाले नेटवर्क का लाभ नहीं उठा सकता है।

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

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

पिछले दशकों में, प्रोग्रामरों के साक्षात्कार का फैशन कई बार बदल गया है, और उनमें से प्रत्येक रेट्रोस्पेक्ट में हास्यास्पद दिखता है। या तो हमने अंततः प्रभावी साक्षात्कारों का वास्तविक रहस्य पाया, या अगले फैशन की प्रवृत्ति से दूर किया गया, जो दस से बीस वर्षों में बस उतना ही हास्यास्पद लगेगा।

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

से प्रेरित होकर , हाल ही में मैंने विशेष रूप से नियोक्ताओं के प्रतिनिधियों से पूछा कि वे अपने साक्षात्कार की प्रभावशीलता की जांच करते हैं और वे पूर्वाग्रह से कैसे निपटते हैं। यहां उन्होंने उत्तर दिया (आवृत्ति के घटते क्रम में):

• क्या? कुछ भी नहीं, यह क्यों है?
  
• हम वास्तव में नहीं जानते हैं कि क्या हमारी प्रक्रिया प्रभावी है।
  
• हम सिर्फ इतना जानते हैं कि सब कुछ काम करता है।
  
• हमारा कोई पक्षपात नहीं है।
  
• अगर आकलन प्रक्रिया होती तो हम पूर्वाग्रह देखते।
  
• किसी ने अनुसंधान का अध्ययन किया और / या संचालित किया है, लेकिन यह कैसे अध्ययन किया गया था और अध्ययन किस पद्धति से आयोजित किया गया था, इसके बारे में कुछ भी ठोस नहीं कह सकता।

आवेदन: प्रशिक्षण

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

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

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

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

मेरा मानना ​​है कि शिक्षा और प्रशिक्षण के मुद्रीकरण की सापेक्ष कठिनाई के कारण सार्वजनिक शिक्षण सामग्री की खराब गुणवत्ता पर ध्यान देना आसान है। यदि आप प्रशिक्षण कार्यक्रमों का मुद्रीकरण करना चाहते हैं, तो कुछ अच्छे तरीके हैं। जाहिर है, मूल्यवान वीडियो पाठ्यक्रमों का मुद्रीकरण अच्छी तरह से काम करता है (एक छोटे पाठ्यक्रम के लिए सैकड़ों या हजारों डॉलर)। कॉर्पोरेट प्रशिक्षण, जब कंपनियां आपको 30 लोगों के साथ बात करने के लिए आमंत्रित करती हैं, और आप प्रत्येक से 3,000 डॉलर लेते हैं, तो बहुत अच्छा काम करते हैं।

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

उदाहरण के लिए, जूलिया इवांसकंप्यूटर कॉमिक्स की बिक्री के लिए पर्याप्त आय, जो हाल ही में प्रति वर्ष लगभग $ 100 हजार लाती है। एक कॉर्पोरेट प्रशिक्षण विशेषज्ञ एक से दो दिनों में इसे अर्जित कर सकता है।

परिशिष्ट: प्रोत्साहन बेमेल के साथ गहराई में रक्षा, भाग 3

उपरोक्त तीन उदाहरणों में, दो मामलों में मुझे कंपनी के पैसे बचाने के लिए कुछ प्रोत्साहन मिला। मेरे अनुभव में, यह शायद ही कभी बड़ी कंपनियों में होता है, लेकिन फिर भी, प्रोत्साहन का वितरण बल्कि खराब निकला। कुछ बिंदु पर, पदोन्नति और वेतन वृद्धि के बाद, मैंने अपनी वृद्धि और बचत के अनुपात की गणना की, जिसे मैंने कंपनी में लाया। मेरे द्वारा विकसित किए गए औजारों को ध्यान में रखे बिना अनुपात सीधे पैसे में लगभग 0.03% था, जिसके लिए एक विशिष्ट मूल्य की गणना करना मुश्किल है। संभवतः यह मान वास्तव में एक मात्रात्मक मूल्य से अधिक है। इसलिए, हम यह निष्कर्ष निकाल सकते हैं कि मुझे कंपनी द्वारा लाई गई राशि का 0.01% से काफी कम प्राप्त हुआ। और यह एक overestimated आकलन है: वास्तव में, मुझे दृढ़ता से संदेह है कि वास्तव में किए गए काम ने मुझे कुछ भी नहीं लाया,और वृद्धि का इस परियोजना से कोई लेना-देना नहीं है, जिससे कंपनी को करोड़ों डॉलर की बचत हुई। पहले $ 10 मिलियन एक वर्ष, या शायद $ 20 मिलियन एक वर्ष के बाद, प्रभावशीलता, पदोन्नति, सुधार, आदि के मूल्यांकन के संदर्भ में काम करने के लिए कोई प्रोत्साहन नहीं है क्योंकि कोई प्लस नहीं हैं, लेकिन कुछ नुकसान हैं (आप कर सकते हैं) अंडरकवर इंटिग्रेशन में शामिल हो जाएं, गलती से किसी साइट को नीचे लाएं, आदि), ताकि वैकल्पिक काम करने पर वापसी नकारात्मक हो जाए।लेकिन कुछ नुकसान हैं (आप अंडरकवर इंटिग्रेशन में शामिल हो सकते हैं, गलती से किसी साइट को नीचे ला सकते हैं, आदि), ताकि वैकल्पिक काम करने पर वापसी संभवत: नकारात्मक हो जाए।लेकिन कुछ नुकसान हैं (आप अंडरकवर इंटिग्रेशन में शामिल हो सकते हैं, गलती से किसी साइट को नीचे ला सकते हैं, आदि), ताकि वैकल्पिक काम करने पर वापसी संभवत: नकारात्मक हो जाए।

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

इस प्रकार, इस अपेक्षाकृत पेशेवर टीम में भी, कंपनी की इनाम प्रणाली लोगों को दक्षता बढ़ाने के लिए उन्हें उत्तेजित किए बिना सीमित कर देती है।

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

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

संबंधित लिंक

• ट्रेंडिंग भर्ती प्रथाओं के पंथ पंथ की
  
• भक्ति का सामान्यीकरण
  
• Zvi Mousovitsa की पुस्तक "Moral Labyrinths" प्रणालीगत समस्याओं के बारे में जो निगम के सभी स्तरों पर असंगत विसंगतियों का कारण बनती है।
  
• Randomsong लिखते हैं कि आप लगभग किसी को भी प्रोग्रामिंग कैसे सिखा सकते हैं। विचार यह है कि प्रोग्रामिंग उतना मुश्किल नहीं है, जितना कि कई प्रोग्रामर विश्वास करना चाहेंगे।
  
• , — ,
  
• ,
  
• 
  
• HN Google, 10% ,

---

1. सबसे पहले, Google साक्षात्कार अक्सर छोटी कंपनियों की नकल करते हैं जिनके लिए यह तर्क अनुचित है। लेकिन यहां तक ​​कि बड़ी कंपनियों में से कोई भी बड़े पैमाने पर एल्गोरिदम को विकसित या कार्यान्वित नहीं करता है (Google ने शायद यह आखिरी 2003 के आसपास किया है, लेकिन आधुनिक बड़ी आईटी कंपनियों में कोई भी विशेष रूप से एल्गोरिदम विकसित करने पर ध्यान केंद्रित नहीं करता है)। [वापस]

2. "वास्तविक" उद्धरण चिह्नों में है क्योंकि मैं साक्षात्कार प्रक्रिया से संबंधित नहीं होने के कारणों के लिए कई साक्षात्कारों से गुजरा। शायद मेरी बहुत अच्छी सिफारिशें थीं, या हो सकता है कि किसी ने मेरे ब्लॉग को पढ़ा हो या पूर्व सहयोगियों से पूछताछ की हो, या मेरे ओपन सोर्स प्रोजेक्ट्स को देखा हो (जहाँ तक मुझे पता है, यह एक या दो बार हुआ)। आमतौर पर, साक्षात्कार में स्पष्ट विफलता के बाद, मैं पूछता हूं कि मुझे नौकरी क्यों दी गई थी, इसलिए मैंने पहले से ही ऐसे कारणों का एक संग्रह एकत्र किया।

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

कृपया ध्यान दें कि मेरे कमजोर परिणाम केवल प्रोग्रामिंग इंटरव्यू को संदर्भित करते हैं, हार्डवेयर को नहीं। मैं वास्तव में लोहे के लिए साक्षात्कार में अच्छा हूं, हालांकि मैंने इस काम में लंबे समय तक अभ्यास नहीं किया है। मेरे एक मित्र का कहना है कि विशिष्ट शब्दजाल के कारण हार्डवेयर साक्षात्कार मेरे लिए बहुत अच्छे हैं: मैं "एक हार्डवेयर इंजीनियर की तरह बोलता हूं" और वास्तव में हम इलेक्ट्रॉनिक इंजीनियरों के साथ एक ही भाषा बोलते हैं। दूसरी ओर, हम कुछ चीजों को इस तरह से कहते हैं कि वे अधिकांश प्रोग्रामर के लिए अविश्वसनीय रूप से मूर्खतापूर्ण लगते हैं, लेकिन समस्या शब्दावली, शब्दजाल और वास्तविक ज्ञान या कौशल के साथ नहीं है। [वापस]

3. यह फोन से उम्मीद से थोड़ा अधिक जटिल प्रश्न है, और एक व्यक्ति के साक्षात्कार में इस तरह के प्रश्न की उम्मीद की जा सकती है। हालाँकि Google के साथ एक फ़ोन साक्षात्कार में मेरे मित्र को एक बार Google Code Jam world के फाइनल से एक प्रश्न पूछा गया था , इसलिए अधिकतम जटिलता के लिए वास्तव में कोई सीमा नहीं है, जो इस बात पर निर्भर करता है कि आपसे कौन पूछ रहा है।

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

4. चमकती वास्तु समस्याओं के अलावा जो बस सेवा में गिरावट का कारण बनती है, एक और बिंदु है। टीमें अक्सर अतिरिक्त कंप्यूटिंग संसाधनों का अनुरोध करके प्रदर्शन की समस्याओं को हल करती हैं। कुछ कंपनियां किसी तरह इससे निपटने की कोशिश कर रही हैं। मैंने सुना है कि फेसबुक पर, एक विशेष विभाग को दक्षता रिपोर्ट में सुधार करने पर काम करने वाली कई टीमों ने उन्हें क्षमता विस्तार के अनुरोधों को ब्लॉक करने की अनुमति दी है यदि वे एक टीम में अत्यधिक अक्षमता को नोटिस करते हैं जिसे वे ठीक करने से इनकार करते हैं। लेकिन व्यक्तिगत रूप से, मैं ऐसी कंपनियों के सामने नहीं आया। Google ने इस समस्या को एक प्रणाली के साथ हल करने की कोशिश की, जो अन्य बातों के अलावा, कंप्यूटिंग संसाधनों के साथ कर्मचारियों की संख्या को सहसंबद्ध करती है, लेकिन मैंने सुना है कि इसे अंततः किसी कारण से अधिक पारंपरिक प्रणाली के पक्ष में छोड़ दिया गया था। [वापस]