काम की तलाश में वरिष्ठ अभियंता। मैं 15 तकनीकी साक्षात्कारों के माध्यम से कैसे गया और मैं इसके बारे में क्या सोचता हूं

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

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

इससे पहले कि मैं व्यवसाय में उतरूं, मैं सबसे लोकप्रिय सवालों और व्यक्तिगत संदेशों और टिप्पणियों का जवाब दूंगा।

साक्षात्कार के लिए वेतन की व्यवस्था कैसे करें

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

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

मैं काम की तलाश करने से पहले पढ़ने की सलाह देता हूं।

भर्ती करने पर कुछ विचार

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

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

यह मुझे लगता है कि, दुर्भाग्य से, कुछ भी भर्ती पर निर्भर नहीं करता है। एक भर्तीकर्ता जो कुछ भी कर सकता है, वह आवश्यक प्रोफ़ाइल के विशेषज्ञों के यथासंभव संपर्कों को खोजने और उन सभी के लिए एक प्रस्ताव भेजने के लिए है। इसके बाद, आपको प्रतीक्षा करने और यह उम्मीद करने की आवश्यकता है कि उनमें से एक या तो झिझक रहा है या एक सक्रिय नौकरी खोज में है। यही है, आधार के साथ काम का 20% और भाग्य का 80% है। नेटवर्क में बहुत सारी सामग्रियां हैं कि रिक्तियों को सही तरीके से कैसे बनाया जाए, और इसी तरह, लेकिन मेरे लिए, मुख्य कारक ठीक यही है कि उम्मीदवार नौकरियों को बदलने की इच्छा रखते हैं।

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

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

किसी कंपनी या प्रोजेक्ट में व्यस्त होना

हमारी वास्तविकताओं में - निश्चित रूप से एक परियोजना के लिए।

एक शीर्षक कैसे चुनें

मैंने खुद को वरिष्ठ सॉफ्टवेयर इंजीनियर और उच्चतर - टीम / टेक लीड, प्रिंसिपल इंजीनियर, सॉफ्टवेयर आर्किटेक्ट, प्रोजेक्ट मैनेजर, पीपल / ग्रुप मैनेजर और इतने पर एक उम्मीदवार के रूप में तैनात किया। यह "सीनियर +" में "ऊपर" का मतलब "+" है।

यह मुझे लगता है कि शीर्षक का मतलब कुछ भी नहीं है। एकमात्र महत्वपूर्ण बात यह है कि आप वास्तव में क्या करेंगे, और यह केवल उस व्यक्ति से पता लगाया जा सकता है जिसके साथ आप काम करेंगे।

तो, महिलाओं और सज्जनों, चलो तकनीकी साक्षात्कार के लिए आगे बढ़ते हैं।

स्टेज दो। तकनीकी साक्षात्कार

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

डिस्क्लेमर: लेखक एक टर्बोजाइनर-ओलंपियाड नहीं है, इसलिए कुछ निर्णय या टिप्पणियां मुस्कुराहट, एक बट-चोट, लेखक को अपनी गलतियों या कम योग्यता की ओर इशारा करने का कारण बन सकती हैं। मैं निर्माण को सुनकर प्रसन्न हूं।

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

परीक्षण कार्य

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

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

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

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

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

क्या यह खोज मेरे लिए मददगार थी? निश्चित रूप से हाँ! अब मुझे पता चलेगा कि वैग्रांत और शेफ से आपको दूर रहने की जरूरत है :)

समय बिताया - 8 घंटे ।

दुर्भाग्य से, मेरे पास इस प्रकार के कार्यों के बारे में अधिक कहानियां नहीं हैं, क्योंकि सामान्य रूप से इतने सारे परीक्षण नहीं थे :(

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

रूबी सॉफ्टवेयर इंजीनियर की स्थिति। वे मुझे एक कस्टम टेस्ट के लिए, निश्चित रूप से टेस्टडोम वेबसाइट की एक लिंक भेजते हैं। मैं क्लिक करता हूं, वास्तविक परीक्षणों में शामिल होता हूं। उन्होंने मुझे पूरे सेट को पूरा करने के लिए 2.5 घंटे दिए, प्रत्येक प्रश्न के लिए 5-20 मिनट दिए। वास्तव में, मुझे वास्तव में पसंद आया, मैं लंबे समय से ऐसी चीजों से नहीं गुजरा। मुझे विशेष रूप से TDD दृष्टिकोण पसंद आया: मैंने कोड किया, लॉन्च किया, देखा कि क्या गिर गया, आप आगे कोड करते हैं। बड़े मजे से गुजरे।

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

मैंने केवल एक घंटे में 93/100 अंक के लिए कार्य पूरा किया। दुर्भाग्य से, इस परिणाम ने मुझे भविष्य में बिल्कुल मदद नहीं की।

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

समय बिताया - 1 घंटा।

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

"यहां रिपॉजिटरी है, एक कार्य है, एक समाधान के साथ एक पुल अनुरोध भेजें" - मुझे ऐसा कोई विकल्प नहीं मिला, लेकिन मेरे सहयोगियों ने इसका इस्तेमाल किया। मैं वास्तव में उसे पसंद नहीं करता, क्योंकि आप देख सकते हैं कि अन्य उम्मीदवारों ने कैसे कार्य किया (यदि वे थे)।

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

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

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

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

परीक्षण वस्तुओं के लिए मेरी सिफारिशें?

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

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

तकनीकी साक्षात्कार। परिचय

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

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

समाचार समूह में उचित संचार के बारे में एक महत्वपूर्ण टिप: जब कोई अन्य व्यक्ति बोल रहा हो, और हेडसेट पर बात कर रहा हो, या नहीं, तो उदाहरण के लिए, बाहरी लैपटॉप माइक्रोफोन और बाहरी स्पीकर के माध्यम से कीबोर्ड पर न बोलने या टाइप करने की आदत डालें।

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

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

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

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

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

और अब एक अप्रत्याशित तथ्य।

कोई भी आपका रिज्यूमे नहीं पढ़ता है

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

: « , ». , ( , ). , , .

, .

, , 10 . CV, , , .

CV , . , , .

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

किसी को आपकी जरूरत नहीं है

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

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

मैंने इंजीनियरों के साथ केवल कुछ बातचीत की, जिसमें पता चला कि हां, उन्हें वास्तव में लोगों की आवश्यकता है, वे एक अच्छे विशेषज्ञ को नियुक्त करना चाहते हैं, उनके पास मेरे लिए एक योजना है और इसी तरह। और इसलिए हम अगले पैराग्राफ पर चलते हैं।

आप अपने भविष्य के बॉस या टीम लीडर से बात नहीं करेंगे

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

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

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

. , CTO CEO. , . , , . , .
, , (, ).

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