Live coding interview सिर्फ़ तनाव को मापते हैं, coding skill को नहीं

 (hadid.dev)
14 पॉइंट द्वारा GN⁺ 2025-08-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Live coding interview वास्तव में इंजीनियर की coding ability से ज़्यादा उसकी stress response को मापते हैं
  • वैज्ञानिक शोध के अनुसार, रीयल-टाइम में देखे जाने वाले माहौल में cognitive ability में गिरावट और performance में भारी उतार-चढ़ाव दिखता है
  • खासकर महिला उम्मीदवारों के मामले में, सार्वजनिक माहौल में सभी असफल रहीं, जबकि निजी माहौल में सभी पास हो गईं
  • अधिकांश कंपनियाँ stress adaptation की माँग नहीं करतीं, फिर भी coding test के ज़रिए गलती से उसी का आकलन करती हैं
  • Mock test, gradual exposure, और कुछ सहायक supplements तनाव कम करने में मदद कर सकते हैं

Live coding interview के बारे में व्यक्तिगत अनुभव

  • कुछ लोग live coding interview का आनंद लेते हैं, लेकिन लेखक ऐसा नहीं करता
  • लेखक Toptal के आवेदन प्रक्रिया में live coding test में असफल हुआ, लेकिन बाद में अकेले दोबारा हल करने पर उसे जल्दी सुलझा लिया
  • इस अनुभव से यह समझ में आया कि रीयल-टाइम निगरानी के दौरान तनाव के कारण व्यक्ति अपनी वास्तविक क्षमता नहीं दिखा पाता

तनाव पर प्रतिक्रिया देने वाला मस्तिष्क

  • उच्च-जोखिम और समय-सीमा के दबाव वाली स्थिति में मस्तिष्क का amygdala सक्रिय हो जाता है और cortisol level बढ़ जाता है
  • इसके कारण जटिल reasoning और memory संभालने वाले prefrontal cortex के functions प्रभावित होते हैं
  • working memory नई समस्याएँ हल करने की क्षमता का सबसे महत्वपूर्ण पैमाना है, और live coding की स्थिति में यह काफ़ी घट जाती है
  • हल्की performance anxiety होने पर भी साफ़ सोच पाना लगभग असंभव हो जाता है
  • ध्यान केंद्रित करना मुश्किल हो जाता है, कई steps एक साथ याद नहीं रहते, और व्यक्ति को लगता है कि वह ‘अपनी सामान्य क्षमता से बहुत कम’ हो गया है

निर्णायक शोध निष्कर्ष

  • Microsoft researchers के एक पेपर में एक ही coding problem को private environment और public environment में हल करवाकर तुलना की गई
  • private environment में उम्मीदवार अकेले कमरे में काम करते थे, जबकि public environment में supervisor के सामने अपने सोचने की प्रक्रिया बोलते हुए हल करना होता था
  • नतीजतन, देखे जाने वाले माहौल में प्रदर्शन आधा रह गया, और खास तौर पर performance variance बहुत बढ़ गया
  • पुरुष उम्मीदवारों से अलग, public environment में सभी महिला उम्मीदवार असफल रहीं, जबकि private environment में सभी पास हो गईं
  • live coding environment वैज्ञानिक रूप से सिद्ध exclusion filter की तरह काम करता है, जो सक्षम इंजीनियरों को बाहर कर देता है

तनाव में प्रदर्शन की वास्तविकता

  • live coding अंततः तनावपूर्ण स्थिति में प्रदर्शन को देखने का एक proxy metric भर है
  • कुछ कंपनियाँ सचमुच ऐसे लोगों को चाहती हैं जो stress environment में अच्छा काम करें, लेकिन अधिकांश कंपनियाँ इसे job description में साफ़ नहीं लिखतीं
  • जब ज़्यादातर काम में रीयल-टाइम stress कम होता है, तब live coding में गलती होने के कारण अच्छे इंजीनियरों को बाहर कर देना उचित नहीं है
  • यह मानना अधिक उचित है कि live coding coding ability से ज़्यादा stress hormone level को मापता है

तनाव कम करने के तरीके

  • चूँकि live coding industry में आम है, इसलिए stress adaptation training की ज़रूरत है
  • वास्तविक माहौल जैसे repeated practice (Pramp, Interviewing.io, LeetCode mock tests आदि) के ज़रिए मस्तिष्क को stress का अभ्यस्त बनाया जा सकता है
  • timer लगाकर, खुद को record करके, या किसी दोस्त से देखते रहने को कहकर दबाव को धीरे-धीरे बढ़ाने वाला अभ्यास असरदार हो सकता है
  • इसके अलावा, L-tyrosine (तनाव के दौरान neurotransmitters की पूर्ति) और L-theanine (relaxation और focus में सुधार) जैसे supplements भी आज़माए जा सकते हैं
  • असली interview से पहले, जो तरीका आप पर सबसे अच्छा काम करता है उसे mock practice में ज़रूर परख लेना चाहिए

निष्कर्ष

  • live coding में कमज़ोर होना इंजीनियर के रूप में अयोग्यता नहीं, बल्कि इंसानी स्वभाव की एक सामान्य विशेषता है

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

1 टिप्पणियां

 
GN⁺ 2025-08-02
Hacker News राय

  • मैं अपने मामले को सामान्यीकृत नहीं करना चाहता, लेकिन अपना व्यक्तिगत अनुभव साझा करना चाहता हूँ। मैं अब एक सफल self-employed indie developer हूँ। मुश्किल समय में भी indie development न छोड़ने की एक बड़ी वजह यह थी कि मैं व्यावहारिक रूप से नौकरी पाने लायक स्थिति में नहीं रह गया था। मैं tech industry में उम्र-भेदभाव झेलने वाला मध्यम आयु का व्यक्ति हूँ, मेरे पास computer science की डिग्री भी नहीं है, और live coding interview में मेरा दिमाग सुन्न हो जाता है। मैं यह कहना चाहता हूँ कि हर तरह का stress एक जैसा नहीं होता। firefighter जलती इमारत में कूद जाते हैं, लेकिन अनजान लोगों के सामने बोलने से डर सकते हैं। मैं भी रोज़मर्रा के काम के stress को संभाल लेता हूँ, लेकिन यह कि कोई मेरे कंधे के ऊपर से देख रहा हो और मेरा आर्थिक भविष्य तय कर रहा हो, यह इतना भारी पड़ता है कि सहन करना मुश्किल हो जाता है। interview खत्म होने के बाद मैं coding problem अक्सर हल कर लेता हूँ। interviewers को लग सकता है कि मैं impostor हूँ, लेकिन करीब 20 साल का अनुभव इसका उलटा सबूत है। बहुत से लोग "false negative" को जैसे कोई random चीज़ मानते हैं, लेकिन मेरे जैसे लोग हर बार इसी वजह से बाहर हो जाते हैं। मैं audition-style interview में हमेशा fail होता हूँ, क्योंकि मैं मंच पर प्रदर्शन करने वाला इंसान नहीं हूँ.

    • जब दूसरों की निगरानी में मूल्यांकन होता है, उससे पूरी तरह सहमत हूँ। मैं 60 की शुरुआती उम्र में हूँ। 20–30 की उम्र में interview किसी तरह ठीक-ठाक दे लेता था, लेकिन समय के साथ interview खुद ही ज़्यादा टकरावपूर्ण लगने लगे। पहले माहौल ऐसा होता था जैसे 'किसी तरह hire करना है', अब लगता है 'hire न करने का कारण ढूँढना है'। यह age discrimination भी हो सकता है, लेकिन मुझे industry culture में बदलाव भी दिखता है। पिछले 15 सालों में interview का अनुभव लगातार अधिक अप्रिय हुआ है, और interview के दौरान panic भी हुआ है। फिर भी किसी तरह job मिलती रही, और referrals की वजह से बिना interview वाले contract काम भी किए। आख़िरी startup, जहाँ मैं था, 2022 के अंत में funding खत्म होने से बंद हो गया, और तभी मैंने retire होने का फैसला किया। मुझे काम सच में बहुत पसंद था, और मैं latest tech के साथ काम भी कर रहा था, लेकिन अब interview झेलना संभव नहीं रह गया था.

    • मुझे लगता है कि समस्या इसी structure में है। आजकल के coding interview ऐसे लगते हैं जैसे यह जाँचने के लिए बनाए गए हों कि किसी युवा candidate ने CS data structure homework किया है या नहीं। 2010s के FAANG जैसे mass hiring वाले माहौल में इसका कुछ मतलब रहा होगा, लेकिन छोटे और मध्यम आकार की कंपनियों में असल दुनिया के हालात पर ध्यान देना, जैसे code पढ़ना या edge case पर चर्चा करना, कहीं बेहतर है। मैंने 20 साल से ज़्यादा startup में काम किया है, लेकिन ऐसे test अब भी pass नहीं कर पाता। रटकर याद करना भी नहीं चाहता। अगर कोई जगह इसी पर ज़ोर देती है, तो शायद वहाँ मेरा fit न होना ही ठीक है। मैं CTO भी रह चुका हूँ, कई कंपनियाँ launch की हैं, teams manage की हैं, फिर भी मुझे फिर से fresher की तरह treat किया जाता है। एक बार LRU cache जल्दी और साफ़-सुथरे तरीके से न बना पाने पर reject कर दिया गया था, लेकिन आज के startup में इसकी ज़रूरत कितनी होती है, इस पर मुझे शक है। हाल में तो मैंने इसका इस्तेमाल भी नहीं किया। अगर मैं ऐसे problem तुरंत न सुलझा पाऊँ तो मैं अयोग्य दिख सकता हूँ, लेकिन जो चीज़ काम में आती ही नहीं, उसे परखने का मतलब मुझे समझ नहीं आता। यह वैसा है जैसे architect को slide rule चलाने की क्षमता पर hire करना। इस तरह की hiring अंततः complex codebase बनाती है, जबकि असली ज़रूरत complexity नहीं बल्कि business goal पूरा करना है। मैं ऐसे सहकर्मियों के साथ काम करना चाहूँगा जो समस्याओं को छोटे हिस्सों में बाँटें और logic व structure को simple रखें। leetcode से smart लोगों को चुनने का अपना फायदा हो सकता है, लेकिन असल दुनिया की समस्याएँ लगातार और प्रभावी ढंग से हल करने वाला व्यक्ति अधिक मूल्यवान है.

    • मैं hiring side पर रहते हुए ऐसी स्थिति से गुज़रा हूँ। मैंने एक student का phone interview लिया था, जो लंबे समय से project में शामिल था, लेकिन कई तरह के stress और language barrier की वजह से वह अपनी क्षमता नहीं दिखा पा रहा था। मैं format बदलने को तैयार था, लेकिन candidate ने खुद ही कहा कि वह आगे कोशिश नहीं करेगा। दूसरी तरफ, अगर asynchronous coding interview किया जाए, तो शायद हम सिर्फ यह जाँच रहे होंगे कि LLM इस्तेमाल हुआ या नहीं। अगर चुनना पड़े कि interview में freeze हो जाने वाले लोगों को filter करें या बिल्कुल अयोग्य fraud को, तो मैं पहले वाले को filter करना बेहतर मानूँगा.

    • मैंने company में इस तरह का temperament mismatch बहुत देखा है। कई programmer introvert होते हैं, लेकिन hire करने वाले अक्सर extrovert होते हैं। अगर इस फ़र्क को ठीक से manage न किया जाए, तो introvert talent बाहर रह जाता है या समझा नहीं जाता। open seating environment भी ऐसा ही मामला है। managers को collaboration पसंद हो सकता है, लेकिन introvert लोगों के लिए यह बहुत मुश्किल माहौल होता है.

    • जानना चाहता हूँ कि आपको indie development में सफलता मिलनी कैसे शुरू हुई। मैं भी लगभग 40 का हूँ और लंबे समय से programming को hobby की तरह करता आया हूँ, लेकिन पिछले साल से इसे गंभीर पेशा बनाने का फैसला किया है। Github पर मेरे कई public project हैं, दूसरे क्षेत्रों में सफलता का अनुभव भी है, और communication skills भी बुरी नहीं हैं। फिर भी live coding में दिक्कत होती है। independent contribution वाले ऐसे रास्ते के बारे में आपका क्या विचार है जिसमें असली skill दिखाई जा सके? अगर मेरे पास सचमुच क्षमता है, तो मैं उससे कमाना चाहता हूँ.

  • इस हफ्ते मैंने Data Engineering candidate का interview लिया। मैंने उसे 4 बहुत basic SQL statements दिए, तो उसने problem ज़ोर से पढ़ी और तुरंत सही syntax के साथ जवाब दे दिया। आख़िरी सवाल थोड़ा मुश्किल था और वह अटक गया। मैंने कहा, "result check करो," तो उसे समझ नहीं आया और वह defensive हो गया। मैंने कहा, "table dump करके देखो," तब भी वह बिल्कुल नहीं समझा और बहाने बनाने लगा। अंत में उसने जो SQL paste किया उसमें [redacted].ai output में दिख रहा था। लगता है पहले सवाल AI से हल किए थे, और आख़िरी सवाल में राज़ खुल गया। अगर ऐसे technical सवाल न होते, तो cheating पकड़ में नहीं आती.

    • AI interview cheating tools युवा लोगों में बहुत फैल चुके हैं। कुछ मामले तुरंत पकड़ में आ जाते हैं, लेकिन अनुभवी candidate AI का इस्तेमाल और बीच-बीच में 'आवाज़ नहीं आ रही' जैसी चीज़ों से gaps छिपा लेते हैं। जिस managers group में मैं हूँ, वहाँ हाल के समय में hiring पर सबसे ज़्यादा चर्चा इसी विषय पर हो रही है। जिन कंपनियों के पास क्षमता है, वे आख़िरी interview in-person करती हैं। remote screen पर लोग ठीक लगते हैं, लेकिन सामने मिलने पर basic सवाल भी नहीं कर पाते, और तब reject करना पड़ता है। यह time और money की बर्बादी है, लेकिन bad hire की लागत से बेहतर माना जाता है। AI का इस्तेमाल सिर्फ technical interview तक सीमित नहीं है; resume, behavioral question, यहाँ तक कि ChatGPT द्वारा बनाए गए S.T.A.R. format answers तक हर जगह है। भरोसेमंद reference check पहले से कहीं ज़्यादा महत्वपूर्ण हो गया है। कई बार ऐसा हुआ है कि पुराने manager ने जिस काम की बात की, वह resume में लिखी बात से पूरी तरह अलग निकली। अगर candidate शुरू से ईमानदारी से कहता कि उसके पास हमारे domain का direct experience नहीं है, तो शायद हम उसे hire कर लेते, लेकिन जब झूठ इतना मज़बूत हो, तो भरोसा बिल्कुल नहीं बनता.

    • आजकल candidates का interview लेते हुए लगभग 50% लोग live GenAI का real-time इस्तेमाल कर रहे थे। अभी तक यह पहचानना बहुत आसान रहा है कि कौन AI इस्तेमाल कर रहा है। सामान्य बातचीत में यह जल्दी सामने आ जाता है। विडंबना यह है कि आख़िरी candidate भी हमेशा सवाल दोहराकर 10–15 सेकंड रुकता था। इससे साफ़ है कि इस तरह के test मूल समस्या का समाधान नहीं हैं। बल्कि यह नए problem पैदा करते हैं और उत्कृष्ट candidates को reject करवाते हैं.

    • "अगर AI का उपयोग cheating नहीं, बल्कि वही काम है जो असली job में करना होगा, तो?" इस नज़रिए से देखें तो वह interview वास्तव में एक बहुत प्रभावी, छोटे पैमाने का <i>requirements interpretation</i> उदाहरण था। अंततः ज़्यादा सकारात्मक दिशा यह होगी कि लोगों को वही tools इस्तेमाल करने दें जो वे काम में करेंगे, और उसी के भीतर role तथा language की मूल समझ को test करें। ज़रूरत सिर्फ Leetcode से बाहर निकलने की नहीं, बल्कि बेहतर तरीक़ा खोजने की है.

  • आख़िरकार सब कुछ 'depends' करता है। live coding interview भी ऐसा ही है। candidate के नज़रिए से यह सबसे अच्छा अनुभव नहीं है, लेकिन Meta, Google जैसी बड़ी कंपनियों में यह दूसरे तरीक़ों की तुलना में false positive कम करने में बेहतर काम करता है। हालाँकि, interviewers अक्सर पर्याप्त रूप से trained नहीं होते, और सवाल पहेली जैसे होते हैं, इसलिए बहुत LeetCode practice या recent academic background न हो तो यह कठिन हो जाता है। मैंने 6 साल assessment के क्षेत्र में काम किया है और Fortune 10 से लेकर startup तक, कई hiring process नज़दीक से देखे हैं। मैं candidates के लिए actual work के क़रीब evaluations की सिफारिश करता हूँ, और 'असल काम' के नाम पर unpaid labor जैसी चीज़ों को अब पसंद नहीं करता। assessment ऐसा साधन होना चाहिए जिससे company ऊँची salary का offer आत्मविश्वास से दे सके। AI के आने से छोटे take-home problem भी fairness बनाए रखना मुश्किल हो गया है। इसलिए कुछ कंपनियाँ फिर से on-site interview, live monitoring जैसे चरम तरीक़ों पर लौट रही हैं। मेरे हिसाब से आदर्श समाधान यह है कि हर candidate को एक जैसा समय, environment और tools मिले, ताकि वह अपनी सर्वोत्तम क्षमता दिखा सके। मैं इस समस्या पर लगातार सोचता हूँ, लेकिन अभी तक जवाब नहीं मिला है.

    • लोग कहते हैं "Meta, Google के स्तर पर यह काम करता है," लेकिन असल में data नहीं है। मैंने Facebook और Google background वाले F-grade developers के साथ काम किया है। हक़ीक़त यह है कि ऐसी बड़ी कंपनियाँ भी 3–5% workforce को निकालती रहती हैं, और यह इस बात का सबूत है कि interview false positive को सही से नहीं रोक पाते। interviewers जितना समय लगाते हैं, उसके मुकाबले 3% error rate भी बहुत ज़्यादा है। यह मूलतः पुराने 'Fizzbuzz' स्तर से बहुत अलग नहीं है.

    • यह ऐसा है जैसे किसी mason से दीवार बनवाकर देखने के बजाय, सिर्फ certificate verify करके तुरंत hire कर लिया जाए। कई professions में यही होता है। अगर skill fit न हो, तो hire करने के बाद निकाल दिया जाता है। अपमानजनक corporate interview process से गुज़रने की कोई ज़रूरत नहीं होनी चाहिए.

    • मैंने जिन बेहतरीन engineers को देखा है, वे अक्सर false negative के रूप में classify कर दिए जाते थे। live coding interview में घबराहट के कारण वे खुद को ठीक से दिखा नहीं पाते। इसलिए मैं यह नहीं मानता कि ऐसे interview को सीधा-सीधा "अच्छा काम करता है" कहा जा सकता है.

    • "depends" कहने के बाद "live coding interview काम करता है" जैसी ठोस बात कहना खुद में विरोधाभासी है। उसी तरह मैं भी कह सकता हूँ, "depends, लेकिन live coding interview काम नहीं करता।" तर्क में कोई फ़र्क नहीं है.

    • leet-code pass करना उन लोगों को filter करने में काम आ सकता है जिनमें सचमुच problem-solving skill नहीं है। सबसे अच्छा समाधान यह होगा कि candidate को उसके अपने tools और environment में अधिकतम क्षमता दिखाने दिया जाए। लेकिन व्यवहार में, शायद leetcode को interviewer के साथ whiteboard पर offline pair programming करते हुए solve करना सबसे fair माना जा सकता है। वही तो सचमुच आरामदायक environment है.

  • मुझे लगता है दोनों बातें एक साथ सच हो सकती हैं। वास्तव में ऐसे "senior" developer होते हैं जो काम ठीक से नहीं कर पाते, और live coding उन्हें filter करने में मदद कर सकता है। लेकिन लोग दूसरे कारणों से भी interview में fail हो सकते हैं.

    • बहुत से developer live coding में अच्छे होते हैं, लेकिन large-scale system design का अनुभव कम होता है। ऐसे लोग अक्सर technical debt, anti-pattern और inconsistency लाकर codebase को और बिगाड़ देते हैं। वास्तव में यही वे लोग हैं जिनसे बचना चाहिए। company मान लेती है कि existing seniors नए लोगों को नियंत्रित कर लेंगे, लेकिन हर company कहती है कि "हमारा codebase कचरा है," इसलिए यह उपाय भी बहुत असरदार नहीं लगता.

    • अगर लोगों को अकेले कमरे में बैठकर code करने दिया जाए, तो उन अच्छे candidates को नहीं खोएँगे जो सिर्फ असामान्य माहौल में ही अच्छा प्रदर्शन नहीं कर पाते.

    • हाल के live coding interview अब सिर्फ साधारण coding test नहीं रहे। अब इनमें कई algorithm याद रखने पड़ते हैं, और 30 मिनट में 2–3 algorithm जोड़कर समस्या हल करनी होती है। समस्या सुलझाने में ही सारा समय निकल जाता है, इसलिए असली coding skill दिखाने का समय ही नहीं बचता.

    • 20 साल के पेशेवर जीवन में मैंने ऐसे "अयोग्य senior" के साथ वास्तव में कभी काम नहीं किया। resume और 15 मिनट की बातचीत से ही उन्हें छाँटा जा सकता था। उल्टा, whiteboard interview पास करके भी team productivity खराब करने वाले लोग कहीं ज़्यादा देखे हैं.

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

  • मेरे हिसाब से किसी की job performance सचमुच जानने का एकमात्र तरीका है उसे वही job करके दिखाने देना। अगर कोई वैकल्पिक मूल्यांकन हो भी, लेकिन जब असली काम कराया जा सकता है, तो दूसरा तरीक़ा चुनने का कारण नहीं है। अगर company का काम इतना complex है कि उसे interview में छोटे हिस्से में नहीं बदला जा सकता, तो शायद company अनावश्यक रूप से बहुत complex काम कर रही है। उदाहरण के लिए, अगर 10 kilogram उठाने की क्षमता चाहिए, तो candidate से 10 kilogram का बोझ उठवा कर देखिए। लेकिन हम करते यह हैं कि 'strength जाँचनी है' कहकर 'पैंट उतारो और 1kg की बाल्टी को पीछे से पकड़कर उठाओ' जैसी अजीब परीक्षा लेते हैं। अंततः बस वही skill देखनी चाहिए जो असली काम में चाहिए। chef है तो असली kitchen में खाना बनवाइए, support role है तो mock situation में communication देखिए। phone screening के मामले में भी live screen देखकर यह किया जा सकता है.

    • इसके जवाब में तर्क दिया जाता है कि "अगर interview में असली काम कराया जाए, तो cheating या unpaid labor का मुद्दा नहीं उठेगा?" अगर company interview task का उपयोग अपने लाभ के लिए करे, तो कानूनी समस्या हो सकती है.

    • एक सुझाव यह भी है कि लोगों को एक दिन, एक हफ्ते या एक महीने के लिए सीधे hire करके काम कराया जाए, और fit होने पर permanent hire कर लिया जाए। हालांकि, यह American employer healthcare system के साथ ठीक से मेल नहीं खाता.

    • company के नज़रिए से यह बहुत time-consuming है। इसलिए वे false positive से अधिक false negative की ओर झुके हुए proxy इस्तेमाल करती हैं.

    • अगर interview में असली काम कराया जाए, तो 'free labor' माँगने वाली चिंता पर आपका क्या विचार है?

    • नए organization में ढलने में समय लगता है, इसलिए actual work के ज़रिए test करना उल्टा inefficient हो सकता है। live coding assessment से communication, problem-solving और pure coding skill मापना बेहतर है.

  • बच्चे होने के बाद से interview coding की मेरी क्षमता बहुत गिर गई है। पहले कभी ऐसा नहीं हुआ था, लेकिन अब लगता है interview पर बहुत कुछ दाँव पर लगा होता है। health insurance, loan, retirement जैसी चीज़ें याद आते ही दबाव बढ़ जाता है। interview के दौरान मैं पूरी तरह freeze हो जाता हूँ, और बाद में समाधान सूझता है, यह बहुत तकलीफ़देह है। जितना ज़्यादा practice में समय लगाता हूँ, उतना ही प्रदर्शन और गिरता लगता है। dependents होने की वजह से practice पर समय खर्च करने में guilt भी होता है। सीखने का असर भी कम लगता है और मैं और सिकुड़ जाता हूँ। big tech में काम करते हुए मैंने देखा कि यह interview style बहुत आदर्शवादी ढंग से "सबको बराबरी से test करेंगे" सोचकर लाई गई थी, लेकिन वास्तविक जीवन की परिस्थितियों के बदलाव या असमानता को बिल्कुल नहीं मानती। जो सहकर्मी आज stress में मज़बूत है, वह कुछ साल बाद वैसा न भी रहे। bias हटाने के नाम पर शुरू हुई चीज़ को अब बदलने की ज़रूरत है.

    • आप इन भावनाओं में अकेले नहीं हैं। उम्र बढ़ने के साथ learning speed धीमी होती है, खाली समय कम हो जाता है, और leetcode practice का return घटता जाता है। यह बात चुभती है कि आख़िर में ज़्यादा free time वाले लोगों को ही reward मिलता है.

    • stress कम करने के लिए meditation, breathing, L-Theanine, beta blocker जैसी चीज़ें आज़माने की सलाह दूँगा। smartwatch से heart rate और blood pressure monitor करने की भी सिफारिश करूँगा। ऐसे तरीक़े सच में stress के vicious cycle को कम करने में मदद करते हैं.

  • यह रोज़मर्रा के काम के stress से गुणात्मक रूप से अलग, बहुत अधिक तीव्रता वाला stress environment है। Google interview का अपना अनुभव बताऊँ तो, मैं Netherlands का पहला local search engine बनाने वाला व्यक्ति हूँ, लेकिन Google में cowboy hat पहने interviewer ने मुझसे whiteboard पर marker से binary search code लिखने को कहा। मैं सामान्यतः हाथ से लिखता नहीं, सिर्फ keyboard इस्तेमाल करता हूँ, और उसने मेरे search index design के अनुभव को देखने की कोशिश भी नहीं की। शायद Google को 'cowboy' mindset चाहिए था.

    • मैंने भी कभी Google recruiter के मनाने पर interview दिया था, लेकिन interviewer इतने ख़राब थे कि technical interview skip कर देने के बावजूद, उसके बाद से Google की हर offer ठुकरा रहा हूँ। ज़्यादातर सवाल 'gotcha' style के थे, या बहुत पुराने और वास्तविकता से कटे हुए UNIX structure (जैसे inode structure) पर थे। उस role से उनका कोई संबंध नहीं था। कंपनियों को interview questions पर tracking, feedback process और interviewer training ज़रूर रखनी चाहिए। आज भी बहुत सी कंपनियों में सवाल interviewer की निजी पसंद से तय होते हैं.

    • यह system वास्तव में जैसा बना था वैसा ही काम कर रहा था। ऐसी कंपनियाँ ऐसे लोगों को चाहती हैं जो उनके यहाँ किसी भी तरह का अपमान सह लें। आप दोनों एक-दूसरे के लिए fit नहीं थे, तो दोनों की ही जीत हुई.

    • अगर binary search लिखने को कहना आपको अपमानजनक लगा, तो शायद आपका ego बहुत बड़ा है.

    • अगर सालाना $250k और अतिरिक्त Google stock options दाँव पर हों, तो एक दिन का "अपमान" मैं ख़ुशी से सह लूँगा.

  • मैं live coding screening को 'code पर बातचीत' की तरह लेता हूँ। मैं candidate को साफ़ बता देता हूँ कि interview का उद्देश्य यह देखना है कि क्या हम एक-दूसरे से अच्छे से communicate कर सकते हैं। सिर्फ skill काफ़ी नहीं है, साथ काम भी कर पाना चाहिए। उदाहरण के लिए, अगर बातचीत के दौरान misunderstanding से implementation ग़लत हो जाए, या कोई candidate code अच्छा लिख ले लेकिन technical discussion न कर पाए, तो वह भी problem है। इसलिए Fizzbuzz जैसे सवाल महत्वपूर्ण हैं, क्योंकि वे सिर्फ skill नहीं बल्कि 'technical discussion' की क्षमता भी test करते हैं.

    • सही कहा। live coding interview का सार यह नहीं है कि "समस्या हल कर सकता है या नहीं," बल्कि यह है कि "वह समझा सकता है कि कैसे हल करेगा।" थोड़ी technical grounding और communication ability ही असली बात है। असली job का बड़ा हिस्सा non-technical managers को बातें समझाने में जाता है, तो इसे उसी की परीक्षा समझा जा सकता है.

    • यह तरीक़ा अच्छा है। मैं FizzBuzz को कम से कम 3 भाषाओं में, 4 तरीक़ों से हल कर सकता हूँ, और सभी 12 तरीक़े समझा भी सकता हूँ.

  • मैं भी इस समस्या को समझता हूँ, और यह बात भी मानता हूँ कि कोई शानदार विकल्प मौजूद नहीं है। अपने career में मैंने कई बार ऐसे लोगों को देखा है जो सचमुच 'engineer की तरह बोलते और behave करते हैं, लेकिन code नहीं कर सकते'। interview में coding skill को नज़रअंदाज़ करके hire करने पर कई बार पछतावा भी हुआ है। मैं चाहता हूँ कि युवा developer यह भी समझें कि hiring process के कई चरण उम्रदराज़ candidates को अनुचित लाभ भी दे सकते हैं। मुझे पता है कि industry में ऐसे बहुत से engineer हैं जिनके पास वास्तविक coding ability नहीं है, लेकिन वे बेकार की 'expert' packaging से निकल जाते हैं। अगर coding process को एक बार भी देखे बिना hire करते हैं, तो यह वैसा है जैसे सिर्फ resume, बातचीत और references के आधार पर किसी band के लिए guitarist hire कर लेना। ऐसा भी हो सकता है कि कोई खुद को guitar expert बताए, लेकिन उसने कभी सच में guitar बजाई ही न हो। बिना किसी खास qualification के भी लोग इस तरह निकल जाते हैं। अगर interview में प्रत्यक्ष सबूत के बिना सिर्फ अनुमान लगाना पड़े, तो अंततः bias और preconceived notions घुस आएँगे ही.

    • "समस्या है लेकिन विकल्प नहीं" वाली बात के जवाब में कहा जा सकता है कि doctor और lawyer जैसे पेशों में license-based system भी है। surgery से पहले किसी surgeon से demo नहीं माँगा जाता, जबकि risk कहीं ज़्यादा होता है। असल में कठोर verification ज़्यादातर निचले स्तर के roles पर ही लागू होती है, जबकि ज़्यादा प्रभाव वाले managers या senior executives आसानी से निकल जाते हैं.

    • मुझे लगता है whiteboard पर pseudocode लिखवाना बेहतर है। इससे syntax का stress कम होता है और problem-solving logic ज़्यादा साफ़ दिखती है। साथ ही, यह मेरे collaboration style से भी मेल खाता है, क्योंकि मैं whiteboard पर ideas exchange करना पसंद करता हूँ.

  • "stress skill से अलग है" यह बात बार-बार सामने आती है। Microsoft का paper भी भयावह था। ज़्यादातर सलाह बस यही होती है कि "LeetCode ज़्यादा करो," लेकिन stress (cortisol) को नज़रअंदाज़ किया जाता है। मैं अब stress environment के साथ खुद को परिचित करने की practice करता हूँ। दोस्त इतने intense training partner नहीं बन पाते, और coach की hourly cost बहुत ज़्यादा है। इसलिए इन दिनों मैं Tough Tongue AI नाम का side project बना रहा हूँ। यह एक voice-based live code editor है जो real-time सवाल, interruptions और instant feedback देता है। इस training से 'कोई मुझे देख रहा है' वाली घबराहट धीरे-धीरे सामान्य लगने लगती है। अगर live coding interview जारी रहने हैं, तो algorithm नहीं बल्कि physiological response यानी stress itself को train करने के तरीक़े चाहिए.

    • यह सबसे बेहतरीन learning tools में से एक है.