क्या ओवर-इंजीनियरिंग एक चेतावनी संकेत है? [बन्द है]


22

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

अब मेरा प्रश्न यह है कि क्या यह चेतावनी संकेत है?

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

IMHO, जब मैं साक्षात्कार कर रहा था तो यह सबसे पूर्ण अभ्यास था जो मुझे आया था।

जिस विशिष्ट परिदृश्य के बारे में मैं विचार कर रहा हूँ, वह वह जगह है जहाँ एक उम्मीदवार ने फ़ाइल से पढ़ने के बजाय, बहु-थ्रेडेड अनुप्रयोग में "नेटवर्क" इनपुट को स्वीकार किया, जो स्पष्ट रूप से दायरे में नहीं है।


43
क्या आप व्यायाम का एक उदाहरण शामिल कर सकते हैं। समस्या चुनौती में हो सकती है और उम्मीदवार को नहीं।
रिएक्टगुलर

13
क्या आप सुनिश्चित हैं कि अभ्यर्थी अभ्यास में प्रस्तुत समस्या को समझ गए हैं? सीधे-सीधे व्यायाम करने वाले व्यक्ति के पास प्रदर्शन करने के लिए हमेशा तनाव में सीधे उम्मीदवार के बराबर नहीं होता है।
cdkMoose सेप

23
क्या यह तथ्य नहीं है कि आपने इसे "अतिरंजना" कहा है जो उत्तर को स्पष्ट करने के लिए है? यह पूछने की तरह है कि "क्या एक अतिविशिष्ट उम्मीदवार एक चेतावनी संकेत है"? यकीन है, जब तक कि वह सिर्फ आश्वस्त नहीं है, लेकिन आपने पहले ही अपने निष्कर्ष को प्रश्न के आधार में डाल दिया है।
Psr

3
@ मैथ्यू फोसकारिनी हमेशा नकारात्मक नहीं है? इसका मतलब है कि व्यक्ति गलत चीजों पर ध्यान केंद्रित करता है, और एक ऐसा समाधान लागू करता है जो अनावश्यक रूप से जटिल, समय लेने वाला या समझने और बनाए रखने में कठिन हो। इसे दोष के रूप में कैसे नहीं माना जा सकता है?
एंड्रेस एफ।

2
@AndresF। यह एक साक्षात्कार है। ओवर इंजीनियरिंग ने एक साक्षात्कार में एक सवाल का जवाब दिया, जिसमें अधिकांश साक्षात्कार केवल एक घंटे तक चले। एक उपलब्धि हो सकती है। हां, कुछ को सॉर्ट करने के लिए कोड की 1,000 लाइनें लिखना इंजीनियरिंग से अधिक है, लेकिन उन्होंने एक घंटे से भी कम समय में कोड की 1,000 लाइनें लिखीं! यदि ओवर इंजीनियरिंग एक ऐसा मुद्दा है जिसे साक्षात्कार प्रक्रिया में फ़िल्टर करने की आवश्यकता है। डिजाइन गुंजाइश और जटिलता से संबंधित एक अधिक विशिष्ट परीक्षण होना चाहिए। मैं व्यक्ति को हल करने के लिए एक सॉफ्टवेयर आर्किटेक्चर चुनौती देना चाहूंगा। उदाहरण के लिए; "सेल्फ-ड्राइविंग कार सिस्टम के लिए एक यूएमएल आरेख बनाएं"।
रिएक्टगुलर

जवाबों:


48

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

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


5
जहाँ सवाल में यह "जटिल उद्यम स्तर सॉफ्टवेयर" कहते हैं?
रिएक्टगुलर

12
@ नी - मुझे लगता है कि कार्ल की बात यह है कि आप ओवरगेंरिंग पर विचार करते हैं, अन्य साक्षात्कारकर्ता ओओडी के साक्षात्कारकर्ता की समझ का अच्छा प्रतिनिधित्व मान सकते हैं। छद्म कोड का संदर्भ उतना स्पष्ट नहीं हो सकता है जितना आप उस दृष्टिकोण के प्रकार का वर्णन करने में सोचते हैं जो आप अपेक्षा करते हैं।
माइक पार्ट्रीज

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

5
@KarlBielefeldt: हाँ, कभी-कभी लोग ऐसे प्रश्नों में चीजों को पढ़ते हैं जो स्पष्ट रूप से नहीं बताए जाते हैं - उदाहरण के लिए, PSE;?;
Doc Brown

3
व्यायाम के अंत में एक वाक्य जोड़ने के सरल समाधान के बारे में क्या कहेंगे "जितना संभव हो उतना कम कोड में वर्णन करें" या उन शब्दों में कुछ
user60812

30

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

उम्मीदवारों को होने वाली दो अलग समस्याएं हैं:

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

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

इसके अलावा, समस्या को स्वयं हल करें और देखें कि क्या यह अस्पष्ट है और शायद लोगों को गलत रास्ते पर लाने के लिए क्योंकि वे अपने उत्तर तैयार करते हैं।


23

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

यहाँ कुछ चीजें हैं, मेरे सिर के ऊपर से, कि शायद आपकी आवश्यकताओं का उल्लेख नहीं किया गया है:

  • कोडिंग मानकों

  • टिप्पणियाँ

  • उपवाद सम्भालना

  • चरों, वर्गों, विधियों के वर्णनात्मक नाम

  • भाषा के मुहावरेदार उपयोग के बाद

  • उचित वस्तु उन्मुख डिजाइन

  • संभव समसामयिक मुद्दों पर ध्यान दें

  • कोड के लिए परीक्षण मामलों को लिखना

क्या आपने स्पष्ट रूप से बताए बिना इनमें से किसी एक चीज़ पर ध्यान दिया? उम्मीदवार को कैसे पता चलेगा कि आप किन लोगों की परवाह करते हैं, और जो आप नहीं करते हैं?

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

आम तौर पर, उस अनुमान पर गलती करना वास्तविक दुनिया के डिजाइन निर्णयों पर गलती करने की तुलना में बहुत अलग है। यदि आप यह जानना चाहते हैं कि क्या कोई अति-अभियंता चीजें आपको संभवतः एक बहुत ही कृत्रिम कोडिंग अभ्यास को देखने के बजाय डिजाइन के बारे में बात करनी है।


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

1
@ शॉनविलसन: यह बहुत निर्भर करता है। मुझे लगता है कि बड़ी कंपनियों को यह देखने में दिलचस्पी हो सकती है कि आप स्पष्ट चश्मे के साथ क्या कर सकते हैं। छोटी टीमों में, लोग एक-दूसरे की क्षमताओं पर निर्भर करते हैं, सहानुभूति व्यक्त करते हैं, अतिरिक्त रूप से पढ़ते हैं, पंक्तियों के बीच पढ़ते हैं और समस्या का पता लगाते हैं।
back2dos

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

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

@jwenting, मैं आपको विश्वास दिलाता हूं, हम ऐसा कोई काम नहीं करते हैं, यह सिर्फ कम आंका गया है। यदि हम आगे बढ़ते हैं, तो हम f2f साक्षात्कार में, बात करेंगे कि वे कोने के मामलों को जोड़ने के लिए कैसे विस्तार कर सकते हैं, लेकिन केवल अगर उम्मीदवार इसे लाते हैं।
निम

12

IMHO का उत्तर स्पष्ट रूप से हाँ है , यह एक चेतावनी संकेत है, यदि

  • कोडिंग अभ्यास का एक स्पष्ट कार्य था
  • अच्छी तरह से परिभाषित किया गया है (ans भी अच्छी तरह से लिखा है) आवश्यकताओं,
  • उम्मीदवारों को यह सुनिश्चित करने के लिए प्रश्न पूछने का मौका था कि वे सही समस्या को हल करें।
  • आप ऐसे लोगों को चाहते हैं जो स्मार्ट हों और आपकी टीम में काम आए , न कि आर्किटेक्चर अंतरिक्ष यात्री

1
इंटरैक्टिव तत्व के लिए +1। कई मामलों में विनिर्देश अस्पष्ट, अधूरे होते हैं, या इनमें शब्दावली होती है जो डोमेन विशिष्ट होती है। किसी भी मुद्दे को स्पष्ट करने के अवसर के बिना उम्मीदवार को दोष देना अनुचित हो सकता है।
HABO

1
इस तथ्य के लिए +1 कि आपका उत्तर पूरी तरह से प्रक्रिया को मॉडल करता है। आपने स्पष्ट रूप से ओपी द्वारा पूछे गए प्रश्न का उत्तर दिया।
dcaswell

1
+1, यह मेरी वर्तमान विचार प्रक्रिया है, मुझे लगता है कि यह देखने के लिए अच्छा है कि यह भोला या सादा गूंगा नहीं है ... दो जोएल लिंक के लिए धन्यवाद ...
निम

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

1
@MarjanVenema: मुझे संदेह है कि हारून का मतलब जोल स्पोल्स्की के समान शब्द में था, जिसने इस शब्द को बनाया था। और ईमानदारी से, मुझे नहीं लगता कि मैं किसी को भी "अपमानित" करता हूं - यदि आप चाहते हैं कि आपकी टीम बनाने में देवता अच्छी तरह से, दूरदर्शी समाधान कहते हैं, तो उन्हें किराए पर लेने के लिए स्वतंत्र महसूस करें।
डॉक ब्राउन

5

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

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

यह मानते हुए कि कोडिंग अभ्यास बुरी तरह से गड़बड़ नहीं है, ऐसा प्रतीत होता है कि जिस तरह से वह असफल हो गया वह समस्या का गलत अर्थ निकाल रहा था और एक समस्या को हल करने की कोशिश कर रहा मातम में जा रहा था। हां, यह एक चेतावनी संकेत है।


3

शायद।

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

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

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

बाकी सब कुछ है कि ग्रे मध्य मैदान। क्या समाधान पते में परिवर्तन की कुल्हाड़ियों की संभावना है? क्या समाधान जटिलता या नुकसान की स्थिरता को जोड़ता है? भविष्य की समस्याओं को हल करने के लिए थोड़ी जटिलता जोड़ना जो लगभग एक जीत की गारंटी है। पूरी तरह से संभावना नहीं है कि कुछ के लिए खाते में हानि बनाए रखने बहुत।

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


2
यदि समस्या को समझना कठिन है, या अच्छी तरह से संप्रेषित नहीं किया गया है, तो उनके लिए यह महत्वपूर्ण समय है कि वे महत्वपूर्ण कौशल को उदारवादी प्रोग्रामर को अच्छे से प्रदर्शित करें - समस्या को परिभाषित करना।
एडम डेविस

सवाल यह नहीं कहता कि उम्मीदवार ने सवाल पूछने के मौके का फायदा नहीं उठाया।
dcaswell

3

हो सकता है लेकिन निम्नलिखित पर विचार करें:

  • साक्षात्कार कठिन हैं: लोग तनाव में हैं। यह किसी भी समस्या में आपको किसी को देनी चाहिए

  • आवश्यकता की लंबाई: कब तक और सीधे आगे की आवश्यकताएं हैं? क्या आपने उन्हें यह सुनिश्चित करने के लिए अतिरिक्त चीर-फाड़ की कि आपने सब कुछ शामिल किया है। नतीजतन, वे आप के लिए स्पष्ट हो सकता है लेकिन आवश्यकताओं को इंजीनियर हो सकता है! मैंने एक घंटे की समस्या के लिए एक बार एक नौकरी के लिए साक्षात्कार लिया, जिसमें एक समस्या के लिए पाठ के लगभग 3 पृष्ठ थे जो अपेक्षाकृत सरल थे। कभी-कभी वह सभी पाठ एक साक्षात्कार पर पढ़ने और व्याख्या करने के लिए कठिन हो सकता है और साथ ही गलत व्याख्या की जा सकती है।

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

  • कम्यूनिकेशन स्किल: आपको पहले उम्मीदवारों से संवाद करने और समस्या के बारे में बुद्धिमान प्रश्न पूछने की क्षमता का परीक्षण करना चाहिए और जब आप जानते हैं कि उन्होंने प्रदर्शित किया है कि वे समस्या को समझते हैं तो आप उन्हें उनके कार्यान्वयन पर निर्धारित कर सकते हैं।

  • नीचे पंक्ति: यदि आपने जांच नहीं की है कि समस्या को समझा गया है तो आप वास्तव में नहीं जानते कि ओवर इंजीनियरिंग का क्या बनाना है। जैसा कि अन्य लोगों ने कहा है कि यह एक अच्छी या बुरी बात हो सकती है, लेकिन अगर आपने सामने वाले की समस्या के बारे में उम्मीदवार के साथ समझ या संवाद की जाँच नहीं की है, तो समस्या की उनकी सामान्य समझ और इसे बनाने के बारे में जानना कठिन है।


1
ठोस उत्तर, लेकिन पाठ की दीवार के माध्यम से मिटाना कठिन है। अपने उत्तर को संपादित करने और प्रमुख वर्गों को तोड़ने पर विचार करें

2

इस बात के लिए बहुत कुछ जिम्मेदार ठहराया जा सकता है कि आप प्रश्न को कैसे कहते हैं और आपने पूरे साक्षात्कार को कैसे परिप्रेक्ष्य में रखा है।

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

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

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


"2 + 2 क्या है?" 4 बनाम "आइए देखें कि आप कितने रचनात्मक हैं। 2 + 2 क्या है?" अनुक्रम की सीमा 3.9, 3.99, 3.999, 3.9999, ...
एमोरी

"आइए देखें कि आप कितने रचनात्मक हैं? 2 + 2 क्या है?" 5, पर्याप्त रूप से बड़े मानों के लिए 2.
माइकल

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

2

यह निर्भर करता है, लेकिन आम तौर पर नहीं।

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

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

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

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

भी: आप किस स्तर की स्थिति के लिए काम पर रख रहे हैं? एंट्री या इंटरमीडिएट स्तर के उम्मीदवार में से ओवर-इंजीनियरिंग एक वरिष्ठ स्तर के उम्मीदवार के मुकाबले ओवर-इंजीनियरिंग से कम नहीं है।


1

यदि प्रोग्रामर ने समस्या को हल नहीं किया है, तो सभी अतिरिक्त कोड कोडर के गैर-उत्तर को बाधित करने का प्रयास है। यह उसी तकनीक का उपयोग करता है जो एक छात्र द्वारा निबंध परीक्षण पर किया जाता है जो विषय के बारे में ज्यादा नहीं जानता है। वह या वह एक सम्मोहक के बारे में घिसटना होगा, लेकिन आशा में असंबंधित मुद्दा उसकी अज्ञानता शब्द गणना द्वारा नकाबपोश है।

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.