दबाव में आने पर किसी समाधान पर कूदने से कैसे बचें? [बन्द है]

Question

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

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

यहाँ एक गणित की परीक्षा लेने के लिए तकनीकों की सूची दी गई है और दूसरी मौखिक परीक्षा लेने के लिए । क्या दबाव में प्रोग्रामिंग समस्या से निपटने के लिए तकनीकों की समान सूची है?

उत्तर: मुझे लगता है कि यह एक मान्य उत्तर है: इसे कैसे हल करें । मैंने उस लिंक को हल के लिए कदम या दृष्टिकोण के उत्तर के रूप में पाया । वहाँ भी वास्तव में सबसे अच्छी रणनीति एक साक्षात्कार के दौरान जोर से सोच रहा था पर कुछ अच्छे सुझाव थे ? । TDD के लिए एक महान और संक्षिप्त तर्क TDD राइटिंग कोड बनाम एक समस्या का उत्तर जानने का पहला उत्तर है? ।

Comments

यह सभी के लिए अलग है। मैं किसी ऐसे व्यक्ति को जानता था जो लंबे समय तक कीबोर्ड को नहीं छूता था, फिर वह कुछ ही समय में एक अच्छा समाधान निकाल सकता है। मेरे लिए, मुझे टीडीडी फ़नल को सही समाधान में अपना दृश्य सबसे तेज लगता है। कोई भी संभवतः आपको नहीं बता सकता है कि आपके लिए क्या काम करेगा।

— पीडीआर

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

— GlenPeterson

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

— ZJR

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

— GlenPeterson

पहले पता करें कि वास्तव में क्या आवश्यक है या अपेक्षित है। क्या हल करना काफी कठिन है, इसे हल करने की तुलना में अधिक विश्लेषण की आवश्यकता होती है और अक्सर एक अलग प्रश्न का पूरी तरह से पता चलता है।

— शून्य से

Answer 1

मुझे याद है कि एक आग के दृश्य के आगमन पर फायर मार्शल्स कैसे कार्य योजना बनाते हैं, इस पर एक अध्ययन को याद करते हुए; अध्ययन ने एक विचार के साथ आने के लिए उन्हें मनाया (और निंदा की), फिर तुरंत उस पहले विचार का अनुसरण किया। समय के दबाव के कारण, यह बहुत "यह काम कर सकता है" उसके बाद "ठीक है, चलो ऐसा करते हैं"। अध्ययन ने कहा कि बेहतर, तेज, सुरक्षित विकल्प उपलब्ध थे, लेकिन उनका पालन केवल इसलिए नहीं किया गया क्योंकि मार्शलों ने पहले उनके बारे में नहीं सोचा था।

यदि आप "आग" से निपटने के लिए एक संरचित दृष्टिकोण चाहते हैं, तो शायद उनकी (नई) पुस्तक से एक पत्ता निकालें जो कई चरणों को निर्धारित करता है:

RRAPID

1. प्रतिक्रिया - घटना के लिए संसाधनों को जुटाना
2. टोही - स्थिति के बारे में डेटा एकत्र करें
3. प्रशंसा - सर्वश्रेष्ठ और सबसे खराब स्थिति के आधार पर कार्रवाई का एक कोर्स चुनें
4. योजना - कार्रवाई के पाठ्यक्रम के आधार पर एक योजना विकसित करना
5. आदेश जारी करना - मानक ब्रीफिंग प्रारूप का उपयोग करें
6. तैनाती - निष्पादित करें और निगरानी करें

या अधिक सामान्य शब्दों में:

1. सबको जगाओ और उन्हें आगे बढ़ाओ
2. जो चल रहा है, उस पर काम करो
3. मंथन के उपाय
4. एक उठाओ और इसकी योजना बनाओ
5. सभी को बताएं कि उनका काम क्या है
6. निष्पादित करें और मॉनिटर करें

Answer 2

मैं हमेशा आवश्यकताओं को समझने और उनमें अंतराल की तलाश करने के साथ शुरू करता हूं, जिन्हें जवाब की आवश्यकता होती है।

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

एक बार जब मेरे पास मेरे प्रारंभिक प्रश्न होते हैं (100% प्रश्न होते हैं, यदि आपके पास कोई नहीं है, तो आपने वास्तव में आवश्यकता पर गहराई से ध्यान नहीं दिया है।), मैं अपने उत्तर पाने के लिए हितधारकों के पास वापस जाता हूं।

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

एक बार जब मुझे अपने उत्तर मिल जाते हैं तो मैं एक मोटा डिजाइन चुन लेता हूं और फिर मैं उन सभी चीजों की एक सूची बनाता हूं जिन्हें लागू करने के लिए मुझे करना होगा। फिर मैं कोडिंग शुरू करता हूं।

Answer 3

... मेरी प्रवृत्ति एक वास्तविक योजना के बिना कोडिंग में कूदने की है और आशा है कि मैं जैसे-जैसे आगे बढ़ूंगा, इसका पता लगाऊंगा।

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

... एक साक्षात्कार में यह बहुत असफल रहा है, अगर एकदम से-उत्पादक नहीं है। मैं हमेशा यह सोचकर आराम से नहीं बैठता कि घड़ी टिक जाए।

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

क्या कोई चेकलिस्ट है या पहचानने की तकनीकें हैं जब आप समस्या को अच्छी तरह से समझते हैं कि कोडिंग शुरू करना पर्याप्त है?

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

जब यह सबसे अधिक सोचने और डिजाइन करने के लिए सबसे अधिक उत्पादक होता है तो कुछ प्रयोगों को कोड करता है और बाद में ओवर-ऑल डिज़ाइन का पता लगाता है?

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