अवास्तविक coding challenges बंद करने की अपील

 (blackentropy.bearblog.dev)
2 पॉइंट द्वारा GN⁺ 2024-11-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कुछ technical interviews में दिए जाने वाले अवास्तविक coding tasks असली काम से अलग दबाव वाली स्थिति बनाते हैं और developer की practical क्षमता को ठीक से नहीं मापते
  • अकेले, high-pressure tasks उस work environment को नहीं दर्शाते जहाँ सहयोग और support मिलता है; वे अक्सर documentation या team की मदद के बिना पुराने codebase को debug करने जैसे बन जाते हैं
  • कंपनियाँ जिसे “4 घंटे का task” कहती हैं, वह भी company research, role requirements की review और deliverable को polish करने तक जोड़ें तो 8–10 घंटे या उससे ज्यादा हो सकता है
  • role से असंबंधित tech stack वाले tasks को adaptability assessment के नाम पर सही ठहराया जाता है, लेकिन Ruby developer से PHP debugging करवाना वास्तविक fit से मेल नहीं खा सकता
  • hiring को मनमाने high-pressure tasks के बजाय relevant skills, problem solving, collaboration और growth potential पर ध्यान देना चाहिए; अत्यधिक tasks अच्छे candidates को थका सकते हैं और दूर कर सकते हैं

Interview tasks जो असली काम से मेल नहीं खाते

  • कुछ technical interviews developers से कुछ घंटों में legacy PHP debugging या mini app बनाने जैसे tasks मांगते हैं
  • ऐसे solo tasks वास्तविक काम करने के तरीके से अलग होते हैं
    • काम में आम तौर पर team के साथ collaboration होता है और जरूरी support मिल सकता है
    • documentation या team की मदद के बिना पुराने codebase को अकेले जल्दी debug करने की स्थिति सामान्य development environment से मेल नहीं खाती
  • कंपनियाँ इसे “problem-solving ability” का assessment मानती हैं, लेकिन अगर task role की वास्तविक जरूरतों से जुड़ा नहीं है, तो candidate की practical suitability देखना मुश्किल होता है

छिपी हुई time cost और candidate पर बोझ

  • coding task का recommended time candidate द्वारा वास्तव में लगाए जाने वाले समय को पर्याप्त रूप से नहीं दर्शाता
    • task से पहले company के बारे में research करनी होती है और role requirements देखनी होती हैं
    • submission को अच्छी हालत में बनाने के लिए project को polish करने का समय भी चाहिए
    • “4 घंटे” का task 8 घंटे, 10 घंटे या उससे भी ज्यादा हो सकता है
  • job और निजी जीवन साथ संभाल रहे developers को यह उस job के लिए unpaid work करने जैसा महसूस करा सकता है, जो उन्हें अभी मिली भी नहीं है

Adaptability assessment कहाँ गलत दिशा में चला जाता है

  • unrelated tech stack वाले tasks को कभी-कभी “adaptability” assessment के रूप में justify किया जाता है
    • Ruby developer से PHP debugging मांगना, adaptability के महत्व से अलग, candidate की value judge करने का अनुचित आधार हो सकता है
    • केवल अस्पष्ट और असंबंधित tasks को जल्दी निपटाने की क्षमता से यह तय करना मुश्किल है कि candidate वास्तविक role के लिए fit है या नहीं
  • कुछ tasks candidate suitability assess करने से ज्यादा कंपनी के “elite” standards दिखाने का तरीका लग सकते हैं
    • अगर हर hiring में “top 1%” जैसी barrier बनाई जाए, तो वास्तविक काम अच्छी तरह कर सकने वाले skilled candidates भी artificial और high-pressure स्थितियों के कारण प्रक्रिया छोड़ सकते हैं

Hiring tasks को क्या assess करना चाहिए

  • hiring process को role के लिए जरूरी specific skills के इर्द-गिर्द design किया जाना चाहिए
    • वास्तविक job requirements से असंबंधित coding bootcamp-style tasks से बचना चाहिए
    • problem solving, collaboration और relevant domain में growth potential पर focus करना चाहिए
    • adaptability को इस आधार पर नहीं, बल्कि लंबे समय में सीख सकने की क्षमता के रूप में assess करना चाहिए कि कोई arbitrary task कितनी जल्दी निपटाता है

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

1 टिप्पणियां

 
GN⁺ 2024-11-17
Hacker News की रायें

  • आख़िरी बार आपने बिना documentation और बिना team की मदद के किसी पुराने codebase को कब debug किया था? मेरे साथ तो हमेशा ऐसा ही हुआ है। वह C++ की 3–4 लाख lines का था, और legacy का मतलब था कि tests बिल्कुल नहीं थे, documentation भी लगभग नहीं थी, और एक छोटी कंपनी में अकेले developer के रूप में मुझे tens of thousands users को service चालू रखते हुए bugs ठीक करने और features जोड़ने थे।
    हाल का उदाहरण लें तो, एक core feature patch था जो एक साल से ज़्यादा पुराना पड़ा था; original author अब नहीं था, और हमें या तो code शुरू से फिर से लिखना था या patch को master के हिसाब से फिर से जिंदा करना था।
    किसी project में कूदकर लोगों को लक्ष्य तक ले जाने की क्षमता senior developer के लिए निश्चित रूप से ज़रूरी skill है, और मैं इस निष्कर्ष से सहमत हूँ कि problem-solving ability को test करना चाहिए। बस technical interview की सामग्री role के हिसाब से अलग होनी चाहिए; junior web developer से whiteboard पर graph algorithm पूछने की ज़रूरत नहीं है, लेकिन social network product के senior developer या architect को इसे गहराई से समझना चाहिए।

    • “मेरे साथ तो हमेशा ऐसा ही हुआ है” से सहमत हूँ। आज भी मैंने system के core हिस्से को debug किया, जो बाकी system से अलग Python में है, 2020 के बाद से लगभग update नहीं हुआ, comments और documentation नहीं हैं, और deployment system इतना टूटा हुआ है कि उसके बारे में सोचते ही रोने का मन करता है।
      पिछले हफ्ते मैंने इसी तरह बिना comments और documentation वाले 2020 के Go code को debug किया; वह भी system का core हिस्सा था और ऐसा लगता था जैसे पागल लोगों ने लिखा हो। बहुत दर्दनाक है।
    • 6 महीने पहले किसी बेवकूफ़—यानी मैंने—लिखे code को भी debug करना पड़ता है, और मुझे ज़रा भी याद नहीं रहता कि इसे कैसे debug करना है, इसलिए वह practically किसी और के लिखे code जैसा ही है।
    • बिल्कुल सच। जिन engineers को लगता है कि यह समस्या नहीं है, वे dependencies और stack की lower layers को बस ऐसी जमी हुई black box चीज़ों की तरह देखते हैं जिन्हें छुआ नहीं जा सकता। ज़रूरत पड़े तो उन्हें अंदर जाकर ठीक करने या features तक जोड़ने लायक चीज़ मानना चाहिए।
      समस्या को सही layer पर हल करने के लिए नीचे तक खोदने की इच्छा, मेरे हिसाब से, senior engineers को अलग करने वाली बड़ी soft skills में से एक है। lower layer के bug या missing feature को अपने code में बाद की भरपाई से workaround करने के बजाय, अगर सही layer पर ठीक किया जाए तो पूरा system stack के ऊपर-नीचे होने वाले बदलावों और भविष्य के अनपेक्षित use cases के लिए अधिक मजबूत बनता है।
      इसके उलट, अगर यह approach नहीं अपनाई जाती, तो senior engineers के निकल जाने या juniors से replace हो जाने के बाद codebase सड़ना शुरू कर देता है। उदाहरण के लिए, हर input parsing edge case के लिए डरावने और opaque parser के आगे एक naïve validation regex और चिपकाते जाना, और parser grammar को ही ठीक न करना—तो codebase एक कीचड़ के ढेर में बदल रहा होता है।
      बेशक सही layer पर fix करने का मतलब अक्सर यह होता है कि कंपनी अपने stack में इस्तेमाल होने वाले ecosystem software की कोई छोटी private long-term hotfix branch maintain करे। upstream आमतौर पर उस issue को issue नहीं मानता, इसलिए patch accept नहीं करता और आपको उसे अपने पास ही रखना पड़ता है।
      मज़ाक में कहें तो, अगर GitHub profile से verify करके यह गिना जाए कि किसी engineer ने ऐसी long-term private hotfix branches कितनी बार बनाई या maintain कीं, तो seniority को coding test की तुलना में कहीं आसान तरीके से मापा जा सकता है।
    • अनजान codebase में, और कभी-कभी dependent libraries में, कूदकर जल्दी जांच करना, debug करना और root cause ढूँढना—मेरे अनुभव में बहुत valuable है।
      इसे असल दुनिया में बेकार बताकर behave करने से कोई मदद नहीं मिलती। reality messy होती है, documentation अक्सर नहीं होती या भरोसेमंद नहीं होती, और original code लिखने वाला व्यक्ति या team पहले ही जा चुकी हो सकती है।
    • अगर छोटी कंपनी में एक अकेला developer tens of thousands users को service दे रहा है, तो लगता है कि और developers hire करने लायक तो होना चाहिए। अफ़सोस है; tests या developer experience सुधारने पर budget खर्च करके कम stress में काम कर पाना चाहिए था।

  • एक छोटी-सी घटना है। एक दोस्त के spouse ने इस साल की शुरुआत में नौकरी छोड़ने के बाद हर Big Tech कंपनी के लिए इंटरव्यू तैयारी में 4–6 हफ्ते लगाए। Meta के लिए 4–6 हफ्ते, Stripe के लिए 4–6 हफ्ते—इस तरह तैयारी की, बीच-बीच में random interviews देकर practice और muscle memory बनाई, हर कंपनी में आ सकने वाले सवालों पर research की, और रोज़ कई घंटे LeetCode हल किया।
    नतीजा यह रहा कि सब अच्छा चला और उन्होंने MAANG का L6/staff offer accept कर लिया। लेकिन इस हफ्ते बात हुई तो उन्होंने कहा कि नया role शुरू भी नहीं किया है और practice की हुई ज्यादातर details वे पहले ही भूल चुके हैं। उनका कहना था कि system design का अनुभव न होने से system design की तैयारी सबसे कठिन थी, लेकिन अब वे MAANG में staff eng बन गए हैं। मैंने उनके साथ एक छोटा project किया है; असलियत में वे अच्छे हैं, मगर असाधारण रूप से बेहतरीन engineer नहीं थे।
    यह सचमुच अजीब है, और hiring के boom और bust cycles को काफी हद तक समझाता लगता है। system design interview preparation videos देखें तो वे लगभग script जैसे लगते हैं। interview में जाकर बस script follow करनी होती है; आपने सच में वैसा या उससे ज्यादा complex system design किया है या नहीं, यह उतना मायने रखता नहीं दिखता। लगता है system design interview का उद्देश्य आखिरकार यही है कि “क्या आपको script पता है?”
    इन दो videos को 2x speed पर लगातार देखें तो हैरानी होगी कि यह कितना scripted performance जैसा है: https://www.youtube.com/watch?v=4_qu1F9BXow, https://www.youtube.com/watch?v=_K-eupuDVEc

    • पहले जब मैं hiring संभालता था, तो ऐसे सवाल बनाता था जिनमें candidate को follow करते हुए guide किया जा सके, और देखता था कि वे मौके पर क्या discover करते हैं और अनजाने में जो जानते हैं उसे कैसे सामने लाते हैं। मैंने जो whiteboard problems सीखे थे, वे ऐसे ही थे, आज वाले LeetCode-style नहीं।
      मेरे माता-पिता दोनों 1980–90 के दशक में Santa Cruz tech industry में थे, और उस समय talent pool बड़ा नहीं था, इसलिए यह उन लोगों को खोजने का inclusive tool था जिन्हें developer के रूप में grow किया जा सके। आज industry ने उस practice को अपना लिया है, लेकिन उसे ठीक उल्टा, exclusionary बना दिया है।
      जिन लोगों को मैंने hire किया उनमें से एक physicist थे; उन्हें technical jargon बिल्कुल नहीं आता था और पहली बार whiteboard problem देखकर वे घबरा गए। जब उन्हें उनकी comfortable जगह तक ले जाया गया, तो वे उन tools के बारे में बताने लगे जो उन्होंने physics work में मदद के लिए बनाए थे। वे हैरान रह गए जब मैंने कहा कि बिना development knowledge के बनाए गए वे tools software ही थे। वे न सिर्फ सचमुच software थे, बल्कि बेहद impressive भी थे, और whiteboard problem potential सामने लाने का tool था।
      मैं समझता हूं कि बड़ी कंपनियां लोगों के बजाय ऐसे widgets चाहती हैं जिन्हें सीधे फिट किया जा सके, लेकिन मज़ेदार बात यह है कि वे ऐसी चीज़ इस्तेमाल कर रही हैं जो मूल रूप से ठीक उल्टे उद्देश्य के लिए बनाई गई थी। कभी-कभी लगता है कि अच्छा ही है कि मैं इतना उम्रदराज़ हो गया हूं कि ऐसी code challenges कराने वाली cool companies में जाने की उम्मीद ही नहीं बची।
    • ऐसी companies के recruiters से बात करें तो पता चलता है कि यह तरीका जानबूझकर तुलनात्मक रूप से meritocratic बनाया गया है।
      तर्क यह है कि आपने कौन-सी university से पढ़ाई की, कौन-सी classes लीं, आपके पास क्या फायदे या नुकसान थे—इन सबके बावजूद अगर role के लिए जरूरी qualities हैं, तो यह ऐसी चीज़ है जो कुछ महीनों में सीखी जा सकती है। technology काफी standardized है, इसलिए process भी काफी objective हो जाता है।
      यह expectation नहीं होती कि actual काम में आप वही specific skills इस्तेमाल करेंगे। इसके बजाय आप दिखाते हैं कि आप उस तरह की skills सीख सकते हैं और high-stress interview situation में high level पर perform कर सकते हैं। तर्क यह है कि यह बाद में assigned project के लिए जरूरी skills सीखने और बड़े deadline pressure में perform करने की अच्छी signal है।
      मैं इस system का समर्थन नहीं कर रहा, लेकिन इसके पीछे एक स्पष्ट logic जरूर है।
    • उत्सुकता है कि उस training process के बाद आपने उनके साथ काम किया है या नहीं। data structures and algorithms coding problems की training और system design की पढ़ाई किसी engineer को बदल सकती है। हो सकता है वे आपके अनुमान से कहीं बेहतर हो गए हों।
      वे कहते हैं कि वे भूल गए, लेकिन अगर उन्हें वह position मिली है तो शायद वे medium-difficulty LeetCode problems हल कर सकते थे। यह मानना कठिन है कि वे सब कुछ भूल गए; संभावना है कि वे अभी भी आसान problems हल कर सकें जिन्हें ज्यादातर लोग मौके पर नहीं कर पाते। search, sorting, arrays और hash lookups, trees और graph traversal जैसे essential backend tasks की complexity भी उन्हें अभी याद होगी।
    • यह बात कि आपने ज्यादा complex systems design किए हैं, सिर्फ आपको पता है। interviewer के पास यह जानने का कोई तरीका नहीं कि यह सच है या आप “मैंने complex systems design किए हैं” वाली acting script follow करने वाले actor हैं।
      और acting talent शायद programming talent की तुलना में पूरी population में ज्यादा common हो।
    • तो यह ऐसा लगता है जैसे system ने बिल्कुल वही किया जिसके लिए उसे design किया गया था। एक smart दिखने वाले व्यक्ति को अच्छी job मिल गई; इस कहानी में समस्या ठीक-ठीक क्या है, समझ नहीं आ रहा।

  • हाल ही में एक छोटे startup में अपेक्षाकृत senior engineer भूमिका के लिए interview process चलाया। मेरा मानना है कि अलग-अलग लोगों के लिए अलग-अलग interview तरीके बेहतर फिट होते हैं, इसलिए सभी को विकल्प दिए

    1. लगभग 4 घंटे का लक्ष्य, लेकिन असल में कोई time limit नहीं वाला take-home test। यह algorithm problem नहीं था, बल्कि पिछले महीने मैंने सच में जो काम किया था, उसका छोटा किया हुआ project था
    2. 2 घंटे की onsite pairing exercise। 1 का ही एक variation था, लेकिन ज़्यादा “देखते हैं 2 घंटे में कहाँ तक पहुँचते हैं” जैसा
    3. मौजूदा काम का code sample submit करना
      take-home test को लेकर बहुत गुस्सा देखा था, इसलिए लगा था कि तीनों विकल्पों में बराबर बँटवारा होगा, लेकिन हैरानी की बात है कि candidates में से लगभग 90–95% ने take-home test चुना। अगर मैं applicant होता तो यही तरीका पसंद करता, इसलिए यह दिलचस्प data था, और यह देखकर बहुत हैरानी हुई कि ज़्यादातर लोग वही पसंद करते हैं
    • मुझे take-home थोड़ा ज़्यादा पसंद है, मुख्यतः इसलिए कि यह कम chaotic होता है। हालांकि समस्या यह है कि सामने वाला उस पर समय लगाएगा, इसकी कोई guarantee नहीं होती
      आमने-सामने interview में company को भी काफी cost देनी पड़ती है, इसलिए मेरे समय के waste होने की संभावना कम मानी जा सकती है। job search process की asymmetry पहले से ही बढ़ रही है, और take-home इसे और तेज़ करने वाली प्रवृत्ति है
      पहले एक assignment पूरा न करने पर मेरा एक non-technical दोस्त अब भी मुझसे नाराज़ है; core requirement साफ तौर पर मामूली थी, लेकिन instructions इतनी धुंधली थीं कि submit करने लायक अच्छा है या नहीं, यह तय करने में कई घंटे जल सकते थे। ऊपर से वे एक narrow tech set की उम्मीद कर रहे थे, जो मुश्किल तो नहीं था, लेकिन “technical talent नहीं मिल रहा” कहने वाली company को शायद मदद मिल जाए, इस मौके के लिए मैं उसे सीखना नहीं चाहता था
    • जिज्ञासा है कि क्या आपने पूछा कि उन्होंने take-home क्यों चुना
      मुझे लगता है मैं 3 की तुलना में 1 और 2 को पसंद करूँगा। क्योंकि मैं जो problem solve कर रहा हूँ उसे interviewer समझे, तभी वह मेरे approach को बेहतर evaluate कर सकता है
      घर से करके बाद में submit करने पर interviewer मेरे solution को अपने या दूसरे solutions से compare करते हुए, उसी assignment के आधार पर मेरी coding style को बेहतर समझ सकता है
      pairing में साथ काम करने पर वह मेरी thought process देख सकता है, और मैं यह भी बेहतर explain कर सकता हूँ कि मैंने कोई खास idiom क्यों चुना
      पुराने code में context लगभग नहीं होता। वह बस किसी दूसरे project के लिए लिखा code होता है। शुरुआती stage में resume के साथ भेजकर यह verify करने के लिए उपयोगी है कि मैं सच में code लिख सकता हूँ, लेकिन बाद की stage में तभी impressive होगा जब कोई working app हो और आप किसी specific feature code के बारे में guide कर सकें। लेकिन कितने लोगों के पास यूँ ही working software पड़ा होता है? आम तौर पर कुछ hacks से जैसे-तैसे चलने वाला code ही होता है
      मैं 2 की तुलना में 1 को पसंद करता हूँ। क्योंकि गलती होने की संभावना कम हो जाती है। onsite 2 घंटे में pressure और Murphy’s law के कारण बिगाड़ने का risk लेने के बजाय, घर पर 2 घंटे और लगाना और जो नहीं पता उसे freely research करने का समय मिलना, मेरे हिसाब से साफ तौर पर बेहतर है
    • मैं औसत skill वाला introverted engineer हूँ, लेकिन 10+ साल से problems solve करते आने के नाते मैं 2 चुनूँगा। आमने-सामने मिलकर मैं अपने विचार बहुत आसानी से explain कर सकता हूँ, काम भी काफी कम करना होगा, और interviewer को impress करने के तरीके भी ज़्यादा होंगे
      मैं take-home test evaluate करने वाली side पर भी रहा हूँ, और जानता हूँ कि उससे किसी पर गहरा impression डालना कितना मुश्किल है
    • मुझे लगा था “3. code sample submit करना” भारी जीत हासिल करेगा। वह तो पहले से done काम है, इसलिए obvious लगता है; जिज्ञासा है कि क्या वास्तव में किसी ने उसे चुना
    • विकल्प देने का idea दिलचस्प है, लेकिन hiring manager के नज़रिए से problem और कठिन हो जाती है। अलग-अलग विकल्पों के results को fairly compare कैसे किया जा सकता है? एक ही interview देने पर भी candidates को fair compare करना काफी कठिन होता है
      पिछली बार जब मैंने actual coding interview दिया था, तो कोई भी programming language चुन सकता था, और solve करने के लिए 3 में से problem भी चुन सकता था। मुझे यह काफी पसंद आया और offer भी मिला। time-limited interview में C++ की जगह Python चुन पाने का मौका लगभग cheat जैसा लगा

  • online coding interviews को लेकर जितनी शिकायतें बढ़ती हैं, उतना मेरा विश्वास बढ़ता है कि software development roles के candidates को filter करने के लिए coding interview बिल्कुल सबसे अच्छा तरीका है। industry में बातें बनाने वाले, impostors, meeting schedule करने वाले लोग बहुत हैं, और sleeves roll up करके code में कूदकर सच में काम finish करने वाले लोग कम हैं
    higher levels पर यह problem और खराब हो जाती है। जितनी मर्जी शिकायत कर सकते हैं, लेकिन आरामदायक FAANG $500k/year job अपने-आप मिलने वाली चीज नहीं है। अगर basic programming दोहराने और कुछ for loops लिखने का मन नहीं है, तो company बस किसी ऐसे व्यक्ति के पास चली जाएगी जो यह करेगा

    • मैं ऐसे interviews अच्छे से pass करता हूँ और FAANG में हूँ, और इस महीने दूसरी FAANG में जाने वाला हूँ। फिर भी ये interviews बेकार हैं, और problem-solving ability और learning ability के बारे में false signal देते हैं
      अगर interview सच में sleeves roll up करके code में कूदने की ability test करता है, तो समझ नहीं आता कि new hire के रूप में मुझे पुराने लोगों को software engineering और debugging practices इतनी बार क्यों समझानी पड़ती हैं
      अगर आपने बड़ी company में सच में काम किया है, तो आपको पता होगा कि असली काम का 90% 5% से भी कम लोग करते हैं। अगर interview ठीक से काम कर रहा होता, तो यह ratio काफी बेहतर होना चाहिए था
    • coding challenges मुझे पसंद नहीं हैं, लेकिन इसलिए नहीं कि वे मुश्किल होते हैं। वे उन लोगों को advantage देते हैं जिनके पास coding challenge करने का समय है। फिर भी industry में fake लोगों की संख्या बहुत है, यह बात सही है, और उन्हें filter करने के लिए coding tests शायद फिलहाल सबसे बेहतर तरीका हो सकते हैं
    • पहले शायद ऐसा रहा हो, लेकिन अब इस system को crack कराने में मदद करने वाली पूरी industry बन चुकी है
      Cracking the Coding Interview, Elements of Programming Interviews in Java/Python/दूसरी languages, LeetCode और paid premium subscription sites, mock interview bootcamps तक हैं। अब यह skill से ज़्यादा system को game करने का मामला बन गया है
    • आप कह रहे हैं कि “coding interview software development roles के candidates को filter करने का बिल्कुल सबसे अच्छा तरीका है”, और साथ ही कह रहे हैं कि “industry में काम न कर पाने वाले लोग बहुत हैं”
      coding interview standard hiring method है—इस premise और उसके इतने खराब result की reality के बीच कोई cognitive dissonance न होना हैरान करने वाला है
    • मान लें कि LeetCode को generally अच्छा माना भी जाए, तो उसके increasingly dominant variant, यानी ML/AI engineer, के लिए क्या?
      अगर problem LLM tokenization जैसी हो, तो “ML-LeetCode” problem में LLM use को कैसे ban कर सकते हैं?
      candidate Cursor और Claude को skillfully इस्तेमाल करके coding करने वाला expert है, इसलिए 3 prompts और आसानी से मिले 2 errors fix करके 10 मिनट में solve कर देता है, और उसके पास NeurIPS-level papers और open-source code भी हैं—तो मैंने fake fraud को filter किया, या top-tier candidate को filter कर दिया?
      LLM से जुड़े काम करने वाले व्यक्ति के लिए LeetCode-style problems मुझे meaningful नहीं लगतीं। पसंद हो या न हो, आगे आरामदायक FAANG+ $500k/year jobs का बढ़ता हिस्सा LLM से जुड़ा होगा

  • Ruby डेवलपर से flexibility test के तौर पर PHP debug करवाना ठीक-ठाक test जैसा लगता है। एक अच्छे, खासकर senior developer को ऐसा कर पाने में सक्षम होना चाहिए। खुद को सिर्फ “Ruby developer” की कैटेगरी में रखना career trap है

    • और यह काफी पैसे दिलाने वाला trap भी है
    • कौन और कैसे इसे कराता है, इस पर निर्भर करता है कि यह मजेदार exercise बन सकती है या भयानक। लेकिन अगर role Ruby का बताया गया हो और candidate के पास पर्याप्त options हों, तो वह सोच सकता है कि role description झूठा था और चला जा सकता है
    • सहमत। असल काम में ऐसा काफी बार हुआ है, इसलिए यह पूरी तरह गढ़ा हुआ example नहीं है। आम तौर पर पूरी company में इसे कर सकने और करना चाहने वाले सिर्फ दो-तीन लोग होते हैं
      पुराने vendor-specific DSL को debug करना पड़ सकता है, या ऐसा code जहां framework और standards इतने पुराने हो चुके हों कि वह लगभग अलग भाषा बन गया हो
      backported feature support जोड़ना या पुराने clients और legacy stack के security holes patch करना भी होता है। बड़ी company में कभी-कभी बहुत छोटे partner का escrow code भी हमारी जिम्मेदारी बन गया था
      ठीक से debug कर पाने के लिए environment set करना अक्सर असल fix से बड़ा काम होता है। फिर भी senior या उससे ऊपर के लिए यह अच्छा test है
    • JavaScript की एक भी line लिखे बिना मैंने JavaScript test pass करके job पाई थी। task लगभग conversational था
      interviewer ने कहा, “इस array को reverse कीजिए,” तो मैंने जवाब दिया, “Python में होता तो array.reverse() या reversed(array) इस्तेमाल करता, और JS में भी इनमें से कोई एक होगा, शायद .reverse method होगा।” interviewer ने कहा, “अच्छा guess है”
      सच में मजा आया, कुछ चीजें सीखीं, और लगा कि सामने वाले ने देख लिया कि मैं नए problem पर कैसे reason करता हूं
    • career को mental health से ऊपर रखना भी life trap है

  • बिना documentation और team help वाले पुराने codebase को मैंने कई बार debug किया है। ऐसे systems सच में होते हैं जिनके बनाने वालों में से कोई नहीं बचा होता और documentation होता नहीं या मिल नहीं पाता। इसलिए यह example बहुत अच्छा नहीं है। program debug करना, request flow follow करना और देखना कि क्या हो रहा है, एक अच्छी skill है
    लेकिन इस example की सच में खराब बात यह है कि यह developers को किसी specific technology में pigeonhole कर देता है। अगर legacy PHP application है, तो Java, Python, Ruby, Go developers में से वे लोग filter out हो जाएंगे जिनमें ऐसी debugging ability तो है, लेकिन PHP न जानने की वजह से वे धीमे होंगे। जबकि कुछ महीने PHP पर हाथ लगाने के बाद वे और मजबूत developer भी हो सकते हैं
    इस बात से सहमत हूं कि “4 घंटे का assignment” अच्छा output बनाने के लिए आसानी से 8 घंटे, 10 घंटे या उससे ज्यादा तक खिंच जाता है। बताई गई समय-सीमा को आसानी से game किया जा सकता है, जिससे जिसके पास ज्यादा समय है वह बेहतर candidate जैसा दिख सकता है

    • Stripe में interview देते समय उनके पास कई languages में “इसे debug करके दिखाइए” वाली problems तैयार थीं। शायद Ruby, Java, Python, JavaScript, Go और एक-दो और थीं। यह काफी अच्छा था, लेकिन काफी labor-intensive भी लगा

  • बिना documentation और team help वाले पुराने codebase को आखिरी बार कब debug किया? इस हफ्ते हर दिन
    documentation की बात करें तो code आखिरी बार June में update हुआ था और documentation आखिरी बार January 2022 में
    team की बात करें तो दो साल पहले layoff में नहीं निकले आधे लोग भी बेहतर जगहों पर चले गए। हां, इस project को own करने वाली team है, लेकिन उनके पास तीन और projects भी हैं, और पिछले एक साल में उन्होंने इसमें मुश्किल से दर्जन भर lines contribute की हैं, जिनमें से 11 lines dependency updates थीं

    • काम में ऐसा करना ठीक है, लेकिन interview में करना मुझे problem लगता है। अनजान environment और अनजान लोगों के सामने हर कोई comfortable नहीं हो सकता। कृपया take-home test दें, और जब मैं whiteboard के सामने खड़ा हूं तब आपस में बातें न करें

  • “Ruby developer से PHP debug करवाने जैसा है”, “job में specific technology चाहिए तो उसी technology को test करो” — यह सब coding challenge में fail हुए व्यक्ति जैसा लगता है
    गंभीरता से कहूं तो companies hiring practices सिर्फ मजे के लिए शायद ही अपनाती हैं। आम तौर पर यह उस collective intelligence के हिसाब से निकला best तरीका होता है। वे कौन-सी problem solve करने की कोशिश कर रहे हैं, यह समझने की कोशिश किए बिना और कोई alternative दिए बिना उसे हटाने को कहना productive नहीं है
    मुझे लगता है software development में हम दूसरी professions की practices उधार लेने के बजाय बहुत बार wheel reinvent करते हैं। देखें कि civil engineers software developers की आधी salary पाने के लिए किस hiring process से गुजरते हैं, और उसे अपनी practices में integrate करें। तब हम सब happy soldiers होंगे

    • यह बात कि companies hiring practices मजे के लिए नहीं बनातीं और वे collective intelligence का best outcome होती हैं, कम संभावना वाली लगती है। आम तौर पर सबसे senior व्यक्ति वही उठा लाता है जो उसने पहले कहीं पढ़ा या experience किया होता है
      उन्होंने सच में क्या हासिल करना है, इस पर reflect किया हो, इसकी संभावना बहुत कम है। वे बस इसलिए follow करते हैं क्योंकि बाकी लोग कर रहे हैं, और मान लेते हैं कि कहीं किसी ने इसे किसी intention के साथ बनाया होगा
      tech hiring रास्ता इतना भटक गई है कि ज्यादा से ज्यादा यह किसी local maximum पर आकर टिक गई लगती है
    • फिर भी शायद इससे बेहतर software बनाया जा सके

  • जिस company में coding test बिल्कुल नहीं था, वहां मेरा बहुत खराब experience रहा। सिर्फ 2–3 interviews हुए थे
    problem तब दिखी जब data engineering team में साथ काम शुरू किया। stack का बड़ा हिस्सा Hadoop, Kubernetes, Ruby, Python और कई technologies पर आधारित था, और cloud computing की basic understanding चाहिए थी
    लेकिन लोगों का work experience और background इतना अलग-अलग था कि जिस काम के लिए मुझे hire किया गया था उसे करने के बजाय मैं अक्सर दूसरों की कमी पूरी कर रहा था। कुछ colleagues Docker का इस्तेमाल करके Python CLI package करना या Hadoop jobs check करना जैसे basic tasks भी नहीं कर पाते थे, इसलिए मुझे वह कमी पूरी करने वाला काफी glue work करना पड़ा
    आखिरकार मैं चला गया। इसलिए नहीं कि मैं खुद को खास समझता था, बल्कि इसलिए कि मैं अपने समय का 80% उन्हीं level या higher level पर hire किए गए लोगों को support करने में खर्च करते-करते थक गया था। यह मानता हूं कि उस company की hiring practices बहुत खराब थीं, लेकिन किसी न किसी रूप में basic technical test जरूरी है

    • “basic tasks भी नहीं कर पाते थे” से आपका मतलब है कि वे assigned काम बिल्कुल नहीं कर सकते थे, या यह कि simple tasks में अटकते तो थे लेकिन overall independent और capable थे?
      एक और अहम सवाल यह है कि क्या आपको उसी व्यक्ति को वही बात बार-बार समझानी पड़ती थी। कुछ न जानना acceptable है, लेकिन सीखने की कोशिश न करना मुश्किल से स्वीकार किया जा सकता है

  • असाइनमेंट-टाइप टेस्ट का दिलचस्प हिस्सा यह है कि “सिर्फ X घंटे लगाइए” कहने पर भी इसमें ऐसा moral hazard होता है जो लोगों को उससे ज़्यादा समय लगाने के लिए उकसाता है। कंपनी पूछे तो वास्तव में लगे समय के बारे में झूठ बोलने की प्रेरणा भी पैदा होती है
    मैंने कई बार सुझाए गए समय के भीतर रहने पर ज़ोर देते हुए, समस्या को ठीक-ठाक हल करके असाइनमेंट जमा किया है, लेकिन बाद के interview में “आपने X implement क्यों नहीं किया?” कहकर डांट पड़ी है
    इसी संदर्भ में, बहुत ज़्यादा open-ended असाइनमेंट-टाइप टेस्ट खराब असाइनमेंट होते हैं। क्योंकि वे उन लोगों को फायदा देते हैं जिनके पास ज़्यादा खाली समय है और जो चीज़ों को ज़्यादा बारीकी से कर सकते हैं। अंतिम output के तौर पर PowerPoint presentation मांगने वाले data science असाइनमेंट-टाइप टेस्ट को मेरा सलाम

    • बिल्कुल यही बात है। और फिर कंपनी में बैठा कोई व्यक्ति, जिसने मुझसे कभी मुलाकात या बात भी नहीं की, शिकायत करता है कि comments बहुत ज़्यादा हैं, या मैंने उनका पसंदीदा code formatter इस्तेमाल नहीं किया, या optional type checking नहीं की। अगर उन्हें proper project setup guide चाहिए, तो उसकी कीमत चुकानी होगी