जावा डेव्हलपरची प्रोजेक्टवरील ठराविक कामे

Java विकासकाच्या विशिष्ट जबाबदाऱ्या काय आहेत? शेवटी, तुम्हाला हे समजून घेणे आवश्यक आहे की तुम्ही स्वतःला कशात अडकत आहात आणि तुम्ही काय करणार आहात, बरोबर? आज मी जावा डेव्हलपर करत असलेल्या दहा महत्त्वाच्या कामांबद्दल बोलू इच्छितो. परंतु प्रथम, जिरा नावाच्या साधनाशी परिचित होऊ या. किंवा तुमची स्मृती रिफ्रेश करा, जर तुम्हाला ते आधीच माहित असेल. जिरामानवी परस्परसंवाद आयोजित करण्याचे साधन आहे, जरी काही प्रकरणांमध्ये ते प्रकल्प व्यवस्थापनासाठी देखील वापरले जाते. दुसऱ्या शब्दांत, एक प्रकल्प या साधनामध्ये वर्णन केलेल्या लहान कार्यांमध्ये विभागलेला आहे. ही कार्ये विकासकांना नियुक्त केली आहेत, जे त्यांच्या अंमलबजावणीसाठी जबाबदार आहेत. एखादे कार्य असू शकते, उदाहरणार्थ, काही कार्यक्षमता जोडणे. एखादे कार्य पूर्ण केल्यावर, विकासक आणि इतर तज्ञ कोणी काय केले आणि किती वेळ घालवला याबद्दल टिप्पण्या जोडतात. हे वेळेचा मागोवा घेण्याच्या उद्देशाने केले जाते — कोणत्या कामांवर किती वेळ घालवला गेला हे जाणून घेण्यासाठी. तद्वतच, हे दिवसातून एकदा केले जाते: आपण संध्याकाळी आपले डेस्क सोडण्यापूर्वी, आपण आपल्या 8 कामाच्या तासांपैकी किती वेळ विविध कामांसाठी खर्च केला हे सूचित करता. वर वर्णन केलेल्या पेक्षा जिराच्या कार्यक्षमतेत बरेच काही आहे, परंतु हे प्रारंभिक समजण्यासाठी पुरेसे असेल.

1. नवीन उपायांची रचना करणे

तुम्ही एखादी गोष्ट तयार करून अंमलात आणण्याआधी, तुम्हाला ती संकल्पना करायची आहे, बरोबर? मी आधी म्हटल्याप्रमाणे, हे फक्त जिरा मधील एक कार्य असू शकते जे तुम्हाला नियुक्त केले जाईल, म्हणून तुम्ही एक नवीन उपाय डिझाइन करण्यासाठी काम करता, तुम्ही किती वेळ आणि कशावर खर्च केला हे जिरामध्ये रेकॉर्ड करा. हे कार्य टीम कॉन्फरन्स कॉलवरील चर्चेदरम्यान देखील होऊ शकते: प्रत्येकजण त्यांचे मत व्यक्त करू शकतो आणि त्यांना सर्वोत्तम वाटणारा दृष्टिकोन प्रस्तावित करू शकतो. आणि येथे मी काही मुद्दे लक्षात घेऊ इच्छितो. प्रथम, सॉफ्टवेअर डेव्हलपमेंट हा एक अतिशय सर्जनशील व्यवसाय आहे, कारण समस्या सोडवण्याचे नवीन मार्ग शोधण्यासाठी तुम्हाला मानक साधने वापरण्याची आवश्यकता आहे. एका कार्यात अनेकदा अनेक भिन्न उपाय असू शकतात. त्यानुसार, सर्व काही विकसकाच्या सर्जनशीलतेवर अवलंबून असते, जे त्यांच्या संचित ज्ञान आणि अनुभवाने जोरदारपणे प्रभावित होते. तुम्ही तुमची सर्व सर्जनशीलता आणि प्रतिभा येथे दाखवू शकता, पण महत्त्वाची गोष्ट म्हणजे ते जास्त करू नका. तुम्ही असे केल्यास, कोड खूप गुंतागुंतीचा आणि वाचण्यायोग्य होईल. परिणामी, तुम्ही सोडल्यानंतर, तुम्ही काय कोड केले आहे आणि ते कसे कार्य करते हे कोणालाही पूर्णपणे समजणार नाही. आणि त्यांना सुरवातीपासून सर्वकाही पुन्हा लिहावे लागेल. आणि ते तुमच्याबद्दल आठवण करून देऊ शकतात. एकापेक्षा जास्त वेळा. आणि उबदार, दयाळू शब्द बोलले जाण्याची शक्यता नाही. तुम्हाला याची गरज आहे का? दुसरे, विकसकाने या अर्थाने मानसिक लवचिकता टिकवून ठेवली पाहिजे की, तुम्ही एकाच उपायाला चिकटून राहू नये आणि इतरांबद्दल बंदिस्त होऊ नये. जणू काही तुम्हाला फक्त एकाच मार्गाने काहीतरी करायचे आहे आणि इतर कोणतेही पर्याय नाहीत. तुम्ही विविध कारणांमुळे या सापळ्यात पडू शकता. उदाहरणार्थ, समजा तुम्हाला तुमचा दृष्टिकोन बरोबर आहे हे सिद्ध करायचे आहे. किंवा कदाचित तुम्ही तुमचे स्वतःचे परिचित समाधान आधीच डिझाइन केले असेल आणि अंमलात आणले असेल — अर्थातच, आपण हे सर्वोत्कृष्ट नाही हे मान्य करू इच्छित नाही. या परिस्थितींमुळे तुम्हाला आंधळे होऊ शकतात. खरं तर, तुम्‍हाला तुमच्‍या चुका कबूल करण्‍यास आणि नेहमी मोकळेपणाने असण्‍याची आवश्‍यकता आहे, जरी तुम्‍हाला अभिमान वाटत असलेल्‍या आणि एका आठवड्यापेक्षा जास्त काळ कोडिंग करत असल्‍याची कार्यक्षमता काढून टाकावी लागली तरीही. मला आठवते की एका सहकार्‍याने जिरामध्ये ही टाइम-ट्रॅकिंग टिप्पणी देऊन प्रत्येकाचा दिवस कसा उजळला: "मी माझे मृत जन्मलेले वैशिष्ट्य काढून टाकले. आणि शोक केला."

2. नवीन कार्यक्षमता लिहिणे

ही पायरी — नवीन कार्यक्षमता अंमलात आणणे — मागील एकानंतर तार्किकपणे अनुसरण करते. प्रकल्पात गुंतलेली सर्व कामे जिरामधील कार्यांमध्ये विभागली जातात, जी नंतर विकासकांना त्यांच्या वर्कलोडवर आधारित दिली जातात. या प्रक्रियेसाठी विविध पध्दती आहेत, ज्यांना "पद्धती" म्हणून ओळखले जाते, ज्याबद्दल तुम्ही CodeGym वरील या लेखात अधिक तपशीलवार वाचू शकता . नियमानुसार, कार्यांचा अंदाज आहे, जे त्यांना पूर्ण करण्यासाठी लागणारा अंदाजित वेळ आहे. हे एकतर तुमच्याद्वारे, विकासकाने तुम्हाला टास्क मिळाल्यावर किंवा टीम लीडद्वारे, किंवा नियोजनादरम्यान, विकास कार्यसंघाद्वारे एकत्रितपणे सेट केले जाते. या वेळेचा अंदाज फार क्वचितच अचूक असतो, कारण सॉफ्टवेअर डेव्हलपमेंटवर अनेक भिन्न घटक परिणाम करतात. उदाहरणार्थ, एखादा प्रोग्रामर संबंधित तंत्रज्ञानाशी परिचित किंवा अपरिचित असला तरी, त्याचा किंवा तिचा एकूण अनुभव, विविध अनपेक्षित तोटे इ. त्यामुळे, जर तुम्ही कोडिंग करताना तुमच्या वेळेचा अंदाज लावला नाही, तर जगाचा अंत नाही. हे फक्त सामान्य अंदाज आहेत. ते म्हणाले, सर्व प्रकल्पांना वेळेचा अंदाज लागत नाही. वैयक्तिकरित्या, मला त्याशिवाय जगणे खूप सोपे वाटते, विशेषत: जेव्हा पंतप्रधान मला दिवसातून दोन वेळा "तुमच्या वेळेचा अंदाज कुठे आहे?" असा प्रश्न विचारत नाहीत. तर, तुम्हाला एक कार्य मिळेल,पुनरावलोकनासाठी सज्ज " जिरा मध्ये आणि प्रार्थना करा की तुमचे कोड बदल टिप्पण्यांसह पुनरावृत्तीसाठी परत येऊ नयेत.

3. लेखन चाचण्या

समीक्षकाला, म्हणजे तुमचा कोड तपासणार्‍या व्यक्तीला तुम्ही लागू केलेली कार्यक्षमता आवडते, परंतु तिला तुमच्यासाठी एक प्रश्न आहे: संबंधित चाचण्या कोठे आहेत? त्यामुळे ती तुमच्याकडे हे टास्क रिव्हिजनसाठी परत पाठवते. चाचण्या कोणत्याही Java ऍप्लिकेशनचा आवश्यक भाग आहेत. चाचण्या चालवून, तुम्ही ताबडतोब अशी ठिकाणे ओळखू शकता जिथे अनुप्रयोग योग्यरित्या कार्य करत नाही. उदाहरणार्थ, डेव्हलपर सिस्टमच्या एका भागात काही बदल करतो, ज्यामुळे दुसऱ्या भागात वर्तनात बदल होतो, परंतु कोडिंग करताना त्याला हे लक्षात आले नाही. चाचण्या चालवून, तो हे पाहण्यास सक्षम असेल की काही चाचण्या अयशस्वी झाल्या, म्हणजे त्यांनी अपेक्षित परिणाम दिले नाहीत. हे त्याला सांगते की सिस्टममध्ये कुठेतरी काहीतरी तुटलेले आहे. हे जाणून घेतल्यावर, तो सर्व्हरमध्ये ब्रेकिंग बदल करणार नाही आणि त्याऐवजी त्याचा कोड डीबग करण्याचे काम सुरू ठेवेल. होय, त्याऐवजी काही डेव्हलपरना चाचण्या लिहिणे आवडते, परंतु सॉफ्टवेअर डेव्हलपमेंटमध्ये त्यांचे फायदे नाकारता येत नाहीत. क्लायंट स्वतः अनेकदा चाचणी कव्हरेजची पातळी दर्शवितात जे ते राखू इच्छितात (उदाहरणार्थ, 80%). याचा अर्थ असा आहे की आपल्याला माहित असणे आवश्यक आहेविविध प्रकारच्या चाचण्या आणि त्या लिहिण्यास सक्षम व्हा. जावा डेव्हलपर प्रामुख्याने युनिट चाचण्या आणि एकत्रीकरण चाचण्या लिहितात, तर अधिक विस्तृत (एंड-टू-एंड) चाचण्या QA आणि चाचणी ऑटोमेशन तज्ञांद्वारे हाताळल्या जातात.

4. बग शोधणे आणि निराकरण करणे

जावा डेव्हलपरसाठी हे देखील एक अतिशय सामान्य, वारंवार काम आहे. QA आणि चाचणी ऑटोमेशन तज्ञांचे मुख्य काम बग पकडणे आहे. दुस-या शब्दात सांगायचे तर, ते अशी ठिकाणे शोधतात जिथे प्रोग्राम चुकीचे वागतो, नंतर ते जिरामध्ये कार्ये तयार करतात आणि एखाद्याला नियुक्त करतात. उदाहरणार्थ, टीम लीडकडे, जो बदल्यात, त्यांच्या कामाचा भार आणि सिस्टीमच्या संबंधित भागांच्या परिचयावर अवलंबून, कोणते विकासक त्यांना नियुक्त करायचे ते ठरवतो. त्यानंतर, नियुक्त केलेला विकासक दोषाचे मूळ कारण शोधतो, डीबगरमध्ये तास घालवतो, QA तज्ञांनी प्रदान केलेल्या बग वर्णनाचा वापर करून दोष उद्भवलेल्या परिस्थितीचे पुनरुत्पादन करणे. एकदा विकासकाला दोष सापडला आणि त्याचे निराकरण केले की, तो निराकरण पुनरावलोकनासाठी पाठवतो. काहीवेळा विकासक बगचे पुनरुत्पादन करू शकत नाही, म्हणून तो स्पष्टीकरणात्मक टिप्पणीसह कार्य परत QA तज्ञाकडे पाठवतो. बग शोधण्यासाठी आणि त्याचे निराकरण करण्यात फार वेळ लागणार नाही असे दिसते, परंतु काही बारकावे आहेत. हे सर्व प्रामुख्याने कोडच्या या विभागाशी विकसक किती चांगले परिचित आहे यावर आणि त्याच्या अनुभवावर आणि सैद्धांतिक ज्ञानावर अवलंबून असते. काहीवेळा एक बग सापडतो आणि 20 मिनिटांत त्याचे निराकरण केले जाऊ शकते आणि काहीवेळा यास तीन दिवस लागू शकतात. याचा अर्थ असा आहे की या प्रकारच्या कार्याचा आगाऊ अंदाज लावणे विशेषतः कठीण आहे, जोपर्यंत विकसक, वर्णन वाचून, दोष काय, कुठे आणि कसे हे लगेच समजत नाही. या प्रकरणात,

5. कोड पुनरावलोकन

वर नमूद केल्याप्रमाणे, तुम्ही एखादे कार्य पूर्ण करताच, ते पुनरावलोकनासाठी पाठवले पाहिजे. जर तो रिव्ह्यू पास झाला तर तो मुख्य शाखेत जातो. नसल्यास, ते विकसकाकडे टिप्पण्यांसह परत केले जाते ज्यांना संबोधित करणे आवश्यक आहे. अर्थात, तुम्हाला समजले आहे की तुमचा कोड सर्व डेव्हलपरद्वारे तपासला जातो, काही उच्च शक्तीने नाही. असे म्हटले आहे की, प्रत्येकाला कोड पुनरावलोकने करण्याची परवानगी नाही — केवळ सर्वात अनुभवी विकासक वास्तविक-जगातील सरावाने कठोर होतात, जे चांगले कोड आणि वाईट कोडमधील फरक सांगू शकतात. कोड पुनरावलोकने सहसा क्रूसिबल सारख्या सहाय्यक साधनाचा वापर करून केली जातात. पुनरावलोकनकर्ते कोडमधून जातात आणि आवश्यक असल्यास, काही ओळींबद्दल टिप्पण्या देतात. विविध प्रकारच्या टिप्पण्या असू शकतात. उदाहरणार्थ, काही गंभीर आहेत. जर त्यांना संबोधित केले गेले नाही, तर पुनरावलोकनकर्ता कोडला वचनबद्ध करण्याची परवानगी देणार नाही. इतर टिप्पण्या आहेत, म्हणा, फक्त निवडलेल्या पद्धतीबद्दलच्या टिप्पण्या. विकासक हे ऐकू शकतात, लक्षात घेऊ शकतात किंवा दुर्लक्ष करू शकतात. एक कार्यसंघ कोड पुनरावलोकनांसाठी स्वतःचे नियम आणि कार्यपद्धती तयार करू शकतो, कोणत्या गोष्टीकडे लक्ष देणे योग्य आहे आणि काय नाही, कोड पुनरावलोकन पूर्ण करण्यासाठी कोणती कालमर्यादा दिली जावी इ. तुमची तांत्रिक कौशल्ये आणि विविध पुस्तके वाचण्याची गरज आहे (उदाहरणार्थ, "क्लीन कोड").

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

प्रकल्पासाठी भिन्न विचार करणारे अनेक लोक एकाच वेळी कोड लिहित असल्याने, त्यांचे कोड आणि दृष्टिकोन भिन्न असतील. आणि कालांतराने, सर्वकाही हळूहळू गोंधळात बदलते. कोड सुधारण्यासाठी, काही वेळा विशिष्ट मॉड्यूल किंवा संपूर्ण अनुप्रयोगाचे विश्लेषण करणे, त्रुटी शोधणे आणि लक्षात घेणे आणि नंतर या विश्लेषणावर आधारित रिफॅक्टरिंग कार्य तयार करणे अशी कार्ये तयार केली जातात. असे विश्लेषण अशा परिस्थितीतही मदत करते जेव्हा, जेव्हा विकास सुरू झाला तेव्हा संघ काही सोप्या, अधिक संक्षिप्त उपाय पाहू शकला नाही, परंतु ते आता ते पाहतात. उदाहरणार्थ, तर्कशास्त्र बहुतेकदा काही पद्धतींमध्ये डुप्लिकेट केले जाते. त्यानुसार, ते वेगळ्या पद्धतीने काढले जाऊ शकते, जे नंतर अनेक वेळा पुन्हा वापरले जाऊ शकते. किंवा कदाचित एखादा वर्ग खूप फुगलेला आहे, किंवा काही कोड राखणे कठीण झाले आहे किंवा कालबाह्य झाले आहे, किंवा... विश्लेषण कार्ये कोड आणि अनुप्रयोगाची गुणवत्ता सुधारण्यास मदत करतात. ते म्हणाले, माझ्यासाठी, मोठ्या प्रमाणात कोडचे विश्लेषण करणे कंटाळवाणे असू शकते.

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

कोड विश्लेषणाचा पुढील भाग म्हणजे रिफॅक्टरिंग. कोड कालबाह्य, अप्रचलित, खराब लिहिलेले, वाचण्यास कठीण इत्यादी असू शकते. तुम्ही नेहमी परिपूर्णतेसाठी (जरी ते अस्तित्वात नसले तरी) आणि अद्ययावत कोडसाठी, अनावश्यक काहीही काढून टाकण्याचा प्रयत्न केला पाहिजे, कारण अनावश्यक केवळ गोंधळात टाकते आणि कोड काय करत आहे हे पाहण्याच्या क्षमतेमध्ये हस्तक्षेप करते. प्रकल्पाच्या सुरुवातीला ही कार्ये तुम्हाला दिसण्याची शक्यता नाही असे म्हणता येत नाही: जेव्हा ऍप्लिकेशन पॉलिश केले जाते आणि परिपूर्णतेकडे आणले जाते तेव्हा विकासाच्या नंतरच्या टप्प्यावर तुमचा सामना होतो. येथे, सहकार्‍यांशी ते काय करतील आणि त्यांना कोणते नुकसान दिसतील याबद्दल सल्ला घेणे योग्य ठरेल. त्यांच्या हृदयावर, अशी कार्ये नवीन कार्यक्षमता विकसित करण्यासारखीच असतात. उदाहरणार्थ, समजा तुम्हाला एखादे कार्य प्राप्त झाले आहे ज्याचे वर्तन न बदलता काही कार्यक्षमता संपादित करा. हे करण्यासाठी, तुम्ही जुना कोड हटवा, तुमचा स्वतःचा लिहा आणि चाचण्या तपासा. जर तुम्ही सर्वकाही बरोबर केले असेल, तर चाचण्यांमध्ये कोणतेही बदल न करता, ते सर्व पूर्वीप्रमाणे उत्तीर्ण झाले पाहिजेत. कोडमधील सर्वकाही जसे असावे तसे झाल्यानंतर, आम्ही ते पुनरावलोकनासाठी पाठवतो आणि कॉफी प्या :)

8. दस्तऐवजीकरण लेखन

कल्पना करा की तुम्ही काही दीर्घकालीन सॉफ्टवेअर डेव्हलपमेंट प्रोजेक्टवर नवीन डेव्हलपर आहात. तुम्हाला कोड बेसशी परिचित होणे किंवा काही विशिष्ट कार्य करणे आवश्यक आहे, उदाहरणार्थ, बगचे निदान करा. आपण प्रकल्प कसे नेव्हिगेट कराल? दर पाच मिनिटांनी तुमच्या सहकाऱ्यांना त्रास द्या? आणि जर ते व्यस्त असतील किंवा शनिवार व रविवार असेल तर काय? यामुळेच आमच्याकडे दस्तऐवज आहेत — जेणेकरुन कोडशी परिचित नसलेली एखादी व्यक्ती आत येऊ शकते, संबंधित पृष्ठ शोधू शकते आणि तिला स्वारस्य असलेल्या अनुप्रयोगाच्या भागामध्ये काय चालले आहे ते त्वरीत शोधू शकते. पण कोणीतरी डॉक्युमेंटेशन तयार करावे लागेल, हाहा. जर एखाद्या प्रकल्पात विकासकांनी समर्थन केले पाहिजे असे दस्तऐवज असल्यास, जेव्हा ते नवीन कार्यक्षमतेची अंमलबजावणी करतात तेव्हा ते त्याचे वर्णन करतात आणि कोणत्याही कोड बदलांसह किंवा रिफॅक्टरिंगसह दस्तऐवजीकरण अद्यतनित करतात. कागदपत्रे लिहिण्यासाठी, देखरेख करण्यासाठी आणि पर्यवेक्षण करण्यासाठी एक स्वतंत्र कर्मचारी — तांत्रिक लेखक — नियुक्त केला जातो अशा परिस्थिती तुमच्याकडे देखील असू शकतात. असा तज्ञ उपलब्ध असल्यास सामान्य विकासकांचे जीवन थोडे सोपे होते.

9. विविध बैठका

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

10. मुलाखती घेणे/उतीर्ण होणे

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