मैं एक साक्षात्कार में एक मनमानी प्रणाली कैसे डिजाइन कर सकता हूं? [बन्द है]

36

टेक साक्षात्कार में एक सामान्य प्रश्न एक विशेष प्रणाली, आमतौर पर कंपनी के मौजूदा उत्पाद को डिजाइन करना है। उदाहरण के लिए, "Google डॉक्स डिज़ाइन करें"।

ऐसे प्रश्न के लिए अपेक्षित उत्तर क्या है? मेरा मतलब है, ऐसी प्रणालियों में निश्चित रूप से एक जटिल डिजाइन होता है जो किसी भी साक्षात्कार के दायरे से परे है। साक्षात्कारकर्ता इतने कम समय में क्या उम्मीद कर रहे हैं?

interview

— शमीम हाफिज
स्रोत

4

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

— सोचें

6

यदि यह एक मौजूदा उत्पाद है, तो मैं वापस गोली मार दूंगा, "आप अपने मौजूदा डिजाइन में क्या कमी पाते हैं?"

— ब्लरफ्ल

5

"अच्छी तरह से .. चरण 1 एक वकील से संपर्क करने के लिए यह देखने के लिए कि क्या हम किसी भी ट्रेडमार्क या कॉपीराइट का उल्लंघन कर रहे हैं"

— स्टीवन एवर्स

12

"अगर मैं आवश्यकताओं के दस्तावेजों को देखता हूं तो मन?"

— जोएल एथरटन

4

"कभी इसका इस्तेमाल नहीं किया। इसकी मुख्य विशेषताएं क्या हैं?"

— स्टीवन ए लोवे

22

इस समस्या को देखने में आपका दिमाग कैसा है यहां कुछ शुरुआती बिंदु हैं जो मैं देख सकता हूं कि कोई इस बातचीत को कैसे करने की कोशिश कर सकता है:

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

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

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

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

— जेबी किंग
स्रोत

2

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

— पी। ब्रायन। मैके

2

+1 अगर मैं कर सकता था: "कुंजी यह है कि आप अपने विचारों को कितनी अच्छी तरह से संवाद कर सकते हैं" ... दुर्भाग्य से, मेरा मानना है कि साक्षात्कारकर्ताओं और उम्मीदवारों के बहुमत इस क्षेत्र में कम हैं।

— Anon

2

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

— डीजेकेवर्थ

16

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

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

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

— एथेल इवांस
स्रोत

2

तो सवाल का एक अपेक्षित उत्तर कुछ यूएमएल आरेख है, कम से कम सरलीकृत?

— शमीम हाफिज

3

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

— एथेल इवांस

11

यह कार्रवाई में आपकी विचार प्रक्रियाओं को देखने के बारे में है; वे एक समाधान में रुचि नहीं रखते हैं, लेकिन आप समस्या को हल करने के लिए कैसे दृष्टिकोण करेंगे, आप क्या सवाल पूछेंगे, आप किन मुद्दों की पहचान करेंगे, आदि।

Google डॉक्स के उदाहरण को देखते हुए, दिमाग में आने वाले स्पष्ट मुद्दे भंडारण, सुरक्षा, मापनीयता, उपलब्धता, क्लाइंट इंटरफ़ेस डिज़ाइन, ब्राउज़र संगतता आदि जैसी चीजें हैं, आप सर्वर और क्लाइंट के बीच जिम्मेदारी को कैसे विभाजित करेंगे? आप बैकअप कैसे संभालेंगे? सर्वर डाउन होने पर क्या होता है? आप "निरस्त" दस्तावेजों के साथ क्या करेंगे (सामान जो लंबे समय तक एक्सेस या संशोधित नहीं किया गया है)?

फिर, बिंदु उन मुद्दों में से किसी को हल करने के लिए नहीं है , लेकिन उन्हें पहचानने के लिए, उनके माध्यम से बात करें, विचार-विमर्श करें कि कैसे पता करें, आदि।

— जॉन बोडे
स्रोत

9

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

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

बुरा जवाब:

उम, मैं शायद ईथरनेट या ऐसा कुछ उपयोग करूँगा।

अच्छा उत्तर:

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

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

— कार्ल बेवफेल्ड
स्रोत

1

आप कहां काम करते हैं और क्या आपको नए कर्मचारियों की आवश्यकता है? : डी

— मैगी

1

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

— डंक

5

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

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

Google डॉक्स के मुद्दे पर विचार करें:

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

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

Google डॉक्स जैसी कोई ऐप बनाने का कोई एक सही तरीका नहीं है, आपको यह पहचानने की ज़रूरत नहीं है कि आप हर ट्रेड-ऑफ के लिए क्या करेंगे, लेकिन यह एक ऐसा क्षेत्र खोजना बहुत अच्छा है, जिसमें एक दिलचस्प मुद्दा हो, और स्पष्ट रूप से समझाएं कि ट्रेड क्या है -ऑफ हो सकते हैं।

आयकर।

— ट्रिस्टन रीड
स्रोत

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

— डंक

2

मुझे संदेह है कि साक्षात्कारकर्ता क्या सुनना चाहते हैं:

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

आप आगे क्या चर्चा करना चाहेंगे?

फिर, गेंद साक्षात्कारकर्ता के न्यायालय में है। यदि वह अधिक विवरण चाहती है, तो वह पूछ सकती है। साक्षात्कारकर्ता क्या देख रहा है, क्या आप किसी समस्या या उत्पाद को देख सकते हैं और डिजाइन निकाल सकते हैं?

— गिल्बर्ट ले ब्लांक
स्रोत

1

उत्तर अच्छा है, लेकिन नहीं लगता कि साक्षात्कारकर्ता इससे संतुष्ट होंगे। अब तक के पदों पर पढ़ना, ऐसा लगता है कि ऐसे प्रश्न साक्षात्कारकर्ताओं के बीच लोकप्रिय नहीं हैं।

— शमीम हाफिज

-1 @Gilbert Le Blanc - द मैथिकल मैन मंथ में ब्रूक के नियम द्वारा परिभाषित "रैंप अप" समय इस सवाल को मूर्खतापूर्ण बनाता है। यदि हम जानते हैं कि किसी सॉफ्टवेयर प्रोजेक्ट में मूल्य जोड़ने के लिए सीखने में लगभग 6 महीने लगते हैं, तो क्या केवल 6 घंटे में "डिज़ाइन निष्कर्षण" की उम्मीद की जा सकती है? en.wikipedia.org/wiki/Brooks%27s_law

— पी। ब्रायन। मैके

1

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

— गिल्बर्ट ले ब्लैंक

4

अगर मैं इंटरव्यू दे रहा होता तो मैं उस जवाब से खुश नहीं होता। यहाँ उत्तर मुझे बताता है कि Google डॉक्स क्या है, कुछ जो मैं पहले से ही जानता हूं।

— whatsisname

1

@whatisname - मुझे लगता है कि साक्षात्कारकर्ता साक्षात्कार के संदर्भ में प्रश्न (या एक बॉलपार्क) का उत्तर जानना चाहता है।

— मॉर्गन हेरलॉकर

2

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

बाद में, वे प्रमुख उपयोग-मामलों / कहानियों के आधार पर एक वास्तु समाधान के साथ आने में सक्षम होना चाहिए। उम्मीद है कि उन्होंने मॉड्यूल को पहचानने के लिए कुछ व्यवस्थित प्रक्रिया का इस्तेमाल किया था, उन्हें उनके द्वारा खींचने के अलावा .... मैं समाधान के लिए एक साक्षात्कार की स्थिति से बहुत अधिक उम्मीद नहीं करूंगा।

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

— डुबोना
स्रोत

1

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

— माइकल ब्राउन
स्रोत

1

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

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

— JohnMcG
स्रोत

0

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

इसका मतलब है ब्लॉग, लेख, http://www.infoq.com , Hacker News आदि पढ़ना । यहां तक कि हार्डवेयर भी कोडिंग हॉरर से खिलते हैं।

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

इसलिए, साक्षात्कारकर्ता को शायद आपकी पढ़ने की आदत (आपके शौक के हिस्से के रूप में) में दिलचस्पी है और देखें कि क्या आपको यादृच्छिक स्थानों से विचारों के बीज एकत्र करने की नियमित आदत है।

— rwong
स्रोत

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

— Aaronaught

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

— 4:11

(जारी) कृपया अन्य स्रोतों से सीखे गए पाठों के महत्व को कम न समझें।

— rwong

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

— हारून

0

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

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

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

— विले ई.के.
स्रोत