Amazon इंटरव्यू कितना मुश्किल है?

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

Amazon एक संरचित इंटरव्यू प्रक्रिया अपनाता है। इंटरव्यूअर्स को जांचने के लिए खास Leadership Principles दिए जाते हैं, वे बातचीत के दौरान विस्तृत नोट्स लेते हैं, और बाद में डीब्रीफ में उन नोट्स की तुलना की जाती है। इससे दो नतीजे निकलते हैं। कमरे में अच्छी लगने वाली कहानी कागज़ पर कमज़ोर दिखती है अगर उसमें कोई फैसला और नतीजा न हो, और दो राउंड में अलग-अलग विवरणों के साथ सुनाई गई एक ही कहानी नोट्स की तुलना करते ही तुरंत पकड़ में आ जाती है।

मुश्किल का दूसरा स्रोत यह है कि बिहेवियरल स्तर तकनीकी राउंड में भी लागू होता है। जो उम्मीदवार कोडिंग समस्या को साफ-सुथरे तरीके से हल कर लेता है लेकिन किसी मैनेजर से असहमति का कोई वाकया नहीं बता पाता, वह उस हिस्से में चूक जाता है जिसे शुद्ध रूप से तकनीकी इंटरव्यू कभी नापता ही नहीं।

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

व्यवहार में इसका मतलब है कि आपका नतीजा तय करने वाले व्यक्ति का उस पद को भरने में कोई स्वार्थ नहीं होता। जल्दबाज़ी आपकी मदद नहीं करती, और मैनेजर से अच्छे संबंध भी नहीं। जो मदद करता है वह ऐसा सबूत है जो लिखे जाने और आपसे कभी न मिले किसी व्यक्ति द्वारा पढ़े जाने के बाद भी टिका रहे।

आमतौर पर आपको पता नहीं चलता कि कौन-सा इंटरव्यूअर यह है, और इससे कोई फ़र्क नहीं पड़ता। हर राउंड का जवाब ऐसे दें जैसे उसे बाद में कोई अजनबी पढ़ेगा, क्योंकि असल में ऐसा ही होता है।

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

बिहेवियरल आधे हिस्से के लिए Leadership Principles में फैली आठ से बारह कहानियां चाहिए, हर एक में स्थिति, आपने खुद क्या फैसला लिया, और मापने लायक नतीजा शामिल हो। एक ही प्रोजेक्ट से अलग-अलग नज़रिए से दो या तीन कहानियां निकल सकती हैं। जहां भी नतीजा संख्या में मौजूद हो, उसे लिख लें, क्योंकि फॉलो-अप सवाल आमतौर पर ठीक वही मांगता है।

फिर उन्हें ज़ोर से बोलकर प्रैक्टिस करें। नौ साल के अनुभव वाली एक बैकएंड इंजीनियर ने बेहतरीन नोट्स लिखे थे और फिर भी अपने पहले प्रैक्टिस राउंड में अटक गई, क्योंकि कहानी पढ़ना और फॉलो-अप में उसे सुनाना दो अलग हुनर हैं। /mock-interview पर दो हफ्तों की बोलकर प्रैक्टिस ने उसे सुनाने के तरीके को एक और महीने पढ़ने से कहीं ज़्यादा बदल दिया। पूरे लूप की चरण-दर-चरण तस्वीर /answers/topic/company-interviews पर है।

ज़्यादातर मामले चार पैटर्न से समझाए जा सकते हैं, और इनमें से किसी का बुद्धिमत्ता से कोई लेना-देना नहीं है।

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

यह साफ़ कहना भी ज़रूरी है कि सक्षम इंजीनियर यहां ऐसी वजहों से रिजेक्ट होते हैं जिनका काबिलियत से कोई संबंध नहीं होता, जिसमें टीम फ़िट और उस दिन के पैनल की बनावट शामिल है। तैयारी संभावनाओं को बदलती है; वह उन्हें तय नहीं करती, और रिजेक्शन आपकी काबिलियत पर फैसला नहीं है।