मुश्किल तर्क पहेलियाँ - क्या वे वास्तव में प्रोग्रामिंग कौशल का आकलन करने में उपयोगी हैं? [बन्द है]

Question

अंतिम साक्षात्कार में मैंने भाग लिया, मुझे एक पहेली को हल करने के लिए कहा गया था जहाँ मुझे उम्मीद थी कि क्रमशः क्षमताओं के साथ दो बाल्टी दिए गए पानी के बिलकुल लीटर - ब्लाह और ब्लाह लीटर को मापा जाएगा। मैं दिए गए समय में पहेली को हल करने में असमर्थ था (~ 5 मिनट)।

साक्षात्कारकर्ता थोड़ा निराश हुआ और कहा कि एक प्रोग्रामर को "ये" कौशल मिला है। मुझे वह कौशल नहीं मिला जिसके बारे में वह बात कर रहा था।

मैंने हमेशा इस तरह की पहेलियों के बारे में अजीब महसूस किया है जो आमतौर पर प्रोग्रामिंग नौकरी के साक्षात्कार में पूछे जाते हैं। मुझे समझ नहीं आ रहा है कि क्या होगा, अगर इस तरह की पहेलियाँ और प्रोग्रामिंग के बीच संबंध है। वास्तव में साक्षात्कारकर्ता ऐसी पहेलियों के साथ क्या आकलन करना चाहते हैं?

Comments

जैसा लगता है मरो हार्ड 3 गुड़ पहेली youtube.com/watch?v=lZ64IR2bz5o

— JF Dion

इस तरह के सवालों के साथ एक बड़ी समस्या यह है कि वे अक्सर मापते हैं कि क्या आवेदक ने उस समस्या को पहले देखा है, और "बहुत सारे तर्क पहेली देखा है" एक वास्तविक अच्छा भर्ती मानदंड नहीं है।

— डेविड थॉर्नले

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

— रीन हेनरिच

हां, ये परीक्षण उतना अच्छा नहीं है। लेकिन, यह अच्छा है जब एक प्रोग्रामर को इन पहेलियों में कम से कम दिलचस्पी है। मेरी सलाह: बस पहेलियों का अध्ययन करें, साक्षात्कार पास करें, और फिर तय करें कि क्या आप शामिल होना चाहते हैं।

— जॉब

मैं एक उम्मीदवार को खोजने के लिए उम्मीद में एक साक्षात्कार के दौरान यह पूछूंगा, जो पूछता है, "डब्ल्यूटीएफ को प्रोग्रामिंग के साथ क्या करना है?" और पार्किंग स्थल से बाहर निकलने से पहले उन्हें एक प्रस्ताव दें।

— जेफ

Answer 1

कुछ लोग समस्याओं को हल करने के लिए आपकी क्षमता और दृष्टिकोण को समझने के प्रयास में उनसे पूछते हैं। व्यक्तिगत रूप से, मुझे नहीं लगता कि ऐसी पहेलियाँ सटीक संकेतक प्रदान करती हैं। उदाहरण के लिए, "वास्तविक दुनिया" में, आपके पास एक बिन पैकिंग बनाम बैक पैक की समस्या से निपटने के लिए पांच मिनट से अधिक समय है । प्रारंभ में, कभी-कभी हाथ पर समस्या को गलत तरीके से समझना आसान होता है जब तक कि आप गलत समाधान को लागू करने के बीच में न हों। यह 1, 5, 10 या 20 साल के अनुभव वाले लोगों के साथ होता है।

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

क्या सभी महान प्रोग्रामर को भी चैंपियन सुडोकू सॉल्वर होना चाहिए? मुझे यकीन है कि बहुत सारे हैं, लेकिन यह योग्यता के लिए किसी तरह की शर्त की तरह नहीं है।

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

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

Comments

यह वह परिप्रेक्ष्य है जो सभी साक्षात्कारकर्ताओं के पास होना चाहिए। अपने डोमेन में एक समस्या को हल करें और तनाव और अप्रत्याशित प्रश्नों के बारे में आपकी टिप्पणी बराबर है!

— क्रिस

+1 के लिए "वास्तविक दुनिया" में, आपके पास यह पता लगाने के लिए पांच मिनट से अधिक है , अच्छा जवाब!

— चींटी का

इस तथ्य से भी प्यार करते हैं कि वे आमतौर पर प्रस्तुत किए जाते हैं जैसे कि साक्षात्कारकर्ता ने सवाल पैदा किया और इसे स्वयं हल किया :)

— RyBolt

मैं इतना मुश्किल पर lol'd excuse yourself to go to the restroom and never return!

— फ्लोरियन मार्गाइन

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

— विंकब्रेस

Answer 2

Microsoft ने इन प्रश्नों का उपयोग 1980 के दशक की शुरुआत में किया। जैसे-जैसे Microsoft उल्लेखनीय रूप से सफल होता गया, अन्य कंपनियों ने उन्हें कॉपी करना शुरू कर दिया, लेकिन कुछ प्रमुख बिंदु अनुवाद में खो गए।

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

ये सवाल कभी पास-फेल होने के लिए नहीं थे। वे एक बातचीत की शुरुआत के बारे में थे कि आप इस समस्या से कैसे निपटेंगे और आपने पहले कभी नहीं देखी गई समस्याओं के बारे में कैसे सोचा। "विफल" होने का एकमात्र निश्चित तरीका, समस्या को हल करने की कोशिश करने से इनकार करना था। उस समय यह एक उपन्यास रणनीति थी, और आप Google पर प्रश्नों को नहीं देख सकते थे।

संपादित करें:

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

वे अंततः परियोजना को पूरा करने के लिए पर्याप्त प्रोग्रामर की भर्ती करने में सफल रहे, लेकिन निष्कर्ष यह था कि स्क्रीनिंग के तरीकों में से कोई भी उन रिक्रूटर्स की पहचान करने के मौके से बेहतर नहीं था जो प्रोग्रामर के रूप में उल्लेखनीय रूप से सफल रहे।

Answer 3

क्या वे उपयोगी हैं? नहीं वास्तव में नहीं। वे एक बार Microsoft में इतने आम थे कि उन्हें "Microsoft प्रश्न" भी कहा जाता है, और उनके बारे में लिखी गई किताबें भी हैं, यह वास्तव में काफी अच्छा पढ़ा गया है ..

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

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

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

Answer 4

आप किताब पढ़ना चाहेंगे कि आप माउंट फ़ूजी को कैसे स्थानांतरित करेंगे? । यह तर्क में जाता है कि बहुत से लोग साक्षात्कार में पहेलियों का उपयोग करते हैं, और मेरी राय यह है कि यह कार्गो पंथ व्यवहार का एक संयोजन है ( "Microsoft यह करता है, और अगर हम चाहते हैं कि वे जितने सफल हों, तो हम बेहतर करें कि वे क्या करें do " ) और बिरादरी का चक्कर ( " गोश द्वारा!, मुझे उन सवालों का जवाब देना था और आप बेहतर मानते हैं कि अगले आदमी को उनका जवाब देना होगा! " )।

एक साक्षात्कार अभ्यास के रूप में इन सवालों के इतिहास की शुरुआत 1950 के दशक में विलियम शॉकले के साथ हुई थी। वे एक आम तौर पर सामान्य सिलिकॉन वैली के साक्षात्कार प्रश्न थे जो साक्षात्कारकर्ताओं ने पूछा क्योंकि अन्य साक्षात्कारकर्ता यह कर रहे थे (और शायद उन्हें कुछ पता था जो इस साक्षात्कारकर्ता को नहीं पता था?)। शॉक्ले ने उन्हें एक बुद्धि परीक्षण के रूप में इरादा किया था, और 2 बाल्टी के साथ सवाल 1916 में मूल स्टैनफोर्ड बिनेट आईक्यू टेस्ट में से एक पर था ।

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

व्यक्तिगत रूप से, मेरे पास इन प्रकार के प्रश्नों के बारे में कम राय है क्योंकि वे आमतौर पर साक्षात्कारकर्ताओं द्वारा उपयोग किए जाते हैं जो नहीं जानते कि वे क्या कर रहे हैं, न ही डेवलपर्स के लिए कैसे देखें। जब तक आप एक ऐसी कंपनी के लिए काम करने जा रहे हैं जो पहेली / पहेलियां बनाती है, वे इतिहास के साथ-साथ "आपकी सबसे बड़ी कमजोरी क्या है" के साथ हैं मैनहोल कवर राउंड हैं "(उनमें से सभी नहीं हैं)।

Comments

+1, अंतिम पैराग्राफ के साथ अधिक सहमत नहीं हो सकता है!

— लापताफैक्टर

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

— पूल

Answer 5

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

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

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

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

1. आपकी प्रोग्रामिंग भाषा प्राथमिकताएँ कौन सी हैं? क्यों?
2. अपवाद से निपटने के लिए कैसे दृष्टिकोण?
3. क्या स्तरित डिजाइन के लाभ एक मिथक नहीं हैं?
4. क्या निरंतर एकीकरण दक्षता के लिए बोझ नहीं है?
5. किसके कोड का एक टुकड़ा लिखा है, यह अधिकार चाहिए?
6. आप "प्रवाह" में आने के लिए क्या करते हैं।
7. रिपोर्ट दोषों को एक परियोजना योजना में कैसे शामिल किया जाना चाहिए?
8. ...

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

प्रभावी सॉफ्टवेयर विकास के बारे में अधिक वैज्ञानिक अध्ययन चूंकि पीपुलवेयर कहते हैं कि सबसे अच्छा प्रोग्रामर वे हैं जो सॉफ्टवेयर विकास की गतिशीलता को समझते हैं, भले ही उनके पास उच्चतम आईक्यू न हो। मैं बल्कि एक बदमाश को ले जाऊंगा, जो nवर्षों के अनुभव के साथ किसी को सीखने के लिए उत्सुक है जो 1बार- nबार अनुभव के वर्ष को उबालता है। मेरा व्यक्तिगत पूर्वाग्रह उन उम्मीदवारों के प्रति है जो बॉक्स के बाहर सोचने की प्रवृत्ति रखते हैं, और साथ ही साथ यह भी जानते हैं कि वर्तमान (मेरे) बॉक्स में कैसे फिट होना है।

Comments

बहुत बढ़िया जवाब। ऑफटॉपिक: आपका उदाहरण प्रश्न # 3 मुझे उत्सुक बनाता है। मैं स्तरित डिजाइन के बारे में आपकी राय जानने में दिलचस्पी रखता हूं।

— लापताफोरटोर

@missingfaktor # 3, जैसा कि कहा गया है, एक ट्रिक सवाल है जो जल्दी से की गई चीजों के बारे में बातचीत को स्पार्क करने के लिए है। # 4 और # 5 समान हैं। # 7 शायद सबसे कठिन है, और केवल नेतृत्व भूमिकाओं के लिए उपयुक्त है।

— अपाला

@missingfaktor I ने फिर से एक अलग सवाल का जवाब दिया। यह विकिपीडिया लेख, संबंधित लोग, और बाहरी लिंक इस बारे में जानकारी प्रदान करते हैं कि चिंताओं को अलग करना जटिल प्रणाली के डिजाइन और निर्माण के लिए सर्वोपरि है: en.wikipedia.org/wiki/Modularity

— Apalala

समझ में आता है। आपका बहुत बहुत धन्यवाद! :-) फिर, उत्कृष्ट जवाब। कई अच्छे बिंदुओं का उल्लेख यहां अन्य उत्तरों में नहीं किया गया है।

— 14 दिसंबर

व्यक्तिगत रूप से मैं टूलींग के बारे में एक सवाल भी जोड़ूंगा। जो लोग अपने द्वारा उपयोग किए जाने वाले उपकरणों की परवाह करते हैं, वे बेहतर प्रोग्रामर बनते हैं। एक Emacs उपयोगकर्ता के रूप में, मैं बहुत से किसी को एक विम उपयोगकर्ता पसंद करता हूं जो सिर्फ अपने कंधों को सिकोड़ता है और परवाह नहीं करता है।

— सिंगलटन

Answer 6

वे समस्या निवारण कौशल का आकलन करने में उपयोगी हो सकते हैं , जो निश्चित रूप से प्रोग्रामिंग के प्रमुख पहलुओं में से एक है।

वर्षों से कई लोगों के साक्षात्कारकर्ता के रूप में, मैं आमतौर पर गेटे प्रकार के प्रश्न नहीं पूछता हूं जैसे कि आप वर्णन करते हैं, लेकिन मैं अच्छी तरह से कुछ पूछ सकता हूं और पूछ सकता हूं "आप कैसे हल करेंगे ..."।

उस मामले में मेरी अपेक्षाएँ यह हैं कि आप समस्या के बारे में अपना दृष्टिकोण स्पष्ट करें। आप कौन से अन्य डेटा को इकट्ठा करने की कोशिश करेंगे? आप अपनी परिकल्पना का परीक्षण कैसे करेंगे आदि।

Comments

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

— डेव वाइज

@ दे दो, मुझे आजमाओ। जब मैं ऐसी पहेलियों को हल करता हूं, तो मैं आमतौर पर कागज का एक टुकड़ा, रेखांकन, या टेबल, या क्रॉस-आउट आंकड़े लेता हूं जो अभिनेताओं का प्रतिनिधित्व करते हैं, या संख्याएं लिखते हैं जो किसी तरह मेरे दिमाग में समस्या को हल करने की प्रक्रिया से संबंधित हैं; मैं यह सब पूरी चुप्पी में करता हूं कभी-कभी अप्रभेद्य बड़बड़ाहट से टूट जाता है। तो, क्या मैं एक अच्छा प्रोग्रामर हूं?

— पी शेव्ड

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

— जेसन

कुछ लोगों का मानना ​​है कि सिर्फ इसलिए कि वे एक बहिर्मुखी हैं कि हर किसी को बहिर्मुखी होना चाहिए। मेरी वर्तमान टीम इंट्रोवर्ट्स का एक समूह है और यह अब तक की सबसे अच्छी टीम है जिसके साथ काम करने का मेरा आनंद है।

— डंक

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

— डंक

Answer 7

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

Answer 8

यह पुरानी-खोपड़ी का तर्क है कि आपके पास बुनियादी तर्क कौशल होना चाहिए; और कुछ भी सिखाया जा सकता है। लेकिन यह पूरी तरह सच नहीं है। बूलियन तर्क , स्थिति और लूप पढ़ना , तर्क पहेली को हल करने में सक्षम होने के समान नहीं है ।

यह कहा, प्रक्रियात्मक भाषाओं के दिनों में, यह शायद सच था कि जो कोई इन समस्याओं को हल कर सकता है, उसके पास उच्च प्रवृत्ति होगी जो स्विच के संदर्भ में किसी भी समस्या को लागू करने में सक्षम होगा। लेकिन मेरे दिमाग में, OO / फंक्शनल प्रोग्रामिंग के लिए एक इंजीनियरिंग मानसिकता की आवश्यकता होती है, जो काफी अलग होती है (हालांकि विरोधाभासी नहीं)।

व्यक्तिगत रूप से, मुझे यकीन नहीं है कि मैं एक ऐसी कंपनी के साथ नौकरी करना चाहता हूं जिसने अभी भी सोचा था कि व्यावहारिक प्रोग्रामिंग कौशल की तुलना में तर्क अधिक महत्वपूर्ण था।

डिस्क्लेमर: मैं लॉजिक पज़ल्स में बहुत अच्छा हूँ और शायद इस तर्क के बिना काम की लाइन में मेरी शुरुआत नहीं हुई है।

Answer 9

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

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

Answer 10

प्रोग्रामिंग कोड की पंक्तियों को लिखने के बारे में नहीं है, यह अन्य लोगों (ग्राहक, उपयोगकर्ता, आदि) के लिए और से समस्याओं को हल करने के बारे में है।

ऐसा होता है कि प्रोग्रामर के लिए समाधान एक कार्यक्रम का रूप लेता है।

इसलिए यह समस्या को हल करने की क्षमता होना महत्वपूर्ण है और इसका परीक्षण क्यों किया जाता है।

कहा जा रहा है, मुझे यकीन नहीं है कि मुश्किल पहेली को हल करना किसी का आकलन करने का सबसे अच्छा तरीका है।

Answer 11

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

मैं "लॉजिकल पज़ल्स" के साथ ठीक हूं क्योंकि उनके पास एक या शायद दो सॉल्यूशंस हैं और वे सीधे लॉजिक द्वारा आ सकते हैं। और मेरा मानना ​​है कि तार्किक पहेलियाँ एक हद तक अच्छी हैं क्योंकि उन्हें हल करने के लिए आवश्यक प्रक्रिया बहुत ज्यादा है जिस तरह से एक कोडर को वास्तविक जीवन में सोचने की जरूरत है।

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

जब मैं साक्षात्कार लेता हूं तो मैं तार्किक पहेलियाँ नहीं पूछता। कारण: अधिकांश उम्मीदवार जिनके पास 3-4 साल का अनुभव है, वे असफल हो जाते हैं या छोड़ देते हैं, जब मैं उन्हें साधारण पाठ्यपुस्तक की समस्याओं जैसे कि फाइबोनैचि श्रृंखला या पैलिंड्रोम्स को कोड करने के लिए कहता हूं।

पहेली के साथ समस्या यह है कि किसी भी तरह से अच्छे-अच्छे प्रोग्रामर को यह पता नहीं होता है कि नेट पर ऐसी सामान्य पहेलियों के समाधान को देखकर वे साक्षात्कारकर्ताओं को प्रभावित कर सकते हैं। बहुत कम लोग यह बताने के लिए पर्याप्त होंगे कि वे पहले से ही इसका समाधान जानते हैं।

Comments

Palindromes द्वारा, क्या आप रेखीय समय में एक इनपुट स्ट्रिंग में सबसे लंबे समय तक palindrome सबस्ट्रिंग खोजने की बहुत कठिन समस्या का मतलब है? :-)

— b_jonas

Answer 12

दो बिंदु:

1. प्रोग्रामिंग मुख्य रूप से पहेली को सुलझाने से अलग है। यह स्टीव मैकोनेल द्वारा "कोड कम्प्लीट" में स्पष्ट रूप से समझाया गया है:

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

2. ऐसी पहेलियाँ साक्षात्कार के दौरान उपयोगी हो सकती हैं, लेकिन केवल अगर साक्षात्कारकर्ता प्रक्रिया को देखता है , तो परिणाम ही नहीं।

लेकिन आदर्श रूप से पहेलियाँ अधिक जटिल और प्रोग्रामिंग से संबंधित (जैसे छोटे 2-घंटे की परियोजना) होनी चाहिए, मेरी राय में। बात यह है कि साक्षात्कारकर्ता लोग हैं और सही "साक्षात्कार कौशल" नहीं है।

Comments

अगर आप -1 वोट देते हैं तो क्या आप कह सकते हैं कि मेरे जवाब में क्या गलत है?

— klm123

+1, क्योंकि यह एक अच्छा उत्तर है। मैं इसे अन्यथा भी अपवित्र कर देता, बस एक अस्पष्ट उतार को रद्द कर देता।

— 19-11 को लापता

Answer 13

ऐसी समस्याओं की जांच करने के लिए कुछ अलग तरीके हैं:

1. पिछले उपाय को जानकर। फिल्म में ... डाई हार्ड विद अ वेंगेंस ... मुझे यह समझाएं ...? उस मामले के लिए एक समाधान जानने का एक उदाहरण है जहां ब्लाह क्रमशः 4,3 और 5 हैं। कुछ लोग अपने पिछले समाधान के आंतरिक ज्ञान को जल्दी से टैप करने में सक्षम होंगे और यदि आवश्यक हो तो इसे अनुकूलित कर सकते हैं। यह आमतौर पर मुझे लगता है कि एक साक्षात्कारकर्ता उम्मीद करेगा कि एक अच्छा विचार हो सकता है या नहीं।

2. रचनात्मक कामचलाऊ कौशल। यह मामला होगा यदि आप पिछले समाधान को नहीं जानते हैं या समस्या को पहचानते हुए भी कुछ ऐसा कर रहे हैं जो कि एक डायोफैंटीन समीकरण के रूप में मॉडल कर सकता है। इस प्रकार सवाल यह है कि आप कितनी जल्दी उपयोग कर सकते हैं और जो दिया गया है उसे रचनात्मक तरीके से समस्या का हल ढूंढने के साथ-साथ यह बताएं कि आपके पास समस्या का एक वैध समाधान क्यों है।

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

Answer 14

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

OTOH, मुझे लगता है कि प्रोग्रामिंग समस्याएं अधिक उपयोगी हैं।

Answer 15

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

इसलिए संभावित नियोक्ता को आपके भविष्य के प्रदर्शन पर अनुमान लगाना चाहिए।

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

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

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

Comments

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

— कार्सन63000

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

— 8steve8

मुझे लगता है कि आप बाल्टी समस्या के बीच सादृश्य देख सकते हैं और कहते हैं, डिस्क संख्या, या HTTP अनुरोधों की एक न्यूनतम संख्या का उपयोग करते हुए किसी कार्य को पूरा करने के लिए सॉफ्टवेयर लिखना।

— 8steve8