एक साक्षात्कार में, एक कठिन प्रश्न के लिए ब्रूट-फोर्स समाधान को कोड करना बेहतर है, या प्रश्न की जांच करने वाले साक्षात्कार को सावधानीपूर्वक खर्च करना है? [बन्द है]


14

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

उदाहरण के लिए, प्रॉजेक्ट ईयूलर में प्रॉब्लम 91 को हर संभावित त्रिकोण की गणना करने के लिए एक बहुत मुश्किल जानवर-बल समाधान द्वारा हल किया जा सकता है, एक आइसट्राइटंगल () टेस्ट लिख रहा है, और एक सेट में टेस्ट पास करने वाले सभी त्रिकोणों को पॉप कर रहा है। लेकिन X / Y निर्देशांक की दो जोड़ी उच्च स्थिर मान के साथ एक O (x ^ 4) समाधान बनाती है। एक मित्र और मैं अभी एक समाधान लेकर आए हैं जो बहुत अधिक सुरुचिपूर्ण और कुशल है, लेकिन हम दोनों ने इस पर 3 घंटे बिताए और दर्जनों आरेखों को आकर्षित किया, कई सूत्रों का परीक्षण किया, कई दृष्टिकोणों की जांच की, आदि।

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


10
उनसे पूछें कि क्या वे एक जानवर-बल समाधान चाहते हैं, या एक बारीक।
रॉबर्ट हार्वे

अगर वे एक नॉन ब्रूट फोर्स सॉल्यूशन चाहते थे, तो उन्होंने एक सवाल दिया होगा, जिसे ब्रूट फोर्स द्वारा हल नहीं किया जा सकता है।
माइनसवेन

जवाबों:


9

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

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

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

आंशिक रूप से, ऐसा इसलिए है क्योंकि वास्तविक दुनिया में आने वाले बहुत से प्रोजेक्ट यूलर प्रकार की समस्याएं एक-शॉट की समस्याएं हैं जिन्हें आपको एक बार हल करने की आवश्यकता है, फिर इसके बारे में भूल जाएं। मैं यह जानना चाहता हूं कि मैं जिस व्यक्ति को किराए पर लेता हूं, वह एक क्रूर बल एल्गोरिथ्म को पहचानने में सक्षम होगा जो लिखने में 2 मिनट लेता है और चलाने के लिए 10 मिनट एक एल्गोरिथ्म से अधिक कुशल है जो लिखने में 3 घंटे लगते हैं और चलाने में 10 सेकंड लगते हैं, यदि आपको केवल आवश्यकता है इसे चलाने के लिए कि एक बार।


बहुत बढ़िया जवाब। Caleb ने brute-force-first-then-ऑप्टिमाइजेशन कॉन्सेप्ट को लाया, लेकिन आपका एकमात्र जवाब है जो इस बात का कारण बताता है कि इस मामले में brute-force सोल्यूशन स्वीकार्य है, "यह केवल 6 मिलियन पुनरावृत्तियों है, जो नहीं लेगा बहुत लम्बा।" वह सिर्फ सोना है। बहुत बहुत धन्यवाद!
ग्लेनपेटर्सन

14

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

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

"क्या कोई नियम है जैसे 20 मिनट के बाद आपको बस कोडिंग शुरू करनी चाहिए चाहे कोई भी हो?" मैं यह कहकर उत्तर दूंगा कि समस्या के बारे में सोचने के बहुत कम समय के भीतर, आपको कम से कम कुछ करना चाहिए - अधिक प्रश्न पूछना, समाधान के लिए एक रूपरेखा तैयार करना, या यह कहना कि आप ऐसा नहीं कर सकते / पता नहीं कहाँ से शुरू करें।

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


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

धन्यवाद। यह व्यावहारिक है। मेरी नौकरी में मेरी प्रवृत्ति कीबोर्ड को छूने से पहले विश्लेषण करना है। लेकिन एक साक्षात्कार के दबाव में, मैं एक समाधान प्रोग्रामर को दिखाने के लिए पूरी तरह से चाहता हूं ।stackexchange.com/questions/ 178075/… आपका उत्तर याद रखने के लिए एक अच्छा काउंटर-उदाहरण प्रदान करता है।
ग्लेनपेटर्सन

4

मैं दोनों चाहता हूँ, लेकिन वे एक समाधान में "काम करता है" कोड प्रदर्शित कर सकते हैं और फिर संभवतः उस एक या किसी अन्य समस्या में सुधार के लिए संभावित समाधान पर चर्चा करेंगे।

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

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

किसी को पर्याप्त कोड लिखने और उसके बारे में चर्चा करते हुए देखें और यदि वे नौकरी के लिए सही हैं तो आप इसका पता लगा सकते हैं।


1
मुझे लगता है कि मैं यह भी सुनना चाहूंगा कि ब्रूट बल समाधान एक समस्या क्यों हो सकता है, जैसा कि ऊपर दिए गए प्रश्न में है।
क्रिस्टोफर क्रेतुजिग

@ChristopherCreutzig - मैंने माना कि मौजूदा समाधान के साथ समस्याओं को कम से कम सुझाव के बिना सुधार की पेशकश करना मुश्किल होगा।
जेएफओ

सच। मुझे लगता है कि मैं इसे खरोंच दूँगा।
क्रिस्टोफर क्रेतुजिग

3

क्या कोई नियम है जैसे 20 मिनट के बाद आपको बस कोडिंग शुरू करनी चाहिए चाहे कोई भी हो?

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

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

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

इसलिए, हम स्पष्ट रूप से isRightTriangle(p1, p2, p3)फ़ंक्शन को चार forलूपों के बीच में रख सकते हैं और प्रत्येक दो चर बिंदुओं के लिए सभी संभावित विकल्पों पर पुनरावृति कर सकते हैं। आइए देखें ... समस्या 50x50 ग्रिड पर मूल सहित सही त्रिकोणों की संख्या के लिए पूछती है, इसलिए ब्रूट बल विधि का उपयोग करके हमें प्रत्येक बिंदु के प्रत्येक समन्वय के लिए 50 संभावनाएं जांचनी पड़ती हैं। यह 50 ^ 4 चेक है ... मुझे यकीन है कि हम बेहतर कर सकते हैं, लेकिन कोड स्पष्ट है, इसलिए मुझे यह लिखना चाहिए ...

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

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

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


1
बहुत अच्छा जवाब। मुझे विशेष रूप से पसंद है, "मुझे यकीन है कि हम बेहतर कर सकते हैं, लेकिन कोड स्पष्ट है, इसलिए मुझे यह लिखने दें ..."
ग्लेनपेटर्सन

3

एक प्रबंधक के रूप में, अगर मैं आपको एक परीक्षा के रूप में कोड करने के लिए कहता हूं, तो मुझे इसमें सबसे ज्यादा दिलचस्पी है:

  • चाहे आप कोड लिख सकते हैं
  • आपकी कोडिंग शैली
  • आपके द्वारा चयनित एल्गोरिदम
  • क्या प्रयास इंगित करता है कि आपने समस्या को समझ लिया है
  • यदि मैं एक विशिष्ट तकनीक के बारे में वास्तव में गर्म हूं, तो क्या आपने प्रदर्शित किया है कि आप इसे कम या ज्यादा जानते हैं।

पहला आइटम पागल लग सकता है, लेकिन आपको आश्चर्य होगा ...

कोडिंग शैली - इसका मतलब यह नहीं है कि आप अपने ब्रेसिज़ को कहाँ रखते हैं, लेकिन चीजें जैसे:

  • क्या आपने उस समस्या को हल करने के लिए रचना या विरासत को चुना? क्यों?
  • उस मूल्य के लिए, आपने एक एनम बनाम एक स्ट्रिंग बनाम एक इंट (या जो भी क्रमपरिवर्तन लागू होता है) का उपयोग करने का विकल्प क्यों चुना
  • क्या आपने उस मान के लिए गुण, फ़ील्ड या प्राप्त / सेट विधियाँ उपयोग की हैं? क्यों?
  • आपने अपनी कक्षाओं में राज्य कैसे संभाला?
  • क्या आप समझते हैं कि विरासत, इंटरफेस और लैम्ब्डा कैसे काम करते हैं?
  • क्या आप भाषा के पैरामीटर सम्मेलनों को समझते हैं (रेफरी बनाम मूल्य के आधार पर क्या है?)
  • क्या आप जानते हैं कि यूनिट टेस्ट कैसे लिखें?

यहाँ मैं क्या वास्तव में परवाह नहीं है:

  • यह संकलित करता है (यह मानते हुए कि मैंने आपको सिर्फ नोटपैड और कोई संकलक नहीं दिया है)
  • कि आप स्मृति द्वारा उस एक समारोह में उन 2 मापदंडों के आदेश को जानते थे
  • कि आप एक SQL सर्वर या Oracle कनेक्शन स्ट्रिंग को हृदय से पढ़ सकते हैं
  • कि आप पूरी तरह से कोड कर सकते हैं, जबकि मैं आपके कंधे पर हर गलती को देख रहा हूं।

सभी ईमानदारी में, मैं कोडिंग परीक्षणों के प्रशंसक नहीं था - शैली का विश्लेषण करने के लिए एक उपकरण के अलावा।


1
मैं कोडिंग परीक्षणों का प्रशंसक नहीं हूं। प्रोजेक्ट यूलर पर समस्याएं दिलचस्प मस्तिष्क टीज़र हैं और समस्या समाधान कौशल विकसित करने का एक शानदार तरीका है। लेकिन अगर आप ज्यादातर CRUD ऐप लिख रहे हैं, तो यह जानना बेहतर है कि क्या कोई उम्मीदवार अच्छे DB प्रश्नों को लिखना जानता है या, यदि आप मेरी तरह .NET दुनिया में हैं, तो MVC, WCF, WPF और LINQ।
jfrankcarr

1
मैं उस टिप्पणी को जोड़ूंगा कि यह समझने के बजाय कि शब्दार्थ भी मायने नहीं रखता है कि वे किस तरह की समस्याओं को हल करते हैं और कब और कहां वे मायने रखते हैं और किसी भी डाउनसाइड को वे ले जाते हैं।
रिग

@jfrankcarr - अगर आप यह निर्धारित करें कि कोई व्यक्ति किसी प्रकार के परीक्षण में sql लिख सकता है?
जेएफओ

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

1

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


1

मुझे लगता है कि आप एक प्रश्न पूछ रहे हैं जिसके लिए वास्तव में कोई उत्तर नहीं है, बहुत कम 'सही' उत्तर है। मेरे कहने का कारण यह है कि यह पूरी तरह से उस व्यक्ति पर निर्भर करता है जो प्रश्न का मान पूछ रहा है।

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

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

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


0

साक्षात्कारकर्ता आपको वैसे भी अपने समाधान में सुधार करने के लिए कहेंगे।

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


1
"साक्षात्कारकर्ता आपको वैसे भी अपने समाधान में सुधार करने के लिए कहेंगे।" मेरे लिए एक जुआ की तरह लगता है।
क्रेगे

1
@ क्रैज: वास्तव में नहीं। लेकिन अगर वे इसे नहीं लाते हैं। कहते हैं कि यह एक क्रूर बल समाधान है और विश्लेषण के साथ सुधार किया जा सकता है।
मार्टिन यॉर्क
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.