AI युग में तकनीकी इंटरव्यू

 (dein.fr)
5 पॉइंट द्वारा GN⁺ 5 시간 전 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • ऐसे समय में जब AI टूल्स तेज़ी से कोड लिखने और review तक पहुँच रहे हैं, इंटरव्यू में AI के उपयोग को मूल रूप से बाहर रखते हुए बुनियादी क्षमताओं के आधार पर मूल्यांकन किया जाना चाहिए
  • एक अच्छे इंटरव्यू का मूल्यांकन दो अक्षों पर किया जाता है: signal quality और cost to company; ये दोनों तत्व पूरी तरह स्वतंत्र नहीं हैं
  • इंटरव्यू के प्रकार चार हिस्सों में बाँटे जा सकते हैं: Take-home, Live exercise, Presentation, Actual work, और हर एक की signal quality व cost अलग होती है
  • AI coding की वजह से take-home बहुत आसान हो गया है, review का बोझ बढ़ गया है, और leak हुए सवालों पर AI एक बेहद ताकतवर coach की तरह काम करता है
  • AI proficiency सिर्फ instrumental skill है, इसलिए कंपनियों को foundational skill के मूल्यांकन पर ध्यान देना चाहिए

मुख्य तर्क

  • AI models और tools के तेज़ विकास के बीच यह सवाल उठता है कि क्या 6 महीने बाद भी engineers code लिखेंगे और review करेंगे; अगर core skill ही गायब हो रही हो, तो क्या इंटरव्यू का तरीका भी बदलना चाहिए — लेख इसी सवाल से शुरू होता है
  • अधिकतर कंपनियों ने status quo बनाए रखा है, जिनमें इस क्रांति को आगे बढ़ाने वाली कंपनियाँ भी शामिल हैं
    • Anthropic की hiring guideline के अनुसार take-home को "अलग से निर्देश न हो तो Claude के बिना" पूरा करना चाहिए
  • कुछ कंपनियाँ AI के उपयोग को अनुमति देती हैं, प्रोत्साहित करती हैं, या अनिवार्य करती हैं, और कभी-कभी AI proficiency खुद इंटरव्यू का विषय बन जाती है
  • निष्कर्ष यह है कि इंटरव्यू में सामान्य रूप से AI को बाहर रखा जाना चाहिए, और इंटरव्यू को AI के दौर के मुताबिक समायोजित करने के ठोस तरीके भी दिए गए हैं

अच्छे इंटरव्यू के दो आयाम

  • Signal quality

    • किसी तय skill set के संदर्भ में मजबूत उम्मीदवारों को पहचानने और noise को नज़रअंदाज़ करने की क्षमता; noise में वे बातें आती हैं जो role के लिए गैर-महत्वपूर्ण हों या आसानी से सिखाई जा सकें
    • इंटरव्यू-विशेष तैयारी के प्रति प्रतिरोध (Invulnerability to preparation): अगर प्रदर्शन तैयारी की मात्रा या मेहनत पर निर्भर हो, तो इंटरव्यू केवल उसी गुण का signal देता है
    • यथार्थवाद (Realism): इंटरव्यू का काम रोज़मर्रा के कार्य जैसा होना चाहिए, लेकिन वही अंतिम लक्ष्य नहीं है। "algorithm & data structure" इंटरव्यू सीधे काम में न आने के बावजूद लंबे समय तक टिके रहे हैं
    • समानता (Equality): पहले से domain expertise, paid mentoring, अतिरिक्त समय, online leaked questions, या हाल ही में इंटरव्यू दे चुके परिचित — इन सब से कुछ उम्मीदवारों को बढ़त मिलती है। आदर्श रूप में सबको समान वातावरण मिलना चाहिए
    • कठिनाई (Difficulty): अच्छा इंटरव्यू इतना कठिन होना चाहिए कि अधिकांश लोग असफल हों। सबसे अच्छा रूप वह है जिसमें कई insights की ज़रूरत वाले व्यापक और अस्पष्ट सवाल हों

  • Cost to company

    • इंटरव्यू सवाल तैयार करने में काफी समय लगता है: शुरुआती design, trial approval, role और level के हिसाब से scorecard बनाना, internal और external candidates पर test करना, और interviewer documentation व training
    • सवाल और scorecard लगातार calibrate करने पड़ते हैं, इसलिए यह निवेश लगातार बना रहता है
    • कठिनाई (Difficulty): सवाल बनाना मुश्किल है, लेकिन पर्याप्त कठिन सवाल बनाना और भी बड़ी चुनौती है। बहुत आसान या बहुत कठिन — दोनों ही सबका समय बर्बाद करते हैं
    • उम्मीदवार के लिए आकर्षण (Appeal to candidate): बहुत समय लेने वाली प्रक्रिया या उबाऊ सवाल अच्छे engineers को दूर कर सकते हैं और conversion rate घटा सकते हैं। सवाल engineering culture भी दिखाते हैं
  • ये दोनों आयाम पूरी तरह स्वतंत्र नहीं हैं; उदाहरण के लिए कठिनाई दोनों को प्रभावित करती है। कठिन इंटरव्यू मजबूत उम्मीदवारों को चमकने देते हैं, लेकिन false negative भी बढ़ा सकते हैं
  • इंटरव्यू का परफेक्ट होना ज़रूरी नहीं है; false negative और false positive हमेशा रहेंगे। false negative पहचानना कठिन है, लेकिन अच्छी onboarding और पहले six months के साफ milestones से false positive को जल्दी हटाया जा सकता है

इंटरव्यू प्रकारों का वर्गीकरण

  • Take-home

    • उम्मीदवार (1) एक अस्पष्ट समस्या, जैसे product spec, का समाधान तैयार करता है और (2) कुछ तकनीकी सीमाओं, जैसे programming language list, का पालन करते हुए submit करता है
    • अक्सर इसके बाद एक review interview होता है, जिसमें उम्मीदवार अपना काम प्रस्तुत करता है और वहीं बदलाव करता है
    • Signal quality: (AI से पहले) उच्च — design, coding, detail, testing आदि का व्यापक signal देता था; 6+ घंटे लगाना motivation का भी संकेत था
    • Cost to company: मध्यम — evaluation automate की जा सकती है, deliverable यानी code को asynchronously review किया जा सकता है, लेकिन इससे उम्मीदवार दूर भी जा सकते हैं
    • AI और अत्यधिक motivated लोगों के सामने यह बहुत कमजोर है

  • Live exercise

    • algorithm & datastructure, live coding, system design, postmortem review आदि, आमतौर पर 1 घंटे या उससे अधिक। जैसे "Netflix architecture design" या "rate-limiter लिखना" जैसे सवाल interviewer के सामने उसी समय हल करने होते हैं
    • Signal quality: मध्यम — सही design और संचालन होने पर यह अपेक्षाकृत objective होता है, लेकिन signal अक्सर एक ही विषय पर केंद्रित होता है
    • Cost to company: मध्यम — उम्मीदवारों की तैयारी के असर को कम करने के लिए बहुत से अलग-अलग सवाल चाहिए
    • कुछ कंपनियाँ लागत घटाने के लिए automated services का उपयोग करती हैं

  • Presentation

    • जैसे "आपने lead किया हुआ project समझाइए", "architecture diagram", या "ऐसा अनुभव जब..." — इसमें उम्मीदवार खुद समस्या और जवाब चुनता है
    • Signal quality: कम — इसमें fail होने के कई तरीके हैं
      • उम्मीदवार ने कभी दिलचस्प समस्या पर काम ही न किया हो (जैसे junior), उबाऊ समस्या चुने, impact या contribution बढ़ा-चढ़ाकर बताए, presentation की तैयारी कमजोर हो, communication अच्छा हो पर execution कमजोर हो, या interviewer के domain knowledge की कमी से गलत मूल्यांकन हो
    • Cost to company: कम — calibration के लिहाज़ से बहुत तैयारी नहीं करनी पड़ती
    • "अगर दोबारा करना हो तो क्या बदलेंगे?" जैसे retrospective सवाल या "अगर requirement X बदल जाए तो?" जैसे hypothetical सवाल इस कम signal quality को कुछ हद तक सुधार सकते हैं। तब यह uncalibrated live exercise के करीब पहुँचता है, लेकिन interviewer से अधिक मेहनत और expertise माँगता है

  • Actual work (यह वास्तव में इंटरव्यू प्रकार नहीं है)

    • एक हफ्ते तक paid basis पर साथ काम करना। Linear जैसी कंपनियाँ इसका उपयोग करती हैं
    • Signal quality: उच्च / Cost to company: उच्च
  • अधिकतर कंपनियाँ इन प्रकारों का मिश्रण इस्तेमाल करती हैं, और Live exercise सबसे प्रमुख है

सवालों का leak होना केवल समय की बात है, AI से अलग

  • सवालों का leak होना केवल समय की बात है; Glassdoor जैसी साइटें इंटरव्यू के लगभग सभी राज़ सूचीबद्ध कर देती हैं। कुछ उम्मीदवार तो सवाल बेचने के लिए भी इंटरव्यू प्रक्रिया से गुजरते हैं
  • इसे नज़रअंदाज़ करने पर signal कमजोर हो जाता है और इंटरव्यू प्रदर्शन का मुख्य कारक "क्या आपने हमारी इंटरव्यू प्रक्रिया खोज ली थी" बन जाता है

  • जवाबी रणनीतियाँ

    • तैयारी को नियंत्रित करें (Control the preparation): mix में presentation शामिल करें, या बहुत स्पष्ट guidelines दें, जैसे "system design database-केंद्रित होगा" या "algorithm section graphs पर होगा", ताकि अधिक समान वातावरण बने
    • प्रकार के भीतर सवालों की विविधता: पुराने सवालों को नियमित रूप से archive करें। अगर उम्मीदवार सही-सही सवाल न भाँप सके, तो उसे तैयारी का दायरा बढ़ाना पड़ेगा — यही लक्ष्य है। हालांकि इसकी लागत है
    • leak करना कठिन बनाना (Make it harder to leak): onsite interview, whiteboard का उपयोग, और सबसे leak-prone सवालों को प्रक्रिया के अंत में रखना, जहाँ उम्मीदवारों की संख्या कम होने से leak की संभावना भी कम होती है

AI coding मौजूदा इंटरव्यू मॉडल के लिए खतरा है

  • (1) Take-home उम्मीदवार के लिए बहुत आसान और कंपनी के लिए बहुत महँगा हो गया है

    • 2026 तक ज़्यादातर submissions AI-generated या AI-assisted होने की संभावना है, और जो assignments अभी किसी तरह टिके हुए हैं, उन्हें अगली model release हल कर देगी — यह केवल समय की बात है
    • नतीजा यह होगा कि ज़्यादातर उम्मीदवार पहला चरण पार कर जाएँगे, जिससे review में बहुत समय लगेगा। AI से बने submissions को AI से review करना अव्यावहारिक है
    • AI coding इंटरव्यू की लागत उम्मीदवार से interviewer पर शिफ्ट कर देता है
      • Brandolini's law के अनुसार, खराब code का खंडन करने में जितनी ऊर्जा लगती है, वह उसे बनाने की ऊर्जा से एक order अधिक होती है

  • (2) अगर code लिखने का समय घट रहा है, तो live-coding का भार कम करना स्वाभाविक है

    • जैसे हम machine code लिखने के बजाय high-level language इस्तेमाल करते हैं, वैसे ही इंटरव्यू में इस्तेमाल होने वाले tools को भी रोज़मर्रा के काम के करीब लाना तर्कसंगत लग सकता है

  • (3) अगर सवाल leak हो जाएँ, तो AI बहुत शक्तिशाली coach बन जाता है

    • पहले सवाल खोजने और तैयारी करने में बहुत समय व संसाधन लगते थे; अब AI से सबसे सस्ती और सबसे ताकतवर मदद मिल सकती है

पारंपरिक शैक्षणिक मूल्यांकन मॉडल ने तकनीक का कैसे प्रतिरोध किया

  • फ़्रांस के high school और university exams अधिकांशतः अब भी लगभग उसी रूप में हैं
    • सामग्री (lecture, किताबें आदि) ले जाना मना, tools (खासकर calculator) लगभग निषिद्ध, पहले से content सार्वजनिक नहीं, अंदाज़ा लगाना मुश्किल (हर exam अलग और एक बार उपयोग), और सवाल व्यापक व अस्पष्ट
    • फ़्रेंच literature exam का सार dissertation है, जिसमें एक वाक्य के विषय पर 5–10 पन्नों का essay लिखा जाता है; यह 1830 से मौजूद है। science exams में भी 3–4 अस्पष्ट समस्याएँ हल करने का मिलता-जुलता ढाँचा होता है
  • take-home, multiple-choice knowledge questions, group assignment, presentation जैसे अन्य evaluation forms भी हैं, लेकिन वे अपवाद हैं, सिद्धांत नहीं
  • फिर से वर्गीकरण करने पर
    • Signal quality: उच्च — तैयारी का दायरा बहुत बड़ा है और लगातार मेहनत चाहिए
    • Cost: बहुत उच्च — हर exam के लिए नया विषय और grading guide बनानी पड़ती है, और सभी उम्मीदवार एक ही समय में वही exam दें; यह corporate interviewing में लगभग अव्यावहारिक है
  • दिलचस्प बात यह है कि copy-paste, internet, calculator, solver जैसे cognitive tools में भारी उन्नति के बावजूद यह मॉडल मूल रूप से नहीं बदला
    • शिक्षा का ध्यान उस समय के tools पर नहीं बल्कि बुनियादी क्षमताओं पर होना चाहिए; यह Aristotle के उस मॉडल से मेल खाता है जो memory (mneme) से अधिक judgment (phronesis) पर ज़ोर देता है

कंपनियों को इंटरव्यू के दौरान AI के उपयोग को सीमित क्यों करना चाहिए

  • Foundational skill बनाम instrumental skill

    • Foundational traits & skills वे क्षमताएँ, दृष्टिकोण और आदतें हैं जिन्हें बनाना कठिन या महँगा होता है
      • मूल बौद्धिक क्षमता, वर्षों की पढ़ाई और अनुभव से बनी गहरी विशेषज्ञता (जैसे प्रति सेकंड लाखों requests संभालने वाले distributed systems, या सैकड़ों microservices को monolith में बदलना), second-order reasoning, और professional ethics, integrity, resilience जैसी विशेषताएँ
      • यह वह internalized knowledge है जो समस्या की पहचान, abstraction और समाधान में मदद करता है; यही आगे और skills सीखने की नींव बनता है। इसी से लोग कहते हैं, "यह स्मार्ट है, सीख लेगा"
    • Instrumental skills वे हैं जिन्हें जल्दी या कम लागत में विकसित किया जा सकता है
      • किसी programming language में intermediate fluency, text editor का ठीक-ठाक उपयोग, documentation search करना, AI prompts ट्यून करना
    • इंटरव्यू में अक्सर कई instrumental skills के signals के ज़रिए उम्मीदवार के foundational traits की जाँच की जाती है, जैसे productivity में निवेश की इच्छा या structured learning

  • तर्क 1: AI proficiency foundational skill नहीं है

    • engineering tools लगातार बदले हैं, लेकिन इंटरव्यू मोटे तौर पर वैसे ही रहे हैं (कोई low-code interview type नहीं, और system design आमतौर पर basic व unmanaged technologies पर ही रहता है)
      • बेहतरीन कंपनियाँ किसी एक tool की expertise नहीं खोजतीं; LLMs के बढ़ने से Expert Generalist का महत्व और बढ़ता है
    • यही वजह है कि programming language expertise इंटरव्यू में बहुत बड़ा कारक नहीं होती। भाषा केवल problem-solving नाम के बड़े लक्ष्य का साधन है
    • AI के मामले में भी यही बात लागू होती है। prompt/context engineering, MCP/skills definition, multi-agent workflow, harness engineering जैसी सूक्ष्म तकनीकें ज़रूर हैं, लेकिन वे फिर भी instrumental skills हैं, और वे code लिखने, review करने, scalable architecture design करने के लिए आवश्यक उसी foundational skill पर निर्भर करती हैं
    • कंपनियाँ दिमाग hire करती हैं, AI agent को लापरवाही से निर्देश देने वाले हाथ नहीं
    • review और production एक ही सिक्के के दो पहलू हैं; code, architecture, और analysis की review में लगभग वही क्षमताएँ चाहिए जो उन्हें लिखने, design करने और analyse करने में लगती हैं। business requirements को generate और validate करने के लिए इंसान चाहिए, इसलिए code review जल्द खत्म नहीं होगा; पर्याप्त विस्तार वाला spec लगभग code के बराबर होता है

  • तर्क 2: AI foundational traits और skills को छिपा देता है

    • Peter Drucker के अनुसार, आप केवल हाथ hire नहीं कर सकते; पूरा व्यक्ति साथ आता है
    • Lewis Mumford के भेद का उपयोग करें — tool (जिसे मानव worker नियंत्रित करता है) बनाम machine (जो अपनी logic से चलती है और agency रखती है)। अगर AI का उपयोग बहुत अधिक हो, तो engineer का योगदान और model का योगदान अलग करना लगभग असंभव हो जाता है
    • ऐसे engineers से सावधान रहना चाहिए जो AI को "tool" नहीं बल्कि "machine" की तरह इस्तेमाल करते हैं। AI सिर्फ शक्तिशाली autocomplete नहीं, बल्कि productivity में छलांग है, और यह सोच का बड़ा हिस्सा externalize कर सकता है। "taste" जैसे मानवीय माने जाने वाले क्षेत्र भी अब चुनौती में हैं, इसलिए Fitts' list भी पुरानी लगने लगी है
    • Plato के pharmakon पर Derrida के विश्लेषण की तरह, AI एक इलाज भी है (दोहराए जाने वाले refactor को automate करना, library-specific details सीखने का समय बचाना) और ज़हर भी (foundational skill के कमजोर होने का खतरा)
    • अगर इंटरव्यू AI पर अत्यधिक ज़ोर दे, तो वह इंसान नहीं बल्कि model ("machine") का मूल्यांकन करने लगता है। इसलिए ऐसी exercises चाहिए जो मानव reasoning को इंटरव्यू के केंद्र में रखें

  • तर्क 3: AI बहुत तेज़ी से बदल रहा है

    • Arthur Mensch (Mistral CEO) के अनुसार AI models हर 12 महीने में लगभग 1 साल का software engineering experience जोड़ लेते हैं। AI agents को intern कहने वाला मज़ाक अब फीका पड़ चुका है
    • अधिकतर कंपनियों के पास ऐसे AI-resistant सवाल लगातार बनाने और बनाए रखने की क्षमता नहीं है जो foundational skills को मजबूर करें। models हर महीने बदल रहे हैं, और सभी models तक पहुँच भी नहीं होती; ऐसे में सबसे अच्छे model को लगातार मात देने वाले सवाल बनाना हारने वाली लड़ाई है
      • Anthropic का "Designing AI resistant technical evaluations" उम्मीदवारों से नहीं बल्कि AI से "लड़ने" का एक case study जैसा है
    • और कठिन take-home बनाना वैसा है जैसे calculator की अनुमति देकर और कठिन mental math पूछना
    • AI best practices भी हर महीने बदलती हैं, और models निर्देश समझने में बेहतर होने के साथ prompt engineering का महत्व घट सकता है। इसलिए यह देखना कि उम्मीदवार ने latest tricks सीखी हैं या नहीं, कोई उपयोगी signal नहीं है
    • इसके उलट fundamentals परिभाषा के अनुसार नहीं बदलते

आपत्तियों के जवाब

  • यह कहना कि डेटा नहीं है: (1) statistical significance वाला वास्तविक प्रयोग, जैसे randomized controlled trial, लगभग असंभव है, और कोई कंपनी उससे पैदा होने वाले false negatives सहना नहीं चाहेगी; (2) अधिकतर इंटरव्यू design के निर्णय clinical-trial शैली के प्रयोगों पर नहीं, बल्कि abstract reasoning पर आधारित होते हैं
  • AI से cheating, जैसे इंटरव्यू के दौरान: अगर इसे स्पष्ट रूप से मना किया गया हो, तो AI tools का उपयोग तुरंत reject करने का आधार होना चाहिए
    • Warren Buffett के अनुसार hiring में integrity, intelligence, energy देखी जाती है; अगर integrity न हो, तो बाकी दो गुण व्यक्ति को और खतरनाक बना देते हैं। अगर ऐसे व्यक्ति को hire करना ही हो, तो बेहतर है कि वह मूर्ख और आलसी हो
  • क्या उम्मीदवारों का मूल्यांकन AI से करना चाहिए? नहीं। (1) नैतिक रूप से गलत — आप knowledge worker इंसान को hire कर रहे हैं, इसलिए मशीन सब कुछ नहीं परख सकती; (2) AI evaluation non-deterministic है और hallucination के लिए जानी जाती है, इसलिए अंत में AI की evaluation को भी किसी इंसान को review करना पड़ेगा

कंपनियों के लिए ठोस सिफारिशें

  • अधिकांश इंटरव्यू में AI के उपयोग की अनुमति न दें। किसी एक विशेष tool पर ज़रूरत से ज़्यादा ज़ोर न दें; foundational skills पर ध्यान रखें
  • Live exercise में निवेश करें। उन्हें नकली, उबाऊ, low-signal या बहुत छोटा होने की ज़रूरत नहीं है। data structure & algorithm इंटरव्यू की फिर से समीक्षा करें — वे अब भी बौद्धिक रूप से सबसे चुनौतीपूर्ण हैं। ऐसी exercises बनाएँ जो मानवीय प्रयास माँगें, और single-question overpreparation रोकने के लिए बहुत से सवालों का pool रखें
  • इंटरव्यू प्रकारों का मिश्रण रखें ताकि cost-efficient तरीके से व्यापक signal मिल सके
  • Take-home को समायोजित करें। या तो AI के उपयोग को साफ़ तौर पर मना करें, या अनुमति दें लेकिन AI output की review पर समय बर्बाद न करें। take-home के बाद अनिवार्य रूप से live exercise हो, जिसमें उम्मीदवार अपना काम प्रस्तुत करे, trade-offs समझाए, requirement changes पर बात करे, और scalability पर चर्चा करे
  • कम-से-कम एक ऐसा इंटरव्यू रखें जो review skill को मापे। इसकी निर्माण लागत कम होती है, signal दिलचस्प मिलता है, और उम्मीदवार पर बोझ कम रहता है। उदाहरण: AI plan, postmortem, existing codebase (Bug squash), product requirements document, trade-off analysis, system architecture review
  • उम्मीदवारों को onsite बुलाने पर विचार करें। cheating रोकने का यह सबसे सीधा तरीका है, और इससे सवाल leak करना भी कुछ हद तक कठिन हो जाता है। हालांकि यह केवल RTO कंपनियों पर लागू होता है
  • स्पष्ट interview preparation guide दें ताकि सभी को अपेक्षाकृत समान वातावरण मिल सके

संबंधित पढ़ाई

3 टिप्पणियां

 
roxie 3 시간 전

मुझे लगता है कि 1 हफ्ते तक साथ काम करना अच्छा रहेगा।
 
linusjeh 3 시간 전

वो लेख भी AI से ही लिखा होगा, lol
 
jjpark78 3 시간 전

वैसे भी काम करते समय AI का इस्तेमाल होगा, तो उसे बाहर रखना कितना मायने रखता है, यह सोचने वाली बात है। मेरी नज़र में बेहतर यह होगा कि remote interview ही हटा दिए जाएँ, उन्हें सिर्फ on-site चलाया जाए, और वहीं इस बात का आकलन किया जाए कि कोई AI का इस्तेमाल कैसे करता है और कैसे सोचता है—इसके लिए अच्छी तरह डिज़ाइन किए गए सवाल और monitoring ज़्यादा उपयुक्त नहीं होंगे, खासकर AI युग में?

एक ही समस्या में भी कोई prompt कैसे लिखता है, यह देख कर उस व्यक्ति के बारे में बहुत कुछ जाना जा सकता है।