पुन: डेवलपर साक्षात्कार (वैकल्पिक / अतिरिक्त)

मैं विषय " मध्य / वरिष्ठ आईओएस डेवलपर के साथ एक साक्षात्कार के लिए प्रश्न " और लेख " डेवलपर साक्षात्कार " से अतीत नहीं पा सका। मैं डेवलपर्स के साक्षात्कार के लिए एक वैकल्पिक या अतिरिक्त दृष्टिकोण की पेशकश करना चाहता हूं।

एक कागज के एक टुकड़े पर एक गोवनोकॉड या सौ मोटली सवाल करना, निश्चित रूप से, ठीक है, लेकिन अगर यह साक्षात्कार का एकमात्र चरण है, तो यह आपको कुछ पूछना चाहता है जैसे: "क्या आप गंभीर हैं?"

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

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

आप क्या सुझाव देते हैं, यार?

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

मैं क्या प्रस्ताव करता हूं: हम एक लोकप्रिय, बड़ी (कार्यक्षमता के मामले में) और जटिल (कार्यान्वयन के मामले में) आवेदन लेते हैं और इस बारे में बात करते हैं कि उम्मीदवार इसे कैसे बनाएंगे !

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

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

उदाहरण के लिए, Android के लिए Vkontakte एप्लिकेशन लें (यह बहुत बड़ा, जटिल और कई से परिचित है)।


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

आप देखेंगे कि "हम किस बारे में बात करेंगे" के प्रत्येक खंड के बाद जो निष्कर्ष निकालेंगे, वह सार्वभौमिक और सॉफ्टवेयर विकास के कई क्षेत्रों के लिए उपयुक्त है (आप हमेशा अपने क्षेत्र के लिए सब कुछ अनुकूलित कर सकते हैं)।

और ऐसे साक्षात्कार का संचालन कैसे करें?

मैं डिवाइस पर एप्लिकेशन / साइट / आदि को खोलूंगा (यह सब कुछ चर्चा करने के लिए सार नहीं है) और, वास्तव में, एक बातचीत शुरू करें: "कल्पना करें कि आपको इस तरह के आवेदन को लागू करने की आवश्यकता है, आइए चर्चा करें कि आप इसे कैसे करेंगे?" और सवालों पर चले गए। कुछ स्क्रीन खोलें और पूछें: "आप कैसे करेंगे ..."

हम किस बारे में बात करने जा रहे हैं?

(Android विकास सिर्फ एक उदाहरण है)

1. वास्तुकला के क्षण

• हम नेटवर्क की यात्राएं कैसे आयोजित करते हैं? (सेवा या अष्टक, या दोनों; हो सकता है कि आपके अपने सूत्र)
• एक डेटाबेस (ORM, शुद्ध एसक्यूएल) कैसे बनाएं, हम बहु-थ्रेडेड समस्याओं को कैसे हल करेंगे? वैसे, क्या आप नोएसक्यूएल डाल सकते हैं ??)
• डेटा कैशिंग के बारे में क्या? (फ़ाइलों पर क्या संभव है, और डेटाबेस में क्या है, क्या अक्षम है, कैश आकार की सीमा)
• एपीआई स्तर को कैसे लागू किया जाए? (यहां यह केवल इस बारे में है कि कौन से दृष्टिकोण लागू होंगे, कहते हैं कि सभी सर्वर प्रतिसाद मॉडल मूल एक को प्राप्त करते हैं, नेटवर्क त्रुटियों से निपटते हैं, एपीपी से त्रुटियों को संसाधित करते हैं)
  
  इस मुद्दे पर बहुत ध्यान दिया जाना चाहिए, जैसा कि (सामान्य रूप में KISS) इस तरह के सर्वर API के कार्यान्वयन के रूप में बातें तो /,, परियोजना भर में इस्तेमाल किया जाता है, जबकि सुधार के लिए तैयार है, तो यह आसान होना चाहिए भविष्य में आने वाले बदलाव
• उन गंभीर पुस्तकालयों के बारे में अभी चर्चा करें, जिन्हें डेवलपर प्रोजेक्ट में खींचना चाहता है (गंभीर लोगों के बारे में, मेरा मतलब है कि जो भविष्य में कसकर हाथ बांधते हैं, उदाहरण के लिए Robospice, ActionBarSherlock (मैं ActionararCompat के बारे में पाठ्यक्रम में हूं), AndroidAnnotations, आदि)

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

2. प्लेटफॉर्म की बारीकियां

• टुकड़े! (आप उन पर सब कुछ करते हैं, क्यों? आप इसका उपयोग कहां और कैसे करेंगे, यहां आप Vkontakte में नेविगेशनड्रावर खोल सकते हैं और पूछ सकते हैं कि आवेदन में शीर्ष-स्तरीय नेविगेशन की व्यवस्था कैसे की जाती है, इसे क्यों और इसी तरह बनाया गया था)
• एक Android एप्लिकेशन के घटकों का जीवन चक्र (कार्य, गतिविधि, टुकड़ा, सेवा)
• उत्तरदायी-यूआई अनुप्रयोगों के आयोजन के लिए दृष्टिकोण (टाइपिंग, थीम शैली, एनिमेशन, डीपी, एसपी, वे कैसे काम करते हैं, उन्हें कैसे टाइप करें)
• एपीआई स्तर <11 और एपीआई स्तर> 11 के बीच महत्वपूर्ण अंतर

इन सवालों के बाद, आप एक विशिष्ट प्लेटफ़ॉर्म के लिए विकास कौशल के स्तर को समझेंगे (इस मामले में, एंड्रॉइड)

3. प्रोग्रामिंग और विकास में सामान्य साक्षरता (इस विषय पर मेरे सिर में कई गड़बड़ियाँ हैं ...)

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

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

4. समय सीमा का मूल्यांकन, संभावित टीम वर्क

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

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

वह सब है। महत्वपूर्ण नोट्स और IMHO लेखक

यह दृष्टिकोण उन कंपनियों के लिए उपयुक्त नहीं है जिनकी भर्ती स्ट्रीम में रखी गई है और प्रत्येक साक्षात्कार के लिए 15-20 मिनट का कठिन समय है। लेकिन यह पेशेवरों की एक छोटी टीम के लिए अच्छी तरह से काम कर सकता है जिन्हें एक अतिरिक्त पेशेवर व्यक्ति की आवश्यकता होती है।

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

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

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

पीएस साक्षात्कार के लिए इस तरह के एक दृष्टिकोण एक विशिष्ट प्रोफ़ाइल पर काम के अनुभव के लिए इन मूर्खतापूर्ण आवश्यकताओं को हटा सकते हैं। आप जानते हैं, मैंने 3+, 5+, 10+ और यहां तक ​​कि 15+ के अनुभव के साथ बहुत से प्रोग्रामर देखे हैं, लेकिन वे अभी भी यह नहीं सीख पाए हैं कि कैसे प्रोग्राम करना है, जो वे देते हैं वह एक ऐसा बुर्ज है जिसे मैं इसे फेंकना चाहता हूं, एक कोने में छिपाना और रोना, लेकिन ये लोग अपने 100k + प्राप्त करते हैं और सोचते हैं कि उन्हें उपहार दिया गया है। यदि आप एक रिक्ति पोस्ट कर रहे हैं, तो कृपया कार्य अनुभव कॉलम में रखें: "यदि आप अच्छी तरह से प्रोग्राम करते हैं तो यह कोई फर्क नहीं पड़ता" या "वर्ष से" और इस मानदंड के आधार पर उम्मीदवारों को फ़िल्टर न करें।

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

UPD: पद के लिए एक परिशिष्ट के रूप में: आपको उन परियोजनाओं पर चर्चा नहीं करनी चाहिए जो आपने स्वयं पहले ही कार्यान्वित की हैं , सबसे अधिक संभावना है कि उम्मीदवार के उत्तरों के संबंध में आपकी राय पक्षपाती होगी।