00:00:00तो चलिए कोडिंग इंटरव्यू के बारे में बात करते हैं। मानिए या न मानिए, सॉफ़्टवेयर इंजीनियर्स को कोडिंग इंटरव्यू से नफ़रत है
00:00:05उतनी ही जितनी उन्हें मेल-जोल बढ़ाने से होती है। शायद यह आपके लिए कोई बड़ी बात न हो अगर आप उन लोगों में से हैं जिन्होंने
00:00:09500 LeetCode समस्याओं को हल किया है। लेकिन हम जैसे बाकी लोगों के लिए, जिन्हें सवाल हल करते समय नींद आ जाती है
00:00:16और सवाल को 'पूरा' मार्क करने के लिए चुपके से AI की मदद लेते हैं, उनके लिए यह एक बड़ी बात है। लेकिन सबसे बुरा हिस्सा
00:00:21अभी बाकी है। भले ही आपने 500 LeetCode सवाल हल किए हों, फिर भी आप रिजेक्ट हो सकते हैं। यह
00:00:27सिर्फ मेरी राय नहीं है। मैं रेडिट पर उन उम्मीदवारों की असली कहानियां पढ़ रहा था जिन्होंने सब कुछ
00:00:33सही किया और फिर भी असफल रहे। इसलिए अगर आप नहीं चाहते कि ऐसा आपके साथ हो, तो यह वीडियो आपकी मदद करेगा। क्योंकि आज
00:00:38मैं आपको एक स्पष्ट और दोहराने योग्य ढांचा (framework) देने जा रहा हूँ जिसका उपयोग आप अपने
00:00:43कोडिंग इंटरव्यू को क्रैक करने के लिए कर सकते हैं। मैं इसे TECT कहता हूँ। इस ढांचे ने मुझे अपनी पहली नौकरी पाने में मदद की और यह रिसर्च करने के बाद कि
00:00:49सफल उम्मीदवार इंटरव्यू में कैसा प्रदर्शन करते हैं, मुझे एक दिलचस्प बात पता चली। अधिकांश टॉप परफॉर्मर्स
00:00:54अनजाने में इसी प्रक्रिया का पालन करते हैं। तो चलिए देखते हैं कि आप अपने कोडिंग इंटरव्यू में इस TECT फ्रेमवर्क का उपयोग कैसे कर सकते हैं।
00:01:00TECT फ्रेमवर्क में 'T' का अर्थ है 'Think' यानी सोचें। इसका मतलब यह है कि मान लीजिए
00:01:06आपका कोडिंग इंटरव्यू शुरू हुआ और आपके इंटरव्यूअर ने आपको एक सवाल दिया। तो सबसे पहला
00:01:10कदम है समाधान के बारे में सोचना। आप में से बहुत से लोग सोच रहे होंगे कि यह तो बहुत स्पष्ट है,
00:01:16लेकिन थोड़ी देर मेरे साथ बने रहें। इस चरण में आपको जिस गलती से बचना चाहिए वह है पहले ही सबसे बेहतर (optimized) समाधान के बारे में सोचना।
00:01:21यह मत सोचें कि आप कम मेमोरी का उपयोग कैसे कर सकते हैं या कोड को तेज़ी से कैसे चला सकते हैं।
00:01:26बस यह सोचें कि आप इसे हल कैसे करेंगे। लेकिन क्या होगा अगर आप पहले से ही सबसे बेहतर समाधान जानते हैं?
00:01:31ऐसे मामले हो सकते हैं जहाँ आप सवाल से पहले से परिचित हों और उसका optimized समाधान जानते हों। तब
00:01:35आपको क्या करना चाहिए? मैं इसका उत्तर दूसरे चरण में दूँगा। तो इस पहले चरण का परिणाम यह होना चाहिए
00:01:40कि आपके मन में इसे हल करने का एक समाधान होना चाहिए। एक बार जब आप जान जाते हैं कि इसे कैसे हल करना है,
00:01:44तो यह हमें दूसरे चरण पर ले आता है। 'Explain' यानी समझाना। अधिकांश लोग क्या करते हैं कि वे
00:01:50सिर्फ समाधान के बारे में सोचते हैं और अपने मुँह से एक शब्द भी बोले बिना सीधे उसे
00:01:55लागू करने (implement) लग जाते हैं। लेकिन अधिकांश इंटरव्यूअर्स के लिए यह एक नेगेटिव पॉइंट है। आपको यह करना चाहिए
00:02:00कि समाधान मन में आने के बाद, आपको इंटरव्यूअर को उस समाधान और अपनी पूरी विचार प्रक्रिया के बारे में समझाना चाहिए।
00:02:04मान लीजिए कि इंटरव्यू में आपको मशहूर '3Sum' समस्या मिली है। तो सीधे कोडिंग शुरू करने के बजाय, पहले सोचें और
00:02:08इंटरव्यूअर से बात करें। आप कुछ ऐसा कह सकते हैं, “चूँकि हमें तीन ऐसी संख्याएँ ढूँढनी हैं जिनका
00:02:14योग एक लक्ष्य (target) के बराबर हो, तो एक सीधा तरीका 'nested loops' का उपयोग करना और हर संभव
00:02:19कॉम्बिनेशन को चेक करना है।” इस तरह, बस अपने पूरे विचारों को सामने रखें कि आप इसे कैसे हल कर रहे हैं और
00:02:23यह तरीका क्यों काम करेगा। अगर आपने वह सवाल पहले किया है और उत्तर जानते हैं, तो आपको सीधे
00:02:28optimized समाधान के बारे में बात नहीं करनी चाहिए। उससे पहले, 'brute force' (बुनियादी) समाधान का जिक्र करें।
00:02:33ऐसा इसलिए क्योंकि सीधे optimized समाधान की बात करने से ऐसा लग सकता है कि आपने इसे रटा हुआ है।
00:02:39तो इससे बचने के लिए, बस brute force दृष्टिकोण से अपनी विचार प्रक्रिया समझाना शुरू करें और उसके बाद ही
00:02:45optimized समाधान के बारे में बात करें। आप कह सकते हैं, “यह काम तो करेगा लेकिन यह सबसे बेहतर नहीं है।
00:02:49तीन लूप्स का उपयोग करने के बजाय, हम ऐरे (array) को सॉर्ट कर सकते हैं और टाइम कॉम्प्लेक्सिटी कम करने के लिए 'two-pointer' दृष्टिकोण का उपयोग कर सकते हैं”
00:02:55और अपनी पूरी विचार प्रक्रिया को विस्तार से बताएं। इससे पहले कि हम TECT फ्रेमवर्क के अगले हिस्से पर बढ़ें,
00:03:01मैं इस वीडियो के स्पॉन्सर के बारे में जल्दी से बात करना चाहता हूँ। अगर आपको LeetCode कठिन लगता है और आप हमेशा
00:03:05समाधान रटने लगते हैं, तो AlgoMonster आपके लिए है। यह एक कोडिंग इंटरव्यू की तैयारी का प्लेटफॉर्म है
00:03:11जो रैंडम प्रैक्टिस के बजाय पैटर्न-आधारित सीखने पर ध्यान केंद्रित करता है। विचार सरल है।
00:03:16अधिकांश इंटरव्यू प्रश्न कुछ मुख्य पैटर्नों से बने होते हैं और एक बार जब आप उन पैटर्नों को सही मायने में समझ लेते हैं,
00:03:22तो आपको सैकड़ों समस्याओं को रटने की ज़रूरत नहीं होती। वे आपको व्यवस्थित रूप से किसी भी सवाल को हल करने के लिए
00:03:27फ़्लोचार्ट और दोबारा इस्तेमाल होने वाले कोड टेम्पलेट्स प्रदान करते हैं जिन्हें आप इंटरव्यू के दौरान लागू कर सकते हैं।
00:03:32AlgoMonster सिर्फ ऐसा प्लेटफॉर्म नहीं है जहाँ आपको प्रैक्टिस के लिए सवालों की लिस्ट मिल जाए।
00:03:38यह आपको आपके कोडिंग इंटरव्यू की तैयारी के लिए अधिक संरचित और कुशल तरीका प्रदान करता है।
00:03:44इसका एक फ्री प्लान उपलब्ध है और यदि आप चाहें, तो अधिक वैल्यू और स्ट्रक्चर पाने के लिए
00:03:47पेड वर्जन भी देख सकते हैं। आप 50% डिस्काउंट पा सकते हैं। लिंक डिस्क्रिप्शन में है।
00:03:52तो चलिए TECT फ्रेमवर्क के अगले कदम पर वापस चलते हैं। अब आपने समाधान सोच लिया है,
00:03:58इंटरव्यूअर को समझा दिया है और फिर अगला चरण आता है - 'Code'। यह चरण सीधा है।
00:04:02आप बस अपने समाधान के लिए कोड लिखेंगे। लेकिन यहाँ अधिकांश डेवलपर्स गलती करते हैं। वे
00:04:08कोडिंग करते समय चुप रहते हैं। ज़्यादातर इंटरव्यू में, इंटरव्यूअर आपसे आपके लिखे गए कोड को समझाने के लिए कहेगा।
00:04:13तो अगर आपने चुपचाप कोड लिखा, तो इंटरव्यूअर शायद बाद में उसे समझाने को कहेगा। लेकिन बेहतर यह है कि
00:04:18जब आप कोड लिख रहे हों, तभी उसे समझाते रहें। मान लीजिए आपने कोडिंग शुरू की। आपने
00:04:23परिणामों को स्टोर करने के लिए एक खाली ऐरे (array) बनाया। इसके उद्देश्य को समझाने के लिए, आप कुछ ऐसा कह सकते हैं,
00:04:28“तो मैं परिणामों को स्टोर करने के लिए एक खाली ऐरे बनाऊँगा और अपने आगे के कोड के बारे में समझाना जारी रखूँगा।”
00:04:33और मेरा विश्वास करें, यह बहुत प्रभावी है और इंटरव्यूअर्स इसे पसंद करेंगे। यह आपके और इंटरव्यूअर के बीच
00:04:39लगातार जुड़ाव सुनिश्चित करने में भी मदद करता है और यह भी साबित करता है कि आप वास्तव में जानते हैं कि आप क्या कर रहे हैं।
00:04:45एक और समस्या जो आपके सामने आ सकती है वह यह कि आप कोई सिंटैक्स (syntax) या फ़ंक्शन का नाम भूल सकते हैं।
00:04:50उस स्थिति में, उसी लाइन पर अटके रहने और उसे याद करने की कोशिश करने की गलती न करें।
00:04:55अगर आपको याद नहीं आ रहा है, तो आप एक छोटा कमेंट छोड़ सकते हैं और बस कोड करना जारी रख सकते हैं
00:05:01और काम पूरा होने के बाद उस लाइन पर वापस आ सकते हैं। इस तरह, आप उस एक सिंटैक्स को याद करने में
00:05:06अपना समय बर्बाद नहीं करेंगे। अगर आपको वह बिल्कुल याद नहीं आ रहा है, तो बस इंटरव्यूअर को बता दें।
00:05:11कभी-कभी वे आपको हिंट भी दे सकते हैं या आपको इसे देखने के लिए कह सकते हैं। तो यह हमें हमारे अंतिम चरण पर लाता है।
00:05:16आपका कोड तैयार होने के बाद, अगला काम उसे 'Test' करना है। कुछ मामलों में, इंटरव्यूअर आपको
00:05:21अपेक्षित इनपुट और आउटपुट दे सकता है। लेकिन अगर उन्होंने नहीं दिया है, तो आपको अपने खुद के टेस्ट केसेस लिखने होंगे।
00:05:27बुनियादी टेस्ट केस के बारे में सोचें। और अगर आप 'edge cases' (असाधारण स्थितियां) के बारे में सोच सकते हैं, तो यह और भी बेहतर है।
00:05:32बस यह सुनिश्चित करें कि आपका कोड उसे संभाल सके। कोड चलाने के बाद, यह 100% पक्का नहीं है कि यह चल ही जाएगा।
00:05:38दो चीजें हो सकती हैं। या तो कोड चलेगा या कोई एरर (error) दिखाएगा। अगर यह चलता है, तो बढ़िया। यदि नहीं,
00:05:43तो आपको यह करने की ज़रूरत है। सबसे पहले, घबराएं नहीं। क्योंकि अगर आपने पहले समाधान किया है
00:05:48और आश्वस्त हैं कि आपका दृष्टिकोण सही है, तो यह सिर्फ कोई सिंटैक्स या छोटी सी लॉजिक एरर हो सकती है।
00:05:53तो घबराएं नहीं और बस एरर को पढ़ें और उसे ठीक करें। ज्यादातर लोग क्या करते हैं कि वे प्रेशर के कारण
00:05:59एरर मैसेज को ठीक से पढ़ते भी नहीं हैं और शुरू से कोड पढ़ना शुरू कर देते हैं। अगर यह पहली बार में नहीं चलता है
00:06:05तो कोई बात नहीं। आपका इंटरव्यूअर छोटी-मोटी गलतियों के लिए नंबर नहीं काटेगा। तो अगर सब कुछ ठीक रहा
00:06:09और आपकी किस्मत अच्छी रही, तो इंटरव्यूअर समाधान के बारे में कुछ बुनियादी सवाल पूछ सकता है
00:06:14और अगले सवाल पर बढ़ सकता है। लेकिन अगर आप मीडियम से सीनियर लेवल की पोजीशन के लिए अप्लाई कर रहे हैं,
00:06:19तो आपसे optimized दृष्टिकोण के बारे में पूछा जा सकता है। दोनों ही मामलों में, आपको बस इसी TECT
00:06:24फ्रेमवर्क को दोबारा दोहराना है और अपने इंटरव्यू को पूरा करना है। तो यह एक सरल और याद रखने में आसान फ्रेमवर्क है
00:06:30यदि आप कोडिंग इंटरव्यू के लिए जा रहे हैं। कोडिंग इंटरव्यू सिर्फ कोडिंग के बारे में नहीं हैं।
00:06:34यह कम्युनिकेशन के बारे में भी है। इंटरव्यूअर्स सिर्फ आपका कोड नहीं देखना चाहते। वे जानना चाहते हैं कि
00:06:40आप क्या सोच रहे हैं और कैसे सोच रहे हैं। बस इस एक बात को ध्यान में रखें। कोडिंग इंटरव्यू में भी
00:06:44कम्युनिकेशन बहुत महत्वपूर्ण है। मैंने रिक्रूटर्स से बात की है और वे सभी सहमत हैं कि अगर
00:06:49उम्मीदवार ज्यादा बात नहीं करता है, तो यह उनके लिए एक नेगेटिव पॉइंट (red flag) है। तो इस बात का ध्यान रखें
00:06:54और अपने कोडिंग इंटरव्यू की तैयारी के लिए AlgoMonster को ज़रूर देखें। इस वीडियो के लिए बस इतना ही
00:06:59और आपके इंटरव्यू के लिए शुभकामनाएँ। वीडियो को लाइक करना न भूलें।
00:07:04मैं आपसे अगले वीडियो में मिलूँगा।
00:07:07I'll see you guys in the next one.