किसी प्रोजेक्ट पर जावा डेवलपर के विशिष्ट कार्य

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

1. नए समाधान डिजाइन करना

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

2. नई कार्यक्षमता लिखना

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

3. लेखन परीक्षण

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

4. बग ढूंढना और ठीक करना

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

5. कोड समीक्षा

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

6. कोड विश्लेषण

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

7. रीफैक्टरिंग कोड

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

8. प्रलेखन लिखना

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

9. विभिन्न बैठकें

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

10. साक्षात्कार आयोजित करना/उत्तीर्ण करना

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