फेसबुक पर साक्षात्कार आयोजित करने वाले एक प्रोग्रामर के उम्मीदवारों के लिए टिप्स

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

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

प्रारूप

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

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

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

जॉब इंटरव्यू के लिए बेस्ट प्रैक्टिस

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

1. स्पष्ट प्रश्न पूछें।
2. समाधान विकल्पों, उनके पेशेवरों और विपक्षों का विश्लेषण करें
3. ड्राफ्ट कोड
4. समाधान कार्यान्वयन दिखाएं
5. अपने समाधान का परीक्षण

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

चतुर प्रश्न पूछें

निर्णय लेने से पहले, आपको समस्या को अच्छी तरह से समझने की आवश्यकता है। कुछ विचारशील परिशोधन सफलता की संभावनाओं को गंभीरता से बढ़ा सकते हैं। यहाँ कुछ उदाहरण हैं:

• क्या यह अतिरिक्त मेमोरी के बिना किए जाने की आवश्यकता है?
• हमें किस इनपुट पर ध्यान देना चाहिए?
• अधिक महत्वपूर्ण क्या है - प्रदर्शन या कम मेमोरी खपत?

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

मत सोचो

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

"क्या हम मानते हैं कि सभी मूल्य सकारात्मक हैं?"

कहीं आसान नहीं है। अगर वे कहते हैं कि हाँ, यह बहुत अच्छा है। कोई अतिरिक्त जांच की आवश्यकता नहीं है। यदि नहीं, तो आपके कोड को किसी भी मौके से बचाने के लिए एक एकल शर्त कथन पर्याप्त है। अक्सर ऐसे सवालों की मदद से आप एक संकेत प्राप्त कर सकते हैं कि आपको किस दिशा में आगे बढ़ना है।

समाधान के विकल्प

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

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

कोड फॉर्म में अपने समाधान को ड्राफ़्ट करें

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

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



कार्यान्वयन लिखें

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

संचार!

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

हालांकि, एक चेतावनी बनाई जानी चाहिए: व्यक्तिगत साक्षात्कार शैली बहुत कुछ तय करती है। निर्णय के दौरान कोई और अधिक सक्रिय रूप से हस्तक्षेप करता है, कोई दूर रहना पसंद करता है।

परीक्षण

अजीब तरह से पर्याप्त है, यह कदम सबसे अधिक बार उपेक्षित है। मैं कहूंगा कि 98% डेवलपर्स जो मेरे साक्षात्कार में थे, उन्हें अपने फैसलों की जाँच करने पर अधिक ध्यान देना चाहिए।

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

तकनीकी साक्षात्कार में दिखाने का सबसे आसान तरीका परीक्षण लिखना है। अधिक, बेहतर। बेहतर कठिन है। जितना व्यापक, उतना बेहतर। ज्यादातर मामलों में, इससे पहले कि मैं उन्हें इंगित करने से पहले आपको बग को पकड़ने की अनुमति देगा। और ऐसी बातें आपके पक्ष में बोलती हैं।

यदि आप नहीं जानते कि क्या करना है

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

अगर कुछ भी दिमाग में न आए, तो घबराएं नहीं। सब कुछ ठीक है। तुरंत सबसे प्रभावी समाधान खोजने की कोशिश करने के बारे में चिंता न करें - सबसे सरल से शुरू करें। फिर, इसे एक शुरुआती बिंदु पर ले जाएं, सोचें: यहां क्या अड़चनें हैं? अनुकूलन की सबसे अधिक आवश्यकता क्या है? इसे कैसे अनुकूलित किया जा सकता है?

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

उदाहरण के लिए, आपके पास एक कार्य है:

एक प्रस्ताव को देखते हुए, गणना करें कि वर्णमाला का प्रत्येक अक्षर कितनी बार इसमें दिखाई देता है।

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

• बाइनरी सर्च ट्री
• सरणी
• हैश टेबल
• एवीएल पेड़
• अनेकता
• बारी

हैश तालिका सबसे प्रभावी रूप से डेटा संग्रहीत और पुनर्प्राप्त करती है। यदि आप इसका उपयोग करते हैं, तो आपको छब्बीस बार प्रस्ताव का विश्लेषण करना होगा - बस एक ही काफी है।

एक सुराग के लिए देखो

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

आइए बताते हैं:

पूर्णांक, ए और बी प्रकार के दो क्रमबद्ध सरणियों को देखते हुए; ए से बी को मर्ज करना आवश्यक है। यह माना जाता है कि ए बी से सभी तत्वों को समायोजित कर सकता है; सरणियों में आरंभीकृत तत्वों की संख्या क्रमशः m और n है।

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

यहां मुक्त स्थान आपको विलय प्रक्रिया को अनुकूलित करने का अवसर देता है। पूरा समाधान यहां देखा जा सकता है ।

मदद के लिए पूछें

कभी-कभी ऐसा होता है कि आप सभी चरणों से गुजरते हैं, लेकिन एक मृत अंत में बने रहे। इस मामले में, आपको बस मदद के लिए साक्षात्कारकर्ताओं से संपर्क करना होगा।

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

निष्कर्ष में

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

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