LeetCode स्टाइल इंटरव्यू से तंग आ चुके लोग
(nelson.cloud)- नवंबर 2023 के आखिर में Robinhood को स्वास्थ्य कारणों से छोड़ने के बाद, कई hiring processes से गुज़रते हुए यह महसूस हुआ कि LeetCode-स्टाइल मूल्यांकन वास्तविक software engineering काम से मेल नहीं खाते
- ऐसा लगता है कि कई कंपनियाँ Google, Facebook/Meta, Amazon जैसी बड़ी tech कंपनियों का तरीका अपनाते हुए उसी तरह के इंटरव्यू दोहराती हैं
- इंजीनियर अक्सर कहते हैं कि search करके मिलने वाली जानकारी को याद रखने की ज़रूरत नहीं होती, लेकिन इंटरव्यू में उसी तरह के searchable knowledge को क्विज़ की तरह पूछा जाता है, जिसकी आलोचना की गई है
- ऐसे इंटरव्यू में सफलता और असफलता दोनों का अनुभव रहा है, और इस असंतोष की जड़ असफल इंटरव्यू से ज़्यादा पहले के व्यावहारिक कार्य अनुभव में है
- यह भी जोड़ा गया कि अगर कोई कंपनी AWS, Kubernetes, Ruby on Rails अनुभव वाले इंजीनियर की तलाश में है और बेकार क्विज़ नहीं करती, तो वह संपर्क कर सकती है
LeetCode-स्टाइल इंटरव्यू और वास्तविक काम के बीच का अंतर
- नवंबर 2023 के आखिर में Robinhood को स्वास्थ्य कारणों से छोड़ने के बाद कई कंपनियों के साथ इंटरव्यू किए गए
- hiring process कई वजहों से आगे नहीं बढ़े, लेकिन बार-बार होने वाले LeetCode स्टाइल इंटरव्यू से खुद थकान महसूस हुई
- माना गया कि ऐसे इंटरव्यू वास्तविक software engineering जिम्मेदारियों को पर्याप्त रूप से नहीं दर्शाते
- ऐसा दिखता है कि कई कंपनियाँ Google, Facebook/Meta, Amazon जैसी बड़ी कंपनियों द्वारा इस्तेमाल किए जाने वाले तरीकों को अपनाकर वही मूल्यांकन पद्धति इस्तेमाल कर रही हैं
क्विज़-आधारित मूल्यांकन और व्यावहारिक अनुभव के बीच टकराव
- कुछ इंजीनियर आम तौर पर कहते हैं कि जो चीज़ Google से आसानी से मिल सकती है, उसे याद रखने की ज़रूरत नहीं है
- लेकिन इंटरव्यू में कभी-कभी ऐसी बातें पूछी जाती हैं जिन्हें search करके जाना जा सकता है, पर तुरंत याद करना मुश्किल होता है, और यह विरोधाभासी लगता है
- इस समस्या का कोई स्पष्ट समाधान नहीं दिखता, लेकिन समस्या खुद साफ़ दिखाई देती है
- इस तरह के इंटरव्यू में सफलता और असफलता दोनों का अनुभव हुआ है, और यह दृष्टिकोण असफलता की दर से ज़्यादा पिछले पेशेवर अनुभव से प्रभावित है
- अगर किसी कंपनी को AWS, Kubernetes, Ruby on Rails अनुभव वाला software engineer चाहिए और वह क्विज़-टाइप इंटरव्यू नहीं करती, तो वह संपर्क कर सकती है
- साथ में पढ़ने के लिए Re-imagining Technical Interviews: Valuing Experience Over Exam Skills का उल्लेख किया गया है
1 टिप्पणियां
Hacker News की राय
झुंझलाहट समझ में आती है, लेकिन आखिरकार मुझे लगता है कि ऐसे interviews का भी कोई मकसद होता है। भले ये बहुत अच्छे न हों, फिर भी कामचलाऊ हैं, और आम तौर पर false positives की तुलना में false negatives ज़्यादा बनाते हैं, इसलिए कंपनी के नज़रिए से बात समझ आती है
किसी smart व्यक्ति के reject हो जाने की लागत कम होती है, लेकिन गलत व्यक्ति को hire कर लिया जाए तो कई महीनों तक उसे evaluate करना, fire करना और फिर दोबारा hiring करना पड़ता है, जिसकी लागत बड़ी होती है। हां, उम्मीदवार के लिए यह बेहद तकलीफ़देह process है, और एक शानदार software engineer भी nervous हो सकता है, कुछ miss कर सकता है, या उसका दिन खराब हो सकता है, इसलिए कुछ बार reject हो सकता है। Interview जीवन-मूल्य का अंतिम आकलन नहीं, बस एक भोंडा tool है, इसलिए इसे जाने देना चाहिए
“Trap” questions बेवकूफ़ी हैं, लेकिन यह देखना चाहिए कि candidate basics जानता है या नहीं, और साथ ही उसे यह भी दिखाना चाहिए कि हमारी company कैसी जगह है। उदाहरण के लिए “क्या arguments को modify कर सकता हूं?” पूछना, या “मुझे याद नहीं कि strlen में 0 byte शामिल होता है या नहीं, इसलिए मैं 1 add कर दूंगा; normally मैं इसे lookup कर लेता” कहना अच्छा संकेत है। Problem atoi या “ताश की गड्डी shuffle करना” जैसी थी—basic, लेकिन fizzbuzz जितनी बिल्कुल trivial नहीं। हमने जिन बेहतरीन लोगों को hire किया उनमें से एक ने एक fundamental गलती की थी, लेकिन जब पूछा कि क्या यह intended तरीके से चलेगा, तो उसने कहा “मैं तो damn idiot हूं” और तुरंत ठीक कर दिया। Interview में ऐसी भाषा शायद उचित नहीं है, लेकिन हमने इसे strong positive signal माना। इसके उलट एक candidate था जिसने अंत तक यह argue किया कि string parse करके integer return करने वाला सवाल unfair है क्योंकि उसके लिए library function पहले से है, जबकि हमारे system का कुछ हिस्सा सचमुच library-less embedded environment में था
स्कूल और कॉलेज के घटिया exams की तरह memory को पहले test करने वाले तरीके की नकल नहीं करनी चाहिए। जरूरत पड़ने पर तुरंत याद कर लेना मेरे लिए बहुत मुश्किल था, और मैं अकेला नहीं होऊंगा। Android developer interview लेते समय मैंने सवाल पूछे और देखा कि वे कैसे सोचते हैं; हर answer सही हो, ऐसी उम्मीद नहीं थी। Android की basic understanding है या नहीं देखने के बाद, उनसे घर पर एक छोटा app बनवाया
आखिरकार जब position भरनी ही होती है, तो false negatives जितने बढ़ते हैं, false positive hire करने की संभावना भी उतनी ही बढ़ती है। Extreme case में, अगर धरती पर उस काम के लिए suitable सिर्फ एक व्यक्ति है और उसे false negative में reject कर दिया जाए, तो बचा हुआ option सिर्फ गलत व्यक्ति को hire करना ही है
समस्या intelligence की कमी नहीं है; समस्या यह है कि कोई algorithm problems अच्छी तरह solve कर सकता है, फिर भी software engineer नहीं हो सकता, या उस position के लिए जरूरी skills में कमी हो सकती है। मैं एक ऐसी team में काम करता हूं जिसमें puzzle-style interviews से बहुत hiring हुई है; सब smart हैं, लेकिन software engineers नहीं हैं, और यह फर्क बहुत साफ दिखता है
अगर किसी ने solve किया है, तो यह संभावना कहीं ज़्यादा है कि उसने optimal solution सचमुच नए सिरे से derive नहीं किया, बल्कि practice problems करते हुए वही या मिलती-जुलती problem देखी थी
एक बार मेरा एक interview काफी पसंद आया था; वह एक bank में था। उन्होंने जल्दबाज़ी में लिखा गया messy code दिया, हालांकि जानबूझकर obfuscate किया हुआ नहीं था, और कहा कि जितना अच्छा हो सके refactor करो
Interviewer बगल में बैठा और पूरे process में बात करता रहा; असल में यह candidate-led pair programming जैसा था। LeetCode interviews के बाद यह fresh लगा। बेशक उस bank को ठीक-ठीक पता था कि वे कौन-सी technologies इस्तेमाल करते हैं, और नई technology सीखने की क्षमता मापने की जरूरत कम थी, इसलिए यह तरीका संभव था। उनके लिए यह ज़्यादा important था कि क्या candidate maintainable code बना सकता है, names ठीक से रखता है, और colleagues से communicate करता है
दिलचस्प बात यह है कि basic questions में लगभग fail होने वाले लोग code review में इतनी अच्छी performance दिखाते हैं कि उनकी गहरी expertise सामने आ जाती है। Interview किसी व्यक्ति की काम करने की क्षमता दिखाने के लिए काफी खराब tool है, लेकिन अगर वह problem को व्यापक और संकीर्ण दोनों तरह से देख सकता है और coding भी पर्याप्त कर लेता है, तो मैं आम तौर पर इसे success मानता हूं
LeetCode-स्टाइल इंटरव्यू शायद दो काम करते हैं। पहला, software engineers की सैलरी और नौकरी बदलने की क्षमता को दबाने का साधन हैं। नौकरी बदलनी हो तो एक-दो महीने पढ़ना पड़ता है, तो कौन आसानी से शिफ्ट करेगा
अगर बदकिस्मती से कोई खूब तैयारी करके आया interviewer LeetCode hard स्तर का बम फेंक दे, तो एक साल तक उसी कंपनी में दोबारा apply करना भी मुश्किल हो जाता है। दूसरा, यह कहकर कि सबको समान और स्पष्ट लक्ष्य दिए गए हैं, प्रक्रिया के bias को छिपाने का साधन बन जाता है। अगर वही school, gender, race हो तो वही समस्या देने पर भी hint दे सकते हैं, syntax errors नजरअंदाज कर सकते हैं, और optimal approach न आने पर भी “communication” के आधार पर strong hire दे सकते हैं। अगर कोई पसंद न हो तो कठिन problem दे दीजिए और पूरे interview में चुप रहिए। कंपनी के लिए यह स्वीकार्य noise है, लेकिन व्यक्ति के लिए लाखों डॉलर के compensation का मौका खोना है। मैंने FAANG interviews दिए भी हैं और interviewer भी रहा हूं; कम standard पर hire हुए लोगों को देखते हुए, साथ ही quadtree या number theory जैसे बेतुके सवालों की वजह से बेहतरीन engineers को मौका गंवाते देखा है
अगर interviewer के fair होने की धारणा मान लें, तो यह तरीका उन candidates को भी skill दिखाने का मौका देता है जिनके resume पर बड़े नाम नहीं लिखे हैं। मेरे पास computer science degree नहीं है, और मुझे जो कुछ मौके मिले, उनमें से कुछ whiteboard interview न होते तो कभी नहीं मिलते। अगर कोई interviewer अपने दोस्त को hire करने के लिए जानबूझकर प्रक्रिया को उलट-पुलट करना चाहे, तो उसे रोकने का कोई तरीका कल्पना करना मुश्किल है
कई कंपनियों के पास fair और कुछ हद तक real-world problems से जुड़ी problem bank होती है। जिन कंपनियों में मैंने interview दिया, वे भी ज्यादातर ऐसी ही थीं, और भले ही वे बिल्कुल LeetCode के actual problems न हों, अंततः isolated coding problems ही हैं, इसलिए मैं उन्हें LeetCode-style मानता हूं। जो कंपनियां इस तरीके को अच्छी तरह चलाती हैं, उनके interviews काफी ठीक थे। अच्छी कंपनियां और interviewers सिर्फ final code नहीं देखते, उससे ज्यादा चीजें देखते हैं, और hiring rating भी scale पर देते हैं ताकि binary फैसला कम हो
सच कहें तो सिर्फ fizzbuzz से भी 75% लोग छंट जाते थे। दबाव में बहुत से लोग code नहीं लिख पाते, और कुछ लोग copy-paste के सहारे जैसे-तैसे टिके रहते हैं। इसका मतलब यह नहीं कि वे कुछ भी नहीं कर सकते, बल्कि वे धीमे होते हैं, अजीब abstractions देते हैं, और usable result पाने तक बहुत समय खा जाते हैं। और चूंकि उनके लिए भी लाखों डॉलर दांव पर लगे होते हैं, वे भी उतनी ही जोर से argue करते हैं
कंपनी के नजरिए से यह rational है। वे ऐसे employees चाहते हैं जो distracted न हों और overtime कर सकें
आज की tech hiring practices पर कई valid criticisms हैं, लेकिन “अपनी आत्मा बेचे बिना बहुत अमीर नहीं बन सकते” वाली शिकायत बहुत convincing नहीं लगती
software engineer को screen करते समय अहम चीज knowledge नहीं, बल्कि problem-solving ability और problem का mental model बनाने की क्षमता है
अगर candidate ने वह problem पहले नहीं देखी है और interviewer समझता है कि उसे क्या देखना चाहिए, तो whiteboard interview इस क्षमता को evaluate करने का अच्छा तरीका है। लेकिन Goodhart’s law की तरह, जब metric ही target बन जाता है तो वह अच्छा indicator नहीं रह जाता। जिन लोगों की problem-solving या modeling ability कमजोर है, वे भी high-paying software jobs चाहते हैं, इसलिए LeetCode को रटते-घिसते हैं; और समय के साथ जब वही लोग interviewers बनते हैं, तो जिस तरह उनके साथ हुआ था, वे भी interview को memory test की तरह चलाते हैं। फिर भी कंपनी की constraints, candidates का समय बर्बाद होने से बचाना, और HR को पसंद आने वाली consistent scorecard बनाए रखने की शर्तों में मैंने अब तक कोई बेहतर interview method propose होते नहीं देखा है, और कुछ समय तक यह चलता रहेगा
यह software बनाने के काम के ज्यादा करीब है। LeetCode actual work से बहुत दूर है, और उसका performance भी real fit से बहुत कमजोर correlation रखता है
बाल्टी में छेद है, लेकिन कंपनी current state से संतुष्ट है, और developers लगातार LeetCode घिसते रहते हैं। जल्द बदलता नहीं दिखता, लेकिन खुशी है कि नई नौकरी ढूंढते समय मैं ऐसे interviews को मना कर सकने की स्थिति में हूं
एक दोस्त technical interview के बीच अचानक चुप हो गया और उठकर बाहर चला गया। कंपनी के लोग “क्या हुआ, आप अच्छा कर रहे हैं!” कहते हुए पीछे गए, लेकिन उसने कहा कि वह बहुत उदास हो गया है और अब interested नहीं है
ज्यादातर लोगों के लिए यह मजेदार profession होना चाहिए, इसलिए यह दुखद है
लेकिन interview के बीच में whiteboard आया और colleagues अंदर आकर pen से basic चीजें implement करने को कहने लगे। जैसे-जैसे process आगे बढ़ा, वे और adversarial और rude होते गए, और यह ritualized bullying जैसा महसूस हुआ। ऐसा लगा जैसे वे test कर रहे हों कि technically trivial result देते हुए भी क्या मैं insults और hostility सह सकता हूं। आखिर मैंने interview रोककर कहा, “मैंने देख लिया कि आप लोग कैसे काम करते हैं, इसलिए मैंने तय किया है कि मैं यहां काम नहीं करना चाहता। मौके के लिए धन्यवाद, और हम दोनों का समय बर्बाद करने के लिए माफ कीजिए,” और बाहर आ गया। CEO parking lot तक पीछे आया और पूछा कि ऐसा क्यों हुआ; उसे सच में shock लगा था कि candidate भी interview के दौरान फैसला कर सकता है। लोग भूल जाते हैं कि job interview दो-तरफा होता है। उस दिन के बाद मुझे एहसास हुआ कि जिस कंपनी में मैं काम कर सकता हूं, उसके हर पहलू को देखने का मुझे अधिकार है, और process में अगर कोई negative चीज दिखे तो compromise करना जरूरी नहीं। अगले दिन competitor company में मुझे ऐसे लोग मिले जो आज तक अच्छे दोस्त और colleagues हैं, इसलिए वह सही फैसला था। यह profession मजेदार है, लेकिन अगर उस मजे को farm की तरह काटकर exploit किया जाए, तो वह किसी और तरह की slavery से अलग नहीं है
मैंने कहा, “लगता है आज मेरा दिन नहीं है और मैं interview यहीं खत्म करना चाहता हूं,” और उसके बाद वे बाकी समय तक मुझे रुकवाने की काफी कोशिश करते रहे। मेरा मानना है कि अगर candidate जाना चाहता है, तो उसे जाने देना चाहिए
5 साल बाद भी मैं ऐसे इंटरव्यू से इनकार करता हूँ, और उस प्रक्रिया से फिर कभी नहीं गुजरना चाहता। मुझे उन लोगों ने परेशान किया और मज़ाक उड़ाया जो इंसान को एक घंटे के kicking game की तरह ट्रीट करते हैं, और अब मैं उनसे डील नहीं करना चाहता
बिना पूर्व सूचना वाले LeetCode इंटरव्यू बहुत हुए, इसलिए मैंने अपने LinkedIn [1] और GitHub [2] प्रोफाइल पर साफ़ लिख दिया है कि क्या स्वीकार्य है और क्या नहीं। “इंटरव्यू के दौरान किसी भी तरह की live coding या online coding test के खिलाफ मेरी निजी policy है, और मैं competitive programming का आनंद नहीं लेता न उसमें भाग लेता हूँ। इसके बजाय, वाजिब लक्ष्य और deadline वाले offline coding assignment, software architecture और design तथा संबंधित technologies पर गहरी technical discussion करने के लिए मैं तैयार हूँ।”
[1] https://www.linkedin.com/in/mtodor
[2] https://github.com/mihaitodor
हालांकि assignment-based interview में cheating बहुत फैली हुई बताई जाती है, इसलिए चिंता है कि इसे अपनाने वाले employers की संख्या तेज़ी से घट सकती है
devil’s advocate बनकर कहूँ तो, LeetCode औसत individual contributor hiring में दो में से एक या दोनों चीज़ें छाँटने के लिए इस्तेमाल होता है। क्या व्यक्ति मेहनती है, यानी बहुत सारे problems पढ़कर उनके solutions याद करके दोहरा सकता है। या क्या वह smart है, यानी LeetCode किए बिना भी fundamentals जानता है और पुराने ज्ञान को जोड़कर नए सवाल का जवाब दे सकता है
अगर कोई जानकारी न हो, तो मुझे लगता है कि LeetCode problem पास न कर पाने वाला व्यक्ति इन दोनों में से किसी भी category में न होने की संभावना अधिक रखता है। अगर role में coding चाहिए, तो LeetCode easy से medium स्तर का एक problem तो, interviewer की थोड़ी direction लेकर भी, solve कर पाना चाहिए। वास्तव में companies जितना senior या जितना specialized role होता है, LeetCode ability का weight उतना कम कर देती हैं। bug fixing, system design, behavioral interview, assignments, trivia-style questions, background-specific questions वगैरह भी बहुत होते हैं, और junior से ऊपर की hiring में LeetCode सब कुछ नहीं है। यह best engineers को जादुई तरीके से चुनने का tool नहीं, बल्कि hiring committee द्वारा इस्तेमाल किया जाने वाला बस एक और signal है
यह budget के भीतर अंत तक काम आगे बढ़ाने की engineering ability नहीं देखता। अच्छे से देखें तो यह peripheral चीज़ है, और बुरे से देखें तो 19 साल के करीब लोगों को prefer करने वाला age discrimination का proxy metric है। शायद इसलिए यह industry quality software देने में इतनी जूझती है। बेहतर तरीका है failed situation देना—जैसे broken build या crash करने वाला code—और उसे fix करने को कहना। अगर कोई system explore कर सके, defect diagnose कर सके, root cause ढूँढ सके, patch propose कर सके, और coding/comment style match कर सके, तो वही असल में चाहिए। branch और issue tracker हो सकते हैं, bug discussion पहले से चल रही हो सकती है, और comments में manually apply करने वाला patch file हो सकता है। patch में नया bug हो सकता है, या वह bait हो सकता है जो मिलता-जुलता लेकिन irrelevant issue छूता हो। यह किसी closed bug का regression हो सकता है लेकिन unit test न हो, और test हो भी तो candidate को ढूँढना पड़े या test खुद outdated और bugs से भरा हो। यही असली काम है। अंत में “unit test broken था” कहना और “मुझे समझ नहीं आया कि इसे सही से कैसे चलाना है, इसलिए छोड़ दिया” कहना attitude में बड़ा फर्क दिखाता है, और team player दूसरा वाला है
इसलिए उल्टा, आपको ऐसा candidate भी मिल सकता है जो अपने current role में शानदार performance नहीं दे रहा, लेकिन बची हुई energy LeetCode grind में डाल रहा है
किसी project पर कुछ हफ्ते काम करने से smart व्यक्ति को सच में जरूरी insights मिल सकती हैं। LeetCode जो अचानक puzzle देता है, वह पुराने magazines की crossword puzzles के ज्यादा करीब है
ऐसा कर पाने की एकमात्र वजह यह है कि आपने उसे पहले पढ़ा है
अगर 2022 होता तो मैं सहमत होता कि LeetCode best engineers चुनने का tool नहीं है, लेकिन 2024 में सही answer देने पर भी ज्यादा छँटनी इसलिए होती है कि आप पर्याप्त तेज़ नहीं थे या बिना hint solve नहीं कर पाए। मैं LeetCode genius नहीं हूँ और पढ़ने के लिए पहले ही बहुत कुछ है; interview में LeetCode का हिस्सा करीब 20% है, लेकिन मुझे नहीं लगता कि यह 2 साल पहले से इतना खराब हुआ है। बस companies की expectations आसमान छू रही हैं, और माहौल ऐसा है कि 15+ years experience वाले roles को 5-year salary में खरीदना चाहती हैं
LeetCode-style interviews में एक दिलचस्प बात कम ही बताई जाती है: यह एक तरह की intellectual hazing है
कई बार साबित हुआ है कि initiation ritual जितना कठोर होता है, group में शामिल लोगों की commitment उतनी ज्यादा बढ़ती है
जब कोई capitalist company programmers hire करती है, तो “सही answer में विश्वास रखने वाले smart और similar लोग” और “randomly mixed skilled people” में से क्या बेहतर होगा? अगर आपका जवाब दूसरा है, तो आप idealistic हैं, और ऐसी राय असल में मायने नहीं रखती। nature आपको ज्यादा smart और realistic व्यक्ति से replace कर देगा
हाल की कुछ interviews में हमने candidates को sample code दिखाकर review करने को कहा। sample में हर line में कम-से-कम एक bug या issue था
इसके बाद modelling task होता था, आम तौर पर whiteboard पर। juniors सच में junior role निभा सकते हैं या नहीं, यह देखने के लिए fizzbuzz जैसा एक simple exercise भी होता था, और इसे execution time complexity या memory layout जैसे topics पर बातचीत शुरू करने के आधार के रूप में इस्तेमाल करते थे। candidate के performance के हिसाब से यह बहुत interactive तरीके से चलता था; मकसद था किसी तरह screening पार कर आए imposters को छांटना और cultural fit का भी कुछ अंदाज़ा लगाना
timezone या phone number validation जैसी messy problem बनाते हैं, और Wikipedia document को spec मानते हैं। खत्म होने पर solution के बारे में पूछते हैं और code review करते हैं। सबसे अच्छे seniors बस library इस्तेमाल करते हैं। अच्छे candidates खुद बनाते हैं लेकिन trade-offs समझा सकते हैं। juniors सिर्फ tests pass कराते हैं और रुक जाते हैं
https://github.com/emilybache/GildedRose-Refactoring-Kata
candidates को उनकी पसंद की language में करने दिया, और यह बहुत effective filter था
मैंने ऐसे developer candidates का interview लिया है जो theory बहुत जानते हुए लगते थे, लेकिन जब code लिखने को कहा तो बुरी तरह fail हो गए। fizzbuzz भी implement नहीं कर पाए, और एक Senior Java developer lookup किए बिना HashMap import नहीं कर पाया
यह maths जैसा है। 562 * 1041 के लिए calculator इस्तेमाल करना ठीक है, लेकिन 3 * 7 जानने के लिए अगर कोई calculator निकालता है तो उसके expert होने पर शक होता है। कई companies LeetCode interviews को हद से ज्यादा कर देती हैं, लेकिन array manipulation, flow control, और basic data structures का इस्तेमाल दिखाने वाला live coding interview यह दिखाता है कि experience से आने वाली muscle memory है या नहीं। अगर pass होने के लिए graph traversal algorithms पढ़ने पड़ें, तो शायद वह बहुत ज्यादा LeetCode-स्टाइल है
लेकिन programs में ऐसे कई छोटे-छोटे elements चाहिए होते हैं, और उस worldview में सब कुछ याद रखना पड़ता है। 562 * 1041 में expectation यह है कि calculation का principle, यानी कैसे करना है, पता होना चाहिए। calculation गलत हो सकती है, लेकिन long multiplication का idea गलत नहीं होना चाहिए। उस context में 3 * 7 जैसी multiplication table की एक entry भूल जाना भी ठीक है। programmer calculations को organize करने वाला होता है, खुद calculation करने वाला नहीं; वह काम computer करता है। मैं इससे सहमत हूं कि graph traversal algorithms के लिए यह पता होना काफी है कि solution कहां मिलेगा, हर solution हाथ में होना जरूरी नहीं
किन हालात में इन लोगों को खुद import करना पड़ा? क्या IDE नहीं था
समझ नहीं आया कि यह interviewer stereotypes पर satire था या नहीं