मैंने सॉफ्टवेयर इंजीनियरिंग पदों के लिए सैकड़ों उम्मीदवारों का इंटरव्यू लिया है
सॉफ्टवेयर इंजीनियरों की hiring प्रथाएँ आलोचना के घेरे में हैं, क्योंकि कई लोगों का तर्क है कि whiteboard puzzles और LeetCode-style चुनौतियाँ तनावपूर्ण, कम-संकेत वाली होती हैं और वास्तविक प्रदर्शन की भविष्यवाणी नहीं करतीं। Commenters conversational interviews, simple coding tasks, take-home assignments, portfolio reviews, और structured behavioral questions जैसे विकल्पों पर बहस करते हैं, साथ ही क्षेत्र में baseline competence की कमी और “culture fit” या tech-news enthusiasm पर निर्भर रहने से होने वाले bias की ओर भी इशारा करते हैं। कई आवाज़ें यह ज़ोर देती हैं कि interviewer की क्षमता, यह स्पष्टता कि क्या मूल्यांकन किया जा रहा है, और उम्मीदवारों के समय तथा गरिमा का सम्मान, उपयोग किए गए format जितने ही महत्वपूर्ण हैं।
कोडिंग चुनौतियों और व्हाइटबोर्ड के सीमाएँ
- कई लोगों का कहना है कि take-home tests, live coding, और puzzles दोनों पक्षों के लिए अप्रिय होते हैं और शायद ही कभी ऐसी समस्याएँ सामने लाते हैं जो बातचीत में न दिखें।
- दूसरे लोग जोर देकर कहते हैं कि live coding के बिना, कई नियुक्त लोग मजबूत résumé और संचार कौशल के बावजूद बुनियादी loops या simple algorithms भी नहीं लिख पाएँगे।
- मानक “LeetCode”/algorithm puzzles की आलोचना इस आधार पर की जाती है कि वे test prep और pressure tolerance को चुनते हैं, नौकरी से संबंधित skills को नहीं।
बुनियादी कौशल सत्यापन की आवश्यकता
- कई interviewer बहुत सरल coding checks पर ज़ोर देते हैं (जैसे loops, list operations, basic data transformations) ताकि उन applicants को पकड़ा जा सके जो “talk a good game” तो करते हैं लेकिन code नहीं कर सकते।
- इस बात पर असहमति है कि कितना pressure उचित है: कुछ लोग low-stress, trivial tasks चाहते हैं; दूसरे moderate pressure को अपरिहार्य मानते हैं।
इंटरव्यू के लक्ष्य: समस्या-समाधान, संचार, फिट
- कई लोग conversational interviews को प्राथमिकता देते हैं: past projects, system designs, code samples, या candidate-provided code पर चर्चा करना, और समझ की गहराई को परखना।
- वांछनीय संकेत: systematic approach, trade-offs समझाने की क्षमता, “I don’t know” कहने की तत्परता, और रचनात्मक सहयोग।
- कुछ लोगों की अपेक्षा होती है कि seniors coding से पहले approach और design articulate करें; दूसरे नोट करते हैं कि वास्तविक design आमतौर पर whiteboard पर पाँच मिनट में नहीं, बल्कि घंटों में होता है।
संस्कृति, व्यक्तित्व, और पूर्वाग्रह
- “Culture fit” को एक साथ आवश्यक और जोखिमपूर्ण माना जाता है: यह smooth collaboration सुनिश्चित कर सकता है, लेकिन bias को भी encode कर सकता है और diversity को घटा सकता है।
- “tech news,” “new technologies,” या social activities (जैसे parties, drinks) से जुड़े प्रश्न सामाजिक bubble, lifestyle, या personality के आधार पर अप्रत्यक्ष रूप से छंटनी कर सकते हैं।
- कई लोग बताते हैं कि बहुत से अच्छे developers high-pressure tests या forced socializing पसंद नहीं करते, और उन्हें बाहर कर देना प्रतिकूल हो सकता है।
मानकों और आधारभूत दक्षता की कमी
- एक बार-बार उठने वाली शिकायत: उम्मीदवारों के skill levels बहुत अधिक बदलते हैं, और résumés खराब predictors हैं।
- कुछ लोग एक हल्का, उद्योग-व्यापी “programmer’s bar exam” सुझाते हैं ताकि न्यूनतम दक्षता (loops, conditionals, basic reasoning) सुनिश्चित हो सके; दूसरे चिंतित हैं कि इससे महँगी credential barriers फिर से खड़ी हो जाएँगी।
प्रक्रिया डिज़ाइन और शोध से साक्ष्य
- सुझाए गए सुधार: कम rounds, क्या मूल्यांकन करना है इसके लिए स्पष्ट योजना, और consistent rubrics के साथ structured behavioral interviews (“tell me about a time when…”)।
- एक commenter industrial/organizational psychology का हवाला देता है: work-sample tests और structured interviews सबसे अधिक predictive होते हैं; unstructured chats अधिक biased और lower signal होते हैं।
- यह भी चिंता है कि बहुत से interviewer स्वयं skills का आकलन करने या सटीक expectations तय करने में अच्छे नहीं होते।