एक इंटरव्यू लेने वाले की नोट्स
सॉफ्टवेयर इंजीनियरिंग में hiring practices को यहाँ कड़ी आलोचना मिलती है—SOLID और Big-O जैसे trivia-style प्रश्नों से लेकर LeetCode drills, academic records, और culture-specific jargon पर अत्यधिक निर्भरता तक। टिप्पणीकारों का तर्क है कि ये तरीके अक्सर memorization, conformity, और privilege को चुनते हैं, न कि वास्तविक problem-solving ability, communication, और real-world experience को; और वे work-sample tests तथा पिछले projects की गहन समीक्षा जैसे विकल्प सुझाते हैं। उम्मीदवारों के लिए व्यावहारिक सलाह भी सामने आती है: कंपनी के बारे में शोध करें, ध्यान से सुनें, संक्षेप में संवाद करें, और सुनिश्चित करें कि आपका remote setup, खासकर audio, आपकी performance को नुकसान न पहुँचाए।
उम्मीदवार की तैयारी और प्रेरणा
- कई लोग बुनियादी तैयारी पर जोर देते हैं: कंपनी के बारे में शोध करना, उत्पादों को समझना, इस बात का ठोस कारण होना कि आपकी रुचि क्यों है, और सूचित प्रश्न पूछना।
- कुछ लोग इसका विरोध करते हैं: ज़्यादातर कंपनियाँ “विशेष” नहीं होतीं, इसलिए गहरी उत्सुकता की मांग करना घमंड जैसा है; स्टाफ भूमिकाओं के लिए न्यूनतम लेकिन वास्तविक रुचि और उचित वेतन को पर्याप्त माना जाता है।
- नेतृत्व भूमिकाओं से अधिक विशिष्ट रुचि और संदर्भ-निर्धारण दिखाने की अपेक्षा की जाती है।
संचार और इंटरव्यू का व्यवहार
- संक्षिप्त, केंद्रित उत्तरों पर मजबूत जोर; “word vomit” और भटककर बोलते रहना आम विफलता के तरीके हैं।
- कमजोर संप्रेषकों के लिए संरचित तरीके (जैसे STAR-जैसे) सुझाए जाते हैं।
- प्रश्न को ध्यान से सुनना, इंटरव्यू लेने वाले की बात पर चढ़कर न बोलना, और सीधे उत्तर देना बार-बार महत्वपूर्ण बताया जाता है।
- कोडिंग टास्क के दौरान दिए गए संकेतों को नज़रअंदाज़ करना बड़ा red flag माना जाता है; शुरुआती पूर्णता से अधिक ज़रूरी है stuck अवस्था से सहयोग करके निकलना।
रिमोट सेटअप और लॉजिस्टिक्स
- कई टिप्पणियाँ एक भरोसेमंद mic, इंटरनेट, और बुनियादी video-call क्षमता रखने पर ज़ोर देती हैं, खासकर remote भूमिकाओं के लिए।
- ऑडियो gear में कितना निवेश करना चाहिए, इस पर बहस है; आम सहमति यह है कि “bad Bluetooth/laptop mics से कुछ भी बेहतर है,” हालाँकि recent MacBook mics के लिए एक अपवाद नोट किया गया है।
- कुछ लोग voice quality सुधारने के लिए software के बारे में पूछते हैं; कोई स्पष्ट सर्वसम्मति वाला समाधान सामने नहीं आता।
इंटरव्यू सामग्री: क्या पूछें और क्यों
- सैद्धांतिक प्रश्नों (SOLID, HTTP verbs, inner joins, आदि) पर मिश्रित विचार हैं:
- कुछ लोग इन्हें टालते हैं, और सरल–मध्यम coding tasks के साथ explanation को प्राथमिकता देते हैं।
- अन्य लोग critique-focused प्रश्नों (जैसे, “आप किस SOLID principle से असहमत हैं और क्यों?”) को गहराई और निर्णय-क्षमता जांचने के लिए उपयोगी मानते हैं—यदि इन्हें रटंत trivia की तरह न लिया जाए।
- SOLID और “Uncle Bob” पर लंबी बहस होती है:
- कुछ इसे कालातीत, व्यापक रूप से लागू होने वाली design guidance मानते हैं।
- अन्य इसे पुराना, अत्यधिक abstract, या cargo-culted enterprise OOP dogma के रूप में देखते हैं।
- कई लोग नोट करते हैं कि बहुत से डेवलपर acronym जाने बिना भी ऐसे ही विचार सहज रूप से लागू कर लेते हैं।
संकेत: LeetCode, ग्रेड, और heuristics
- एक पक्ष का तर्क है कि “LeetCode master + personable बनो” कई कंपनियों के लिए प्रमुख रणनीति है।
- दूसरा पक्ष work-sample–style tasks, पिछले सिस्टम्स की गहरी समीक्षा, और puzzles व trivia की बजाय वास्तविक projects पर चर्चा को पसंद करता है।
- academic record विवादास्पद है:
- कुछ इसे work ethic और care के लिए एक अच्छा heuristic मानते हैं।
- अन्य कहते हैं कि यह neurodiverse लोगों, older candidates के साथ नुकसान करता है, और school तथा work के बीच motivation differences को नज़रअंदाज़ करता है।
- इस बात की आलोचना भी है कि बहुत-सी interview processes interviewer comfort, trivia, और cultural fit को job performance की empirical भविष्यवाणी से ज़्यादा महत्व देती हैं।
मेटा-पर्यवेक्षण और cynicism
- कई टिप्पणीकार interviews को एक “terrible” लेकिन जड़ जमा चुकी screening method कहते हैं, जो अक्सर वास्तविक job skills से मेल नहीं खाती।
- अत्यधिक सख्त, gatekeeper-style interviewing और buzzwords तथा acronyms पर social signals के रूप में निर्भरता को लेकर चिंता जताई जाती है, न कि वास्तविक competence के रूप में।
- कुछ लोग deeper answers निकालने के लिए questions पहले से भेजने का सुझाव देते हैं; अन्य कहते हैं कि इससे वांछित signals विकृत हो जाएँगे।