Java डेवलपर इंटरव्यू के सवाल और जवाब: 2026 गाइड

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

ये पैटर्न पूरे रोल के लिए हैं; अगर आपको किसी एक इंटरव्यू की शॉर्टलिस्ट चाहिए, तो असली जॉब पोस्टिंग फ्री Question Predictor और उस खास इंटरव्यू लूप में सबसे ज़्यादा आने वाले बीस सवाल पा लीजिए।

Java डेवलपर इंटरव्यू असल में क्या परखते हैं?

पांच इलाके, लगभग हमेशा: JVM और मेमोरी का बर्ताव, गार्बेज कलेक्शन, कलेक्शंस फ्रेमवर्क असली गहराई में, कंकरेंसी, और वह फ्रेमवर्क जिसमें टीम रहती है, जो लगभग हमेशा Spring होता है। इन सबके नीचे एक सवाल दबा रहता है जिसे कोई बोलकर नहीं पूछता: जब यह सर्विस रात 2 बजे प्रोडक्शन में बिगड़ेगी, तो क्या आप वजह पता कर पाएंगे?

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

Java इंटरव्यू प्रोसेस कैसा होता है?

एक आम लूप चार से छह चरणों का होता है: रिक्रूटर स्क्रीन, कोडिंग और फंडामेंटल्स मिलाकर एक टेक्निकल स्क्रीन, एक लंबा कोडिंग राउंड, एक डिज़ाइन राउंड, और हायरिंग मैनेजर से बातचीत। एंटरप्राइज़ और कंसल्टेंसी फंडामेंटल्स और Spring पर ज़ोर देती हैं; प्रोडक्ट कंपनियां डिज़ाइन और कंकरेंसी को ज़्यादा वज़न देती हैं। मिड-साइज़ कंपनियों में टेक-होम आम हैं और उनमें आम तौर पर एक छोटी Spring सर्विस बनानी होती है।

1. रिक्रूटर स्क्रीन (20 से 30 मिनट)। वर्ज़न, फ्रेमवर्क, स्केल, सैलरी बैंड। यह पता होना चाहिए कि आपका कोडबेस किस Java वर्ज़न को टारगेट करता है, क्योंकि "लेटेस्ट" कहकर फिर यह न बता पाना कि record क्या है, बहुत बुरा लगता है।
2. टेक्निकल स्क्रीन (45 से 60 मिनट)। शेयर्ड एडिटर पर कोडिंग और साथ में तेज़ फंडामेंटल्स: कलेक्शंस, एक्सेप्शन, इम्यूटेबिलिटी, स्ट्रीम्स।
3. कोडिंग राउंड (60 मिनट)। पहेली के बजाय एक प्रैक्टिकल समस्या: एक फाइल पार्स करके उसका जोड़ निकालना, एक छोटा कैश बनाना, एक थ्रेड-सेफ काउंटर लिखना।
4. डिज़ाइन राउंड (60 मिनट)। सर्विस डिज़ाइन या एक ऑब्जेक्ट-ओरिएंटेड एक्सरसाइज़, और सीनियर लूप में साथ में कैपेसिटी और फेल्योर मोड।
5. फ्रेमवर्क और गहराई वाला राउंड। Spring का बर्ताव, ट्रांज़ैक्शन, टेस्टिंग, और कभी-कभी एक रिव्यू एक्सरसाइज़ जिसमें आपको जानबूझकर खराब लिखी गई क्लास की समीक्षा करनी होती है।
6. हायरिंग मैनेजर या बिहेवियरल। इंसिडेंट, मतभेद, मेंटरिंग, और क्या आपका बताया हुआ लेवल बारीकियों में टिकता है।

अगर आप कंपनी जानते हैं, तो कंपनी सवाल बैंक फोरम खंगालने से कहीं तेज़ी से घर का तौर-तरीका बता देते हैं, क्योंकि खासकर बड़ी कंसल्टेंसी एक जैसी स्क्रिप्ट चलाती हैं।

JVM और मेमोरी के कौन से सवाल आ सकते हैं?

उम्मीद रखिए कि आपको सोर्स कोड से चलते हुए प्रोग्राम तक का रास्ता और वे मेमोरी हिस्से समझाने होंगे जिनमें आपके ऑब्जेक्ट रहते हैं। पैनल देख रहा है कि JVM आपके लिए ब्लैक बॉक्स तो नहीं। बायटकोड में कंपाइलेशन, क्लास लोडिंग, इंटरप्रिटेशन और फिर हॉट पाथ की just-in-time कंपाइलेशन, और हीप, थ्रेड स्टैक व मेटास्पेस के बंटवारे को कवर कीजिए, बिना इसे रटी हुई कहानी बनाए।

एक क्लास लिखने से लेकर उसके चलने तक क्या होता है, बताइए। यह क्या टटोलता है: क्या आप उस रनटाइम को समझते हैं जिस पर आप डिप्लॉय करते हैं। क्रम से चलिए: javac बायटकोड बनाता है, क्लास लोडर उसे लोड और लिंक करता है (parent delegation का नाम लेना काम आता है), इंटरप्रेटर चलाना शुरू करता है, और मेथड हॉट होने पर JIT कंपाइलर उन्हें ऑप्टिमाइज़ करता है, जिसमें inlining और deoptimisation असली बर्ताव हैं।

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

प्रोडक्शन में OutOfMemoryError का डायग्नोसिस आप कैसे करेंगे? यह क्या टटोलता है: असली ऑपरेशनल अनुभव। पहले पूछिए कि कौन सा OutOfMemoryError है, क्योंकि heap space, metaspace और थ्रेड बनाने की नाकामी की वजहें अलग-अलग हैं। फिर एरर पर हीप डंप लीजिए, dominator tree देखकर पता कीजिए कि retained set को कौन पकड़े हुए है, और GC लॉग में देखिए कि लगातार बढ़ोतरी है या एक अचानक उछाल।

गार्बेज कलेक्शन के कौन से सवाल आते हैं?

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

गार्बेज कलेक्शन असल में काम कैसे करता है? यह क्या टटोलता है: मैकेनिक्स, शब्दावली नहीं। रेफरेंस काउंटिंग के बजाय GC roots से reachability बताइए, यंग और ओल्ड जेनरेशन का बंटवारा, माइनर कलेक्शन का survivors को प्रमोट करना, और stop-the-world पॉज़ को वह चीज़ बताइए जो असल में तकलीफ देती है।

उपलब्ध कलेक्टरों में से आप चुनाव कैसे करते हैं? यह क्या टटोलता है: क्या आप टूलिंग को लेटेंसी टारगेट से मिलाते हैं। ज़्यादातर सर्वर वर्कलोड के लिए G1 समझदारी वाला डिफॉल्ट है और वह एक पॉज़ गोल पर निशाना लगाता है। ZGC और Shenandoah बड़े हीप पर बहुत कम पॉज़ के लिए थ्रूपुट की कीमत चुकाते हैं, जो तब मायने रखता है जब 300ms आपका बजट तोड़ देता हो।

आपकी सर्विस में 99वें परसेंटाइल पर 400ms के पॉज़ दिख रहे हैं। आप इस पर कैसे काम करेंगे? यह क्या टटोलता है: मापने का अनुशासन। कुछ भी छूने से पहले GC लॉगिंग चालू करके पक्का कीजिए कि पॉज़ सचमुच GC के हैं, क्योंकि लॉक कंटेंशन और धीमे डाउनस्ट्रीम कॉल भी ऐसी ही टेल बनाते हैं। अगर GC ही है, तो पहले एलोकेशन रेट देखिए, क्योंकि ज़्यादातर पॉज़ की समस्याएं दरअसल एलोकेशन की समस्याएं होती हैं।

Java कलेक्शंस के कौन से सवाल पूछे जाते हैं?

कलेक्शंस पूरे लूप का सबसे भरोसेमंद फिल्टर हैं, क्योंकि दावा हर कोई करता है कि उसे आते हैं और अंदरूनी कामकाज कम लोग समझा पाते हैं। तैयार रहिए कि HashMap कैसे बना है यह बता सकें, equals और hashCode का कॉन्ट्रैक्ट वैकल्पिक क्यों नहीं है, LinkedList सचमुच कब सही चुनाव है (कम ही), और कंकरेंट कलेक्शंस synchronised रैपर से कैसे अलग हैं।

HashMap अंदर से कैसे काम करता है? यह क्या टटोलता है: गहराई। कवर कीजिए: की को हैश करना, बिट्स को फैलाना, बकेट ऐरे में इंडेक्स करना, टकराव को एक लिस्ट में चेन करना जो बकेट लंबी होने पर बैलेंस्ड ट्री में बदल जाती है, और लोड फैक्टर पर बड़े ऐरे में rehash करके रीसाइज़ करना।

equals और hashCode के बीच कॉन्ट्रैक्ट क्या है, और उसे तोड़ने पर क्या बिगड़ता है? यह क्या टटोलता है: क्या आपने कभी इसे डिबग किया है। बराबर ऑब्जेक्ट के हैश कोड बराबर होने ही चाहिए; अलग ऑब्जेक्ट के हैश टकरा सकते हैं। इसे तोड़िए और HashSet में डाला गया ऑब्जेक्ट ढूंढा नहीं जा सकेगा, क्योंकि लुकअप गलत बकेट में चला जाएगा।

ArrayList या LinkedList: आप असल में LinkedList कब चुनेंगे? यह क्या टटोलता है: क्या आप किताबी कॉम्प्लेक्सिटी दोहराते हैं या हार्डवेयर के बारे में सोचते हैं। Big O इंसर्शन पर LinkedList को बेहतर बताता है, लेकिन व्यवहार में लगभग हर वर्कलोड में ArrayList जीतता है, क्योंकि लगातार मेमोरी कैश के अनुकूल होती है और पॉइंटर के पीछे भागना नहीं। LinkedList का बचाव मुख्य रूप से एक deque के तौर पर होता है, और वहां भी आम तौर पर ArrayDeque उससे बेहतर रहता है।

ConcurrentHashMap या synchronised map: फर्क क्या है? यह क्या टटोलता है: कंटेंशन की समझ। synchronised रैपर हर ऑपरेशन को एक ही लॉक पर कतार में लगा देता है; ConcurrentHashMap समानांतर रीड और lock-striped राइट की इजाज़त देता है, जिससे लोड में कहीं बेहतर थ्रूपुट मिलता है।

Java इंटरव्यूअर कंकरेंसी के कौन से सवाल पूछते हैं?

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

volatile क्या गारंटी देता है, और क्या नहीं? यह क्या टटोलता है: मेमोरी मॉडल। volatile विज़िबिलिटी और ऑर्डरिंग की गारंटी देता है: एक राइट दूसरे थ्रेड को दिखता है, और उसके आर-पार रीऑर्डरिंग पर रोक लगती है। यह एटॉमिसिटी की गारंटी नहीं देता, इसलिए volatile काउंटर बढ़ाना अब भी lost-update बग है, क्योंकि रीड, ऐड और राइट तीन अलग ऑपरेशन हैं।

थ्रेड पूल का साइज़ कैसे तय करते हैं, और convenience factory मेथड में क्या खराबी है? यह क्या टटोलता है: क्या आपने कभी पूल को फेल होते देखा है। convenience factory से बना fixed पूल एक अनबाउंडेड क्यू इस्तेमाल करता है, इसलिए ओवरलोड में वह पुशबैक करने के बजाय टास्क जमा करता रहता है जब तक हीप मर न जाए। इसे साफ तौर पर खुद बनाइए, बाउंडेड क्यू और रिजेक्शन पॉलिसी के साथ, और साइज़ वर्कलोड के हिसाब से रखिए।

डेडलॉक किस वजह से होता है और आप उसे कैसे रोकते हैं? यह क्या टटोलता है: सटीकता और व्यावहारिकता। डेडलॉक के लिए चार शर्तें चाहिए: mutual exclusion, hold and wait, no preemption, और circular wait, और आप इनमें से एक शर्त हटाकर उसे तोड़ते हैं, आम तौर पर एक ग्लोबल लॉक ऑर्डर से।

वर्चुअल थ्रेड किस काम के हैं, और कब मदद नहीं करते? यह क्या टटोलता है: क्या आप अपडेटेड हैं। वे ब्लॉकिंग IO को सस्ता बना देते हैं, इसलिए आप कोड को असिंक्रोनस चेन में मरोड़ने के बजाय सीधा ब्लॉकिंग कोड ऊंची कंकरेंसी पर लिख सकते हैं। वे CPU-बाउंड काम को तेज़ नहीं करते, और उन्हें पूल करना पूरी बात ही खत्म कर देता है।

Spring और Spring Boot के कौन से सवाल आते हैं?

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

डिपेंडेंसी इंजेक्शन समझाइए, और कंस्ट्रक्टर इंजेक्शन को क्यों बेहतर माना जाता है। यह क्या टटोलता है: क्या आप inversion of control समझते हैं या बस एनोटेशन लगाते हैं। कंस्ट्रक्टर इंजेक्शन डिपेंडेंसी को साफ और अनिवार्य बनाता है, final फील्ड की इजाज़त देता है, और क्लास को कंटेनर के बिना टेस्ट करने लायक बनाता है। फील्ड इंजेक्शन डिपेंडेंसी छिपा देता है, सर्कुलर रेफरेंस को बिना पकड़ में आए ज़िंदा रहने देता है, और टेस्ट के लिए रिफ्लेक्शन मांगता है।

@Transactional असल में कैसे काम करता है, और यह कब चुपचाप लागू नहीं होता? यह क्या टटोलता है: प्रॉक्सी। Spring बीन को एक प्रॉक्सी में लपेटता है जो कॉल के इर्द-गिर्द ट्रांज़ैक्शन खोलता और कमिट करता है, यानी self-invocation (एक ही क्लास के अंदर एक मेथड का दूसरे एनोटेटेड मेथड को कॉल करना) प्रॉक्सी को पूरी तरह बायपास कर देता है और बिना किसी ट्रांज़ैक्शन के चलता है।

ऑटो-कॉन्फ़िगरेशन कर क्या रहा है? यह क्या टटोलता है: जादू समझा गया है या उससे डर लगता है। Spring Boot कंडीशनल कॉन्फ़िगरेशन को इस आधार पर परखता है कि क्लासपाथ पर क्या है और आपने खुद क्या पहले से डिफाइन किया है, इसलिए कोई डिपेंडेंसी जोड़ने पर समझदार डिफॉल्ट अपने आप वायर हो जाते हैं और अपना बीन डिक्लेयर करने पर डिफॉल्ट पीछे हट जाता है। conditions रिपोर्ट ठीक-ठीक दिखाती है कि क्या मैच हुआ, और किसी हैरान करने वाले बीन को समझाने का यही सबसे तेज़ तरीका है।

Spring REST API में आप एरर कैसे हैंडल करते हैं? यह क्या टटोलता है: एकरूपता। एक controller advice से सब कुछ एक जगह लाइए जो एक्सेप्शन टाइप को स्टेटस कोड और एक स्थिर एरर बॉडी से मैप करे, स्टैक ट्रेस को रिस्पॉन्स से बाहर रखिए, और क्लाइंट एरर व सर्वर एरर को ठीक से अलग कीजिए।

भाषा और डिज़ाइन के कौन से सवाल अब भी पूछे जाते हैं?

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

checked या unchecked एक्सेप्शन: आपकी राय क्या है? यह क्या टटोलता है: API डिज़ाइन की समझ। checked एक्सेप्शन कॉलर को एक ठीक हो सकने वाली स्थिति संभालने पर मजबूर करते हैं, लेकिन वे सिग्नेचर गंदे करते हैं और व्यवहार में दबा दिए जाते हैं, इसीलिए ज़्यादातर आधुनिक कोडबेस unchecked एक्सेप्शन पसंद करते हैं, एक साफ बाउंड्री के साथ जो उन्हें बदल देती है।

record और sealed टाइप किस समस्या को हल करते हैं? यह क्या टटोलता है: भाषा के साथ आपकी अपडेट रहने की आदत। record संक्षिप्त इम्यूटेबल डेटा कैरियर देते हैं, जिनमें equals, hashCode और toString अपने आप बनते हैं, जिससे हाथ से लिखी बगों की एक पूरी श्रेणी हट जाती है। sealed टाइप इजाज़त वाली इम्प्लीमेंटेशन सीमित कर देते हैं, जिससे switch में पैटर्न मैचिंग पूरी होती है और कंपाइल टाइम पर जांची जाती है।

Java कैंडिडेट्स कहां डूबते हैं?

लगभग सब जगह वजह गहराई की कमी होती है। Java पैनल परिभाषा से दो-तीन स्तर नीचे तक टटोलते हैं, इसलिए जिस कैंडिडेट ने शब्दावली रट ली है लेकिन कभी हीप डंप या थ्रेड डंप नहीं पढ़ा, वह पहले जवाब में नहीं बल्कि फॉलो-अप में पकड़ा जाता है। ये रहे बार-बार दिखने वाले पैटर्न।

• बिना मैकेनिक्स के परिभाषाएं सुनाना। "volatile इसे थ्रेड सेफ बना देता है" फेल होता है। बताइए कि वह क्या गारंटी देता है और क्या नहीं।
• रनटाइम को नज़रअंदाज़ करना। जो कैंडिडेट यह नहीं बता सकता कि मेमोरी कहां जाती है या पॉज़ किस वजह से आता है, वह प्रोडक्शन डिबग नहीं कर सकता, कोड चाहे कितना भी साफ हो।
• Spring को जादू मान लेना। यह न जानना कि ट्रांज़ैक्शन प्रॉक्सी के ज़रिए काम करते हैं, सीनियर लेवल की सबसे आम कमी है।
• असली बर्ताव पर किताबी कॉम्प्लेक्सिटी को तरजीह देना। किताब से सीधा उठाया गया LinkedList वाला जवाब बताता है कि इस इंसान ने कभी कुछ मापा नहीं।
• कोडिंग के दौरान चुप रहना। पैनल आपकी सोच खरीद रहा है। टाइप करते हुए तरीका, एज केस और ट्रेडऑफ बोलते रहिए।
• पुरानी पड़ चुकी जानकारी। अगर टीम मौजूदा LTS पर है और आपने record या वर्चुअल थ्रेड का नाम भी नहीं सुना, तो लगता है कि आपने सीखना बंद कर दिया।

Java इंटरव्यू की तैयारी कैसे करें?

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

लूप शुरू होने से पहले, असली जॉब पोस्टिंग को फ्री Question Predictor में पेस्ट कीजिए और उस खास रोल के लिए निकले बीस सवालों पर काम कीजिए, क्योंकि एक लो-लेटेंसी ट्रेडिंग टीम और एक एंटरप्राइज़ Spring शॉप के बीच भाषा के अलावा शायद ही कुछ साझा हो।

लाइव राउंड के लिए GhostPilot एक रियल-टाइम इंटरव्यू कोपायलट है: एक Chrome एक्सटेंशन साइड पैनल और एक वैकल्पिक Windows डेस्कटॉप ऐप, जो कॉल को ट्रांसक्राइब करते हैं, सवाल आते ही उसे पकड़ते हैं, और करीब दो सेकंड बाद एक स्ट्रक्चर्ड जवाब तैयार रखते हैं। यह उन सवालों पर सबसे ज़्यादा काम आता है जिनमें कोई पेच छिपा हो, जैसे ट्रांज़ैक्शन वाला सवाल। यह स्क्रिप्ट नहीं, एक इशारा है, और प्रोडक्शन की बारीकियां अब भी आपको ही लानी होंगी। फ्री टियर आपको हफ्ते में 10 मिनट का लाइव इंटरव्यू टाइम देता है, कार्ड की ज़रूरत नहीं।

Java इंटरव्यू FAQ

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

2026 के इंटरव्यू के लिए कौन सा Java वर्ज़न आना चाहिए? वह LTS जानिए जिस पर आपकी टारगेट कंपनी चल रही है, और हाल के रिलीज़ में क्या जुड़ा, खासकर record, sealed टाइप, switch में पैटर्न मैचिंग और वर्चुअल थ्रेड। कई एंटरप्राइज़ अब भी पुराने LTS पर हैं, इसलिए आपने असल में क्या इस्तेमाल किया है, इस बारे में ईमानदार रहिए।

कितना Spring आना चाहिए? अगर जॉब में Spring का ज़िक्र है, तो उसे फुटनोट नहीं, पहले दर्जे का टॉपिक मानिए। डिपेंडेंसी इंजेक्शन, ऑटो-कॉन्फ़िगरेशन, ट्रांज़ैक्शन और टेस्टिंग लगभग हर Spring लूप में आते हैं, और ट्रांज़ैक्शन वाला सवाल वही जगह है जहां कैंडिडेट सबसे ज़्यादा राउंड गंवाते हैं।

जो नहीं आता, क्या वह मान लेना चाहिए? हां। "मैंने वह कलेक्टर प्रोडक्शन में ट्यून नहीं किया, लेकिन मैं इसे ऐसे देखूंगा और सबसे पहले यह मापूंगा" किसी आत्मविश्वास से दिए गलत जवाब से बेहतर है। Java पैनल फॉलो-अप में दो-तीन स्तर गहरे जाते हैं, इसलिए बहाना जल्दी ढह जाता है।