किसी व्यक्ति के डिबगिंग कौशल की जांच या आकलन कैसे करें? [बन्द है]

Question

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

तब से हम सोच रहे हैं कि हम किसी व्यक्ति के डिबगिंग कौशल का आकलन या अनुमान कैसे लगा सकते हैं।

तो पहला सवाल यह है: क्या कौशल निर्धारित करते हैं कि कोई व्यक्ति सॉफ्टवेयर को प्रभावी ढंग से डिबग कर सकता है?

और दूसरा: साक्षात्कार के दौरान उन कौशल का परीक्षण कैसे करें?

Comments

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

— wkl

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

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

— क्वांटिकल

@quanticle वही, मेरी कंपनी एक व्यक्ति-साक्षात्कार के लिए विचार करने से पहले आपको 5-प्रश्न प्रोग्रामिंग टेस्ट (लगभग आधा डिबगिंग) देती है। स्पष्ट रूप से यह अधिकांश उम्मीदवारों को मातम करता है ...

— इज़्काटा

उसे :-)

— JustMe

Answer 1

यदि पहली चीज जो व्यक्ति करना चाहता है, वह कोड को देखता है और एक डिबगर के साथ इसके माध्यम से कदम उठाता है कि व्यक्ति एक महान समस्या निवारक नहीं है।

यदि आपके पास पहले से कार्रवाई की योजना नहीं है और आप डिबगर ब्लाइंड में गोता लगाते हैं तो आप मूल रूप से ईस्टर एगिंग हैं। यह किसी भी तरह की समस्या निवारण के लिए सही है।

एक साक्षात्कार की स्थिति में एक व्यक्ति जो पूछता है कि सिस्टम कैसे संचालित होता है और सिस्टम के इतिहास के बारे में पूछता है कि कोई ऐसा व्यक्ति होगा जो एक अच्छा समस्या निवारक हो सकता है। एक व्यक्ति जो सोचता है कि प्रणाली पहले और यांत्रिकी दूसरा एक अच्छा समस्या निवारक हो सकता है।

यह किसी भी जटिल प्रणाली का सच है।

Comments

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

— maple_shaft

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

— जॉर्डन

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

— एलग्रिन्गोग्रैन्ड

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

— डंक

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

— जॉर्डन

Answer 2

मेरा तर्क है कि किसी विशेष भाषा या ढांचे में एक अच्छे सॉफ्टवेयर डेवलपर का सबसे अच्छा उपाय गंभीर समस्याओं का गंभीर रूप से विश्लेषण करने और भाषा या ढांचे में अच्छे डिबगिंग कौशल रखने की क्षमता है। वे कम स्तर डिबगिंग के साथ-साथ सामान्य डिबगिंग टूल के साथ उच्च स्तर डिबगिंग में दक्षता प्रदर्शित करने में सक्षम होना चाहिए।

इसका मतलब है कि उनके लिए एक परिदृश्य तैयार करना जो उनके चुने हुए आईडीई में डिबगिंग टूल की उच्च योग्यता को प्रदर्शित करता है। आपको चीजों की तलाश करनी चाहिए जैसे:

• डिबग मोड में सैंडबॉक्सिंग एप्लिकेशन या सर्वर चलाना या डिबगिंग के लिए प्रतीकों के साथ एप्लिकेशन बनाना

• दूरस्थ डिबगिंग पोर्ट उपलब्ध कराना और प्रदर्शन करना या गैर-सैंडबॉक्स वाले एप्लिकेशन का डिबगिंग जो प्रतीकों के साथ बनाया गया था (यदि भाषा पर लागू हो)

• ब्रेकप्वाइंट का रणनीतिक उपयोग

• ब्रेकपॉइंट्स के कस्टम गुण, ब्रेकपॉइंट्स पर सशर्त अभिव्यक्ति (यदि भाषा पर लागू हो)

• चर मूल्यों या संदर्भों की निगरानी के लिए अभिव्यक्ति या चर घड़ियों का उपयोग

• वास्तविक समय में तदर्थ चर मूल्य या संदर्भ या सूचक हेरफेर का उपयोग

• अनुप्रयोग प्रवाह में आगे और बाहर कदम रखने की क्षमता प्रदर्शित करता है

• कॉल स्टैक का महत्वपूर्ण मूल्यांकन

• बहु-थ्रेडेड अनुप्रयोगों को डीबग करना और इसे समझना।

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

Comments

+1 काफी सहायक सूची। और एक लागू किया।

— दीपन मेहता

मेरा विचार है कि बहु-थ्रेडेड अनुप्रयोगों को डीबग करना एकल-थ्रेडेड ऐप्स को डीबग करने की तुलना में पूरी तरह से वास्तविक है। अलग, और बहुत, बहुत कठिन।

— ब्रूस एडिगर

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

— डिबगर्स को

डिबग प्रिंट स्टेटमेंट ठीक हैं और एक डिबगर के लिए बेहतर हो सकते हैं, खासकर जहां संगामिति शामिल है। उनके साथ आपकी समस्या वास्तव में धीमी संकलक के साथ हो सकती है।

— रिकी क्लार्कसन

Answer 3

मैं कहता हूँ कि आप अपने सिस्टम में एक बग को डिस्टिल करें जो कि एक साक्षात्कार के संदर्भ में चर्चा की जा सकती है। डीबगर को आग दें और उसे उस पर चढ़ने दें।

Answer 4

उससे इस तरह सवाल पूछें:

1. आप एक समस्या से कैसे निपटते हैं?

2. आपके द्वारा किए गए जटिल प्रोजेक्ट में से एक क्या है और आपने इसे कैसे प्राप्त किया?

3. आपने कौन से डिबगिंग टूल का उपयोग किया?

4. क्या आपके पास कुछ टूल्स के लिए कोई प्राथमिकता है?

5. अपने स्वयं के परिदृश्य का एक उदाहरण दें और उससे पूछें कि वह इससे कैसे निपटेगा?

6. आप किसी और कोड में जाने की अपनी क्षमता का मूल्यांकन कैसे करेंगे?

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

Answer 5

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

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

शायद व्यक्ति सिर्फ डिबगिंग पसंद नहीं करता है और कोई प्रयास नहीं करता है? मैं इस पर अच्छा नहीं हूँ, इसलिए मुझे ऐसा करने के लिए कहना बंद करो - असहायता सीखी।

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

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

Comments

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

— मीकल बी।

@ मिचल: हम सभी अपने कार्यक्रमों को डिबग करते हैं, लेकिन कुछ लोग एक राजसी दृष्टिकोण का प्रदर्शन करेंगे, जबकि अन्य सिर्फ बेतरतीब ढंग से चीजों को घुमाते हैं और देखते हैं कि क्या होता है ।

— मथिउ एम।

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

— डंक

Answer 6

उसी तरह आप किसी की कोडिंग क्षमता निर्धारित करेंगे, उनसे डिबगिंग के बारे में सवाल पूछेंगे।

उनसे पूछें "कैसे" वे किसी दिए गए स्थिति में बग को ट्रैक करेंगे।

इसे एक कदम आगे ले जाएं और उन्हें एक कंप्यूटर के सामने बैठकर एक मुद्दे पर डिबग करते हुए देखें।

Answer 7

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

Answer 8

आमतौर पर अच्छी योग्यता वाले लोग अच्छे डिबगिंग कौशल वाले भी होते हैं।

साक्षात्कार के दौरान, (उनकी वरिष्ठता के आधार पर) आप उन्हें पहेली के असाइनमेंट जैसे कि कुछ एल्गोरिथ्म या तो दे सकते हैं। वह सरल तरीका है।

यदि आप कर सकते हैं, तो आप कुछ काम से बाहर एक कोड प्रिंट कर सकते हैं व्यक्ति से पूछें कि क्या यहां कुछ गलत है और यदि ऐसा है तो इसे कैसे ठीक करें।

मैं मोटे तौर पर साक्षात्कार के प्रश्न पूछना पसंद नहीं करता, जो लोगों के पढ़ने और वाक्य रचना को ठीक करने की क्षमता पर ध्यान केंद्रित करता है।

Comments

+1 शानदार जवाब! मैं इस बात से सहमत हूं कि सबसे अच्छे सॉफ्टवेयर डेवलपर्स में अच्छे डिबगिंग स्किल्स होते हैं और मुझे यह भी लगता है कि स्पॉटिंग सिंटैक्स एरर ज्यादा प्रदर्शित नहीं करते हैं। अधिकांश आईडीई और यहां तक ​​कि कुछ अच्छे टेक्स्ट एडिटर (नोटपैड ++) आम भाषाओं में वाक्यविन्यास त्रुटियों की पहचान करेंगे। हालांकि मैं असहमत हूं कि एक पहेली डिबगिंग कौशल को प्रदर्शित करती है। पहेलियाँ महत्वपूर्ण सोच को प्रदर्शित करती हैं जो एक अलग लेकिन संबंधित कौशल है।

— maple_shaft

@maple_shaft के लिए धन्यवाद (अभी तक एक और +1)। सच है, पहेलियाँ सीधे डीबगिंग से जुड़ी नहीं हैं । लेकिन यह न्याय करने के लिए अच्छा है कि लोग समस्याओं के लिए कैसे दृष्टिकोण रखते हैं - वास्तव में एक अप्रत्यक्ष चीज।

— दीपन मेहता

मैं पहेली को देखता हूँ और मैं ewwwwwwww की तरह हूँ। तुम सच में किसी भी चीज़ "गोच" सामान से बेहतर नहीं है? और "वरिष्ठता" कैसे चित्र में आती है? अधिक कठिन पहेली को हल करने के लिए पुराने पीपीएल माना जाता है? सभी अच्छे प्रोग्रामर (या डीबगर्स) सुडोकू के प्रशंसक हैं? आप पूरे शहर में कुछ वास्तव में अच्छे प्रोग्रामर और बुरे मुंह वाले लोगों को परेशान कर सकते हैं। गेटा प्रश्न एक अपमान है <अवधि> कृपया कुछ बेहतर पुरुषों के साथ आएं।

— चनी

@Srooge मेरा मतलब केवल प्रोग्रामिंग पज़ल्स के रूप में था - मैंने कभी सैकड़ों साक्षात्कार के साथ सुडोकू नहीं खेला।

— दीपन मेहता

Answer 9

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

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

Answer 10

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

इसे पुराने डेस्कटॉप परिवेश के लिए दूरस्थ डेस्कटॉप के रूप में व्यवस्थित किया गया था। संभवतः एक अनप्लग या पृथक वातावरण के लिए। परियोजना कुछ ASP.NET नियंत्रण और संबंधित कोड-फ़ाइल कोड के साथ कुछ वेबफॉर्म थी। कोडफ़ाइल को एक प्रकार की व्यावसायिक परत के लिए संदर्भित किया जाता है जिसके लिए मेरे पास बस एक dll, कोई स्रोत कोड और विधि का विवरण नहीं है। Webforms ने CRUD फ़ंक्शंस किए जिनसे आप उम्मीद कर सकते हैं। एक छोटा सा खोज समारोह भी। व्यापार परत, बदले में, एक एसक्यूएल सर्वर में दृश्य और एसपी से बात की।

उन्होंने कुछ हिस्सों को अलग-अलग स्तरों पर ब्रोक किया। मुझे लक्षणों के साथ एक पेपर दिया गया था। "खोज नहीं कर सकता" "अंतिम अद्यतन के बाद 'क्षेत्र' गायब हो गया" और इस तरह। जैसे कि आप अपने उपयोगकर्ताओं से प्राप्त कर सकते हैं।

मुझे सभी विवरण याद नहीं हैं, लेकिन कम से कम एक टेबल फ़ील्ड का नाम बदल दिया गया है, जो एक टूटे हुए एसपी की ओर जाता है, जिसका उपयोग खोज फ़ंक्शन द्वारा किया गया था। इसका मतलब है कि फ़ील्ड नामों को ट्रेस करने के लिए VS और कोई BL स्रोत कोड में कोई त्रुटि नहीं है। Sqlcommand के खिलाफ एक चयन पैरामीटर गलत वर्तनी की गई और खराबी के लिए एक वेबफॉर्म का कारण बना। साथ ही एक फ़ील्ड को छोड़ दिया गया था जो कि GridView (Autogeneratecolumns) में गायब फ़ील्ड था। ASP.NET बटन को कुछ ऐसी चीज़ों के लिए संदर्भित किया गया था, जिनका मतलब नए तरीके से डुप्लिकेट, एन्हांस्ड, मेथड और "फॉरगेट" टू प्वाइंट बटन होना चाहिए।

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

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

* मुझे लगता है कि परीक्षण को उम्मीदवारों / मेरे कौशल को साबित किया गया था *
* एक विदेशी प्रणाली का विश्लेषण
करें * त्रुटियों और बग को खोजने के लिए कम से कम जानकारी का उपयोग करें
* समय के तनाव के तहत और किसी की मदद के बिना, आप सुधार मान लिया गया है
* ज्ञान के विभिन्न स्तर;
** sql db और संग्रहीत कार्यविधियाँ,
** dll का प्रोजेक्ट में उपयोग,
** asp.net तकनीक,
** स्तरित वास्तुकला
** समस्या-उन्मुख पहलू

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

Answer 11

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

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

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

Answer 12

कुछ सरल बाइनरी (डिबग) प्रतीकों के साथ कंप्यूटर पर बैठें जो अशक्त सूचक संदर्भ या ऐसे + स्रोत कोड + जीडीबी के साथ segfaults करते हैं और देखें कि क्या वे दुर्घटना का कारण खोज सकते हैं?

Comments

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

— maple_shaft

Answer 13

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

Answer 14

थोड़ा कोड स्निपेट में "बग" ढूंढना एक बहुत ही कृत्रिम स्थिति है। मुझे लगता है कि यह उसी तरह से सहायक हो सकता है जैसे कि पहेली और मस्तिष्क के टीज़र हैं।

एक अधिक व्यापक दृष्टिकोण व्यवहार संबंधी प्रश्न पूछेगा कि उम्मीदवार ने विशिष्ट घटनाओं का हवाला देते हुए और फिर प्रश्नों के साथ डिबगिंग का प्रदर्शन कैसे किया है।

कोई है जो शूटिंग में परेशानी में है, आईडीई में डिबग सुविधाओं से अधिक के बारे में बात करने में सक्षम होगा। बग के बारे में क्या ... बग-रिपोर्टिंग टूल, एंड-यूजर इंटरैक्शन, बग को पुन: प्रस्तुत करना, लॉगफाइल विश्लेषण, सत्यापन?

कोड के ब्लॉक के माध्यम से ट्रेसिंग की तुलना में डिबगिंग करने के लिए बहुत अधिक है और डीबगिंग में किसी के कौशल का मूल्यांकन करने से बचना चाहिए।

Comments

मुझे लगता है कि सॉफ्टवेयर में कीड़े हैं जो हमने अभी तक नहीं खोजे हैं। यह भूकंपीय दोषों को खोजने जैसा है। सवाल यह है कि कोई टेल-टेल संकेत के लिए कैसा दिखता है।

— क्रिस्टोफर महान

Answer 15

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

बोनस बिंदु यदि वे मूल कोड में बग ढूंढते हैं।

डबल बोनस बिंदु अगर वे मूल कोड में बग को ठीक कर सकते हैं।

Answer 16

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

Answer 17

मैं प्रौद्योगिकी अज्ञेय के कुछ प्रश्नों को निम्नलिखित की तरह पूछूंगा:

• मुझे मूल कारणों की पहचान करने और बग (दोष) को ठीक करने के लिए उठाए गए सभी कदमों के माध्यम से लें
• मल्टी थ्रेडिंग ऐप को डीबग करते समय आप कॉल स्टैक का उपयोग कैसे करेंगे

यह फोन साक्षात्कारों में वास्तव में अच्छी तरह से काम करता है क्योंकि आपको केवल एक व्यक्ति को आपको एक ठोस उत्तर देने की आवश्यकता होती है जो दिखाता है कि वह समस्या का निवारण करते समय वास्तव में कैसे चीजों को दिखाता है।