एक मोबाइल मिड-रेंज डेवलपर का आदर्श (शायद) साक्षात्कार

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



* शायद

स्वभाव

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

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

स्टेज 0 - दो अकेलेपन से मुलाकात की

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

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

स्टेज 1 - परीक्षण कार्य या नमूना कोड

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

• तीन स्क्रीन: दो लिंक्ड लिस्ट + डेटा एंट्री फॉर्म, जो अगर वांछित हो, तो एक मोडल विंडो से बदला जा सकता है
• नेटवर्क का काम
• डेटा वेयरहाउस के साथ काम करना (कार्य का अर्थ है एक डेटाबेस, अगर डेवलपर किसी अन्य निष्कर्ष को सही ठहरा सकता है - हमारा स्वागत है)

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

• आवेदन बहुत छोटा है, कोड सांकेतिक नहीं है या बहुत सारे प्रश्न का कारण बनता है, कृपया हमारा परीक्षण करें
• आवेदन उपयुक्त है, लेकिन बारीकियां हैं - कृपया मामूली सुधार करें (शाम से कम)

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

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

स्टेज 2 - साक्षात्कार

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

अगला 1-2 छोटे व्यावहारिक कार्य होंगे, वे परीक्षण कार्य पर निर्भर करते हैं। फिर, हम कीबोर्ड को हाथ में देते हैं (कंप्यूटर से जुड़ा, मॉनिटर वाला कंप्यूटर!) और आपसे कुछ लिखने या संपादित करने के लिए कहें। मेरी पसंदीदा चीजों में से एक 10-20 लाइनों के लिए एक कामकाजी लेकिन खराब लिखित कार्य देना है और इसे फिर से भरने का सुझाव देना है। यह तुरंत स्पष्ट हो जाता है कि क्या उम्मीदवार के पास एक बुरा कोड है, वह भाषा के निर्माण के बारे में क्या जानता है, क्या वह सूची में किसी और के कोड को आगे पढ़ सकता है या नहीं।

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

लेकिन उम्मीदवार धोखा दे सकता था

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

तो बंद करो! मैंने टीम को सवाल में पहचान लिया, कुछ साल पहले उसका साक्षात्कार लिया, और वहां योजना बहुत अलग थी

हां, मुझे पश्चाताप हुआ, फिर मैंने बिना किसी परीक्षण के छोटे चुनावों और साक्षात्कारों के साथ पाप किया। बहुत समय बिताया, दोनों अपने और किसी और के। इसलिए जब डेवलपर के लिए नई खोजों की बात आई, तो मैंने एक अलग दृष्टिकोण आजमाने का फैसला किया। क्या डेवलपर्स कोड लिख रहे हैं? बहुत बढ़िया! मुझे अपना कोड दिखाएं और मैं आपको बताऊंगा कि क्या हमें साक्षात्कार होना चाहिए।

लेकिन मुझे कंपनी में पता चला! एक और परियोजना में बसे, और वहाँ भी, सब कुछ गलत है!

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

वर्णित दृष्टिकोण के अन्य नुकसान हैं!

टिप्पणियों में आपका इंतजार है। हम चर्चा करते हैं ;-)