बेहतर डेवलपर्स को कैसे काम पर रखें

[नोट] यह एक काम पर रखने वाली कंपनी के दृष्टिकोण से या एक कर्मचारी के दृष्टिकोण से लिखा गया लेख है जो अच्छे और सक्षम सहयोगियों के लिए चाहेंगे।

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

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

  1. मूर्खतापूर्ण प्रश्न न पूछें

किसी व्यक्ति से यह पूछना कि व्हेल के शव के अंदर कितने अनानास बस फिट हैं, यह देखने के लिए कि क्या यह आपके आकस्मिक ’जादू’ के परिणाम के साथ फिट बैठता है, किसी के लिए भी मदद करने वाला नहीं है, विशेष रूप से डेवलपर के मस्तिष्क की नहीं।

2. स्पॉट कार्यों पर दबाव डालने और / या समय लेने वाली या अत्यधिक जटिल सेटिंग से बचें

जब तक आपकी कंपनी वास्तव में c ** p नहीं है, तब तक सबसे अधिक संभावना है कि 20 मिनट में एक फीचर को जारी करने की आवश्यकता नहीं होगी, और मुझे पूरा यकीन है कि इसमें बैकट्रैकिंग या बाइनरी ट्रीज़ शामिल नहीं होंगे, न ही हेमैप्स का उपयोग करके ओ (एन) अनुकूलन।

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

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

3. कागज पर कोड लिखना (विशेष रूप से भाषा-विशिष्ट कोड)

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

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

लेकिन .. क्या एक अच्छे डेवलपर को यह जानने की जरूरत है कि 4 प्रकार की छंटाई कैसे करें? मुझे शक है।

क्या वास्तव में मायने रखता है इसे सिर्फ पढ़ने के द्वारा समझने में सक्षम है और प्रत्येक में अंतर और विशिष्टताओं का पता लगाने में सक्षम है।

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

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

4. उस तकनीक / भाषा के बारे में एपीआई सवाल पूछना बंद करें जो उस बारे में नहीं है। इसके बजाय अवधारणाओं के लिए देखें

मेरे कहने का मतलब यह है कि किसी से यह पूछना कि मोंगोबीडी ऑपरेशन के लिए क्वेरी लैंग्वेज / सिंटैक्स की कितनी हिस्सेदारी है, इसका कोई मतलब नहीं है ... मुझे लगता है कि जो लोग दिल से एपीआई सिंटैक्स को पूरी तरह से याद करते हैं, वे आमतौर पर इसे भूल जाने वाले लोगों की तुलना में ज्यादा खराब डेवलपर्स होते हैं।

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

अब आपका पोवा कहां है?

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

SQL API याद रखना एक और उदाहरण है, this आप इसे कैसे बनाते हैं या यह और वह ऑपरेशन ’। आपको यह याद रखने की आवश्यकता नहीं है कि आपके जीवन के बाकी हिस्सों के लिए, यदि आपको संबंधपरक डेटाबेस का मूल विचार मिलता है, तो एक अच्छा डेवलपर आपको अलग-अलग राज्य म्यूटेशन बताने में सक्षम हो सकता है और जिस तरह से संचालन इन प्रकार के डेटाबेस में किया जाता है, व्यापार-बंद जो उनके साथ आते हैं।

और वह भी बिना किसी एपीआई उपयोग के केवल मामूली के साथ।

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

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

5. हाँ, लेकिन क्या आप वास्तव में इस ढांचे को जानते हैं? आपको इसके साथ कितना अनुभव है?

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

इसका व्यावहारिक उपयोग करने के लिए रिएक्ट स्वयं एक 2-3 दिनों का मूल्य है, क्या यह आपकी कंपनी के लिए 'समय बर्बाद' है? यदि ऐसा है, तो शायद यह एक बकवास कंपनी है, इसलिए इसे बदलने की जहमत नहीं उठानी चाहिए ... कृपया चलते रहें और फिर चले जाएँ:

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

और अधिक उपयोगी। उससे पूछें कि वह उसके बारे में क्या पसंद करता है और वह क्या नहीं करता है, इससे आपको उसकी गहराई का एक अच्छा और अच्छा विचार देना चाहिए, यदि आप वास्तव में हैं (किसी कारण से)

6. एक अच्छे डेवलपर को पता होना चाहिए कि चीजों को कैसे देखना है

मुझे लगता है कि यह वह हिस्सा है जो एक ताजा ग्रेड / जूनियर और एक मध्य-स्तर या वरिष्ठ डेवलपर के बीच अंतर करता है।

अधिक जानकारी की तलाश करने, प्रलेखन पढ़ने और अन्य बिंदुओं को देखने के लिए अपने लिए उत्तर खोजने की क्षमता।

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

7. आप X साल के समय में खुद को कहां देखते हैं

यदि वह इस खोज पर प्रतिक्रिया देता है ... केवल मजाक कर रहा है ... बस कृपया मत करो, यह प्रश्न इसके स्वयं के एक भाग के लिए योग्य है क्योंकि यह अन्य बेवकूफ प्रश्नों को अच्छा बनाता है।

8. हर किसी के लिए इसे मजेदार बनाकर अपने तकनीकी कौशल की बेहतर जानकारी प्राप्त करें

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

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

इसके अलावा, अब आप देख सकते हैं कि वह कितनी तेजी से ’अपना ढांचा नाम सम्मिलित कर सकता है’।

9. अपने बारे में उनकी राय पर ध्यान न दें

हुह?

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

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

यदि इस प्रकार के प्रश्नों में से कोई उपयोगी तकनीकी जानकारी प्राप्त करना आपका लक्ष्य है, तो आपको उन्हें पहले ही छोड़ देना चाहिए।

10. खुद को साबित करने के लिए पर्याप्त समय देना

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

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

___________________________________________________________________

पढ़ने के लिए धन्यवाद :)।

जानबूझकर लिंग विशिष्ट सर्वनाम (वह / वह) लिखने से बचने की कोशिश की गई क्योंकि यह 2016 है और मैं अलैंगिक लोगों और कुछ प्रजातियों के समुद्री जानवरों से बचना चाहता हूं। मुझे समुद्री घोड़े बहुत पसंद हैं।