एक साक्षात्कारकर्ता उपकरण के रूप में जोएल का परीक्षण

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

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

मान लीजिए कि आपको यह हिस्सा पसंद आया और आपने इस प्रोजेक्ट पर आगे बढ़ने के बारे में सोचा। आप संभावित रूप से इन लोगों के साथ अगले कुछ वर्षों तक काम कर सकते हैं (ठीक है, कम से कम महीनों के लिए)। इसलिए, परियोजना के बारे में अधिक विस्तार से पूछना समझ में आता है। और एक ही समय में भविष्य के टीममेट्स का परीक्षण करने के लिए - वे किस प्रकार के मिर्च हैं? ;)

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

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

0. जोएल टेस्ट प्रोजेक्ट को कितने अंक मिलते हैं?

यदि वार्ताकार दावा करते हैं कि 6 या उससे कम - IMHO आप तुरंत अलविदा कह सकते हैं। यदि 7 या अधिक - तो आप लंबे समय तक बैठ सकते हैं और विवरण स्पष्ट कर सकते हैं। खासकर उन बिंदुओं के बारे में जिनके साथ सब कुछ बहुत अच्छा नहीं है। अगर किसी भी वार्ताकार को यह नहीं पता है कि जोएल का परीक्षण क्या है और जोएल कौन है, यह विनम्रता से अलविदा कहने और छोड़ने के लिए समझ में आता है;)

1. क्या आप एक संस्करण नियंत्रण प्रणाली का उपयोग करते हैं?

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

और Kamenty से एक महान इसके अलावा - लोगों द्वारा भंडार में एकीकरण से पहले कोड की जाँच की जाती है ? दूसरे शब्दों में, क्या परियोजना पर एक कोड की समीक्षा है?

2. आप एक कदम में उत्पाद इकट्ठा कर सकते हैं?

क्या आपके समकक्षों को एक उत्पाद में विधानसभा / तैनाती / उनके उत्पाद का चौवास्त (या आपके पास वहां चुनने) पूरा हो सकता है? दो चरणों में? दूसरे शब्दों में, असेंबली स्वचालित है। यदि नहीं, तो यह पूछने का कोई मतलब नहीं है कि यह स्वचालित क्यों नहीं है। क्या इसे स्वचालित होने से रोकता है और इस तरह मानव संसाधन (और तंत्रिकाओं) को बचाता है? इस स्तर पर, परियोजना के बारे में बहुत सारी दिलचस्प बातें पता चल सकती हैं।

3. क्या आप दैनिक निर्माण करते हैं?

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

4. क्या आप एक त्रुटि डेटाबेस का उपयोग करते हैं?

फिर, अब हर कोई बगट्रैक का उपयोग करता है। इसलिए, यह दिलचस्प है: क्या बगट्रैकर का उपयोग किया जाता है? इसके आसपास क्या प्रक्रियाएँ बनती हैं? कौन, कैसे और किसके लिए टिकट फेंकता है? क्या यह सुविधाजनक है? आप वर्तमान बग ट्रैकर या इसके आसपास की प्रक्रियाओं के बारे में क्या नापसंद करते हैं? ट्रैकर (बग्स, फीचर्स, बैकपोर्ट्स, रेगुलर टास्क) में कौन सी एक्टिविटी दर्ज होती है और कौन सी नहीं।

5. क्या आप नया कोड लिखने से पहले त्रुटियों को ठीक करते हैं?

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

ठीक है, या सिर्फ परियोजना पर सभी FSUs और लोगों को बस हथौड़ा। क्या आप ऐसी परियोजना में काम करना चाहते हैं?

6. क्या आपके पास अप-टू-डेट कार्य योजना है?

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

7. क्या आपके पास एक विनिर्देश है?

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

8. क्या आपके प्रोग्रामर को आराम से काम करने का माहौल प्रदान किया गया है?

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

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

9. क्या आप काम करने के लिए उपलब्ध सर्वोत्तम उपकरणों का उपयोग करते हैं?

क्या इंजीनियरों को काम के लिए आधुनिक कंप्यूटर दिए गए हैं या अप्रचलित लावा का उपयोग करने के लिए मजबूर किया गया है? क्या आपको OS, IDE, वर्ड प्रोसेसर, एंटीवायरस, आदि चुनने में स्वतंत्रता होगी? कार्यालय (परियोजना) में सभी सॉफ्टवेयर लाइसेंस प्राप्त है? विंडोज? वार्ड? यदि आपको $ 100 के लिए काम के लिए सॉफ़्टवेयर की आवश्यकता है, तो क्या आप इसके लिए लाइसेंस प्राप्त करेंगे? और $ 500 के लिए? और $ 1000 के लिए?

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

10. क्या आपके पास परीक्षक हैं?

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

11. क्या नौकरी के उम्मीदवारों को एक साक्षात्कार के दौरान एक कोड लिखना है?

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

12. क्या आप कार्यक्रम की उपयोगिता का गलियारा परीक्षण करते हैं?

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

कुछ इस तरह।

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

आप क्या पूछेंगे?