Kagi Search के take-home assignment इंटरव्यू में असफल होने का अनुभव

 (bloggeroo.dev)
4 पॉइंट द्वारा GN⁺ 2025-05-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सॉफ्टवेयर डेवलपर इंटरव्यू में दिए जाने वाले "take-home assignment" की अक्षमता और उम्मीदवारों के समय की बर्बादी की समस्या पर ज़ोर दिया गया है
  • Kagi Search की आवेदन प्रक्रिया में ज़रूरत से ज़्यादा व्यापक और अस्पष्ट assignment requirements का अनुभव हुआ
  • प्रस्तावित ठोस execution plan पर मैनेजर की तरफ़ से स्पष्ट feedback की कमी और अप्रभावी communication का अनुभव हुआ
  • काफी मेहनत से विकसित किए गए प्रोजेक्ट को जमा करने के बाद, बिना स्पष्ट कारण अस्वीकृति और मानदंड बदलने जैसी अनुचित बातें महसूस हुईं
  • बेहतर hiring process के विकल्पों (जैसे real-time code review) और assignment-आधारित इंटरव्यू की अत्यधिक मांगों पर समस्या-बोध साझा किया गया है

प्रस्तावना

  • Take-home assignment सॉफ्टवेयर डेवलपर इंटरव्यू में इस्तेमाल होने वाला एक मूल्यांकन तरीका है, जिसमें उम्मीदवार को एक समस्या दी जाती है और उसे कोड में लागू करके जमा करना होता है
  • यह पोस्ट उस Kagi Search में आवेदन करते समय मिले वास्तविक assignment और अनुभव के आधार पर, जिसे लेखक एक प्रतिष्ठित कंपनी मानता था, इस तरीके की अतार्किकता और उम्मीदवारों के समय की बर्बादी की समस्या की ओर ध्यान दिलाती है

Kagi Search में नौकरी के लिए आवेदन

  • Kagi Search के backend developer पद के लिए resume जमा किया गया
  • इस भूमिका की आवश्यकताएँ इस प्रकार थीं
    • backend systems बनाने का अनुभव
    • Go भाषा के उपयोग की क्षमता
    • बड़े पैमाने के backend systems को scale और maintain करने का अनुभव
    • SRE जैसे team members के साथ collaboration की क्षमता
    • Docker जैसी container technologies की समझ

इंटरव्यू assignment की जानकारी और requirements

  • दस्तावेज़ी चरण पार करने के बाद take-home assignment की सूचना वाला ईमेल मिला
  • assignment का विषय: "न्यूनतम terminal-inspired email client का implementation"
    • terminal या webapp में से किसी एक रूप का चयन
    • email देखने/भेजने की बुनियादी functionality
    • fake या real email backend (IMAP/POP आदि) में स्वतंत्र चयन
    • केवल plaintext message handling आवश्यक, rich text की ज़रूरत नहीं
    • project submission: GitHub repository, deployed build, installation guide document सहित
  • स्पष्ट guidance की कमी थी और project का आकार काफ़ी बड़ा था
  • फिर भी उसकी प्रतिष्ठा के कारण assignment करने का निर्णय लिया गया

मैनेजर के साथ communication

  • assignment की स्पष्ट scope और अतिरिक्त features के बारे में पूछने पर केवल इतना अस्पष्ट जवाब मिला कि “क्या जोड़ना है यह उम्मीदवार पर निर्भर है”
  • assignment में समय और मेहनत लगाने से पहले, ठोस execution plan (Proposal) साझा किया गया और उस पर जवाब मांगा गया, लेकिन बिना किसी खास feedback के आगे बढ़ना पड़ा

assignment का प्रस्ताव और योजना

  • execution plan:
    • Go आधारित webapp
    • AWS ECS Fargate के माध्यम से deployment और SSL लागू करना
    • email sender service (Postmark) integration
    • login/authentication functionality जोड़ना
    • email भेजना/पाना और UI में दिखाना
  • तकनीक चयन का आधार:
    • backend role से संबंधित विभिन्न technologies का उपयोग
    • Infra-as-Code tools का उपयोग कर व्यावहारिक system निर्माण
    • साधारण API integration से आगे बढ़कर वास्तविक service के करीब functionality लागू करना
  • मुख्य implementation elements:
    • Pocketbase(backend/DB), TEMPL(template), Pulumi(IaC), Postmark(email service)
    • paging, login आदि का implementation
    • Stretch Goal: data backup और recovery जैसी reliability
  • निष्कर्ष: पहले से पर्याप्त explanation और reasoning दी गई थी, और उस पर स्पष्ट review तथा response की अपेक्षा थी

मैनेजर का जवाब और communication की समस्या

  • ठोस review के बिना केवल “रोचक प्रस्ताव” जैसा छोटा जवाब मिला
  • प्रस्ताव की उपयुक्तता या सुधार की ज़रूरत पर कोई feedback नहीं मिला
  • उम्मीदवार के नज़रिए से यह समय और मेहनत के प्रति सम्मान की कमी जैसा लगा

project assignment का निष्पादन

  • दिए गए requirements और प्रस्तावित बिंदुओं को पूरी तरह implement किया और एक सप्ताह full-time लगाया
  • project demo video, GitHub repository और विस्तृत documentation तक जमा की गई

अस्वीकृति की सूचना और उस पर feedback

  • automated rejection email मिलने के बाद, feedback मांगने पर मिला जवाब:
    • “इससे अधिक मज़बूत उम्मीदवार submissions थीं”, “hiring competition काफ़ी तीव्र है”
  • समस्याएँ
    1. अगर सरल solution को प्राथमिकता थी, तो यह शुरुआत में ही बताया जा सकता था
    2. अगर प्रस्ताव पर्याप्त नहीं था, तो उसी समय feedback दिया जा सकता था
    3. अस्वीकृति के बाद भी job posting अभी भी जारी थी, इसलिए इसे केवल competition नहीं बल्कि अत्यधिक समय खर्च करवाने वाली मांग माना गया
    4. project submission के बाद requirements और सख़्त हो गईं, यानी जमा किया गया solution ही मानदंड ऊँचा करने जैसा बन गया

निष्कर्ष और समस्या-बोध

  • इस तरह की प्रक्रिया कई job seekers के लिए अनुचित है, और इससे वास्तविक आजीविका तक पर असर पड़ सकता है
  • अत्यधिक unpaid assignment demands को ठुकराने या उन पर सवाल उठाने की आवश्यकता पर ज़ोर दिया गया
  • project-आधारित assignments की जगह real-time code review जैसे बेहतर hiring process संभव हैं
    • वास्तविक development problem-solving क्षमता को asynchronous/synchronous code review के माध्यम से देखा जा सकता है
    • Leetcode शैली की समस्याओं और वास्तविक काम की मांगों के बीच की दूरी की ओर इशारा किया गया
  • job seekers की थकावट और अनुचित मूल्यांकन वाली संस्कृति में सुधार की अपील की गई

बेहतर hiring procedure के लिए सुझाव

  • real-time code review जैसे तरीकों सहित डेवलपर की क्षमता का अधिक अर्थपूर्ण मूल्यांकन करने वाले विकल्प सुझाए गए
  • timer-आधारित algorithm puzzle solving पर केंद्रित तरीकों की बजाय, वास्तविक क्षमता और problem-solving skills पर केंद्रित बदलाव की आवश्यकता पर बल दिया गया

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

1 टिप्पणियां

 
GN⁺ 2025-05-16
Hacker News राय
  • भर्ती करने वाले के नज़रिए से ईमानदार राय। व्यक्तिगत रूप से मुझे takehome असाइनमेंट पसंद नहीं हैं। ऐसे असाइनमेंट सबका समय बर्बाद करते हैं। अगर यह hiring के आख़िरी चरण में हो तो समझ आता है, लेकिन उम्मीदवारों को छाँटने के लिए इसका इस्तेमाल करना अक्षम है।
    1. बहुत ज़्यादा सवाल आए। अस्पष्टता के बीच निर्णय क्षमता का इस्तेमाल कर समस्या हल करना भी असाइनमेंट का हिस्सा है। दिए गए निर्देशों के हिसाब से, एक-दो दिन लगाकर एक साधारण local project स्तर का काम काफ़ी था।
    2. प्रस्ताव लिखना और साझा करना ज़रूरत से ज़्यादा था। लगता है उम्मीदवार अपनी thoroughness दिखाना चाहता था, लेकिन कंपनी के नज़रिए से यह अक्षम और समय की बर्बादी लग सकता है।
    3. अंतिम परिणाम functional था, लेकिन infrastructure और polishing पर बहुत ज़्यादा मेहनत की गई। अस्वीकार होने पर यह आख़िरकार समय की बर्बादी बन गया।
    4. लगता है requirement में terminal-प्रेरित email client की बात थी, लेकिन परिणाम में वह दिशा दिखाई नहीं दी।
      उम्मीदवार की क्षमता और काम के प्रति जुनून को मानता हूँ। बस थोड़ा अलग नज़रिए से राय देना चाहता था।
    • ब्लॉग लेखक का रवैया थोड़ा खटकता है। सिर्फ़ लेख पढ़कर भी लगता है कि इनके साथ काम करना कठिन होगा, ये autonomously फैसले लेना मुश्किल पाएँगे, और साफ़ guideline की ज़रूरत होगी। बड़े संगठनों के लिए ठीक, लेकिन startup के लिए नहीं।
      "terminal-प्रेरित email client बनाकर customers के साथ alpha test करना" शुरुआती startup engineer के लिए एक उचित request है। स्पेक्स और भी हों तो भी बहुत कुछ engineer के judgement पर निर्भर करता है। उम्मीदवार certainty बहुत ज़्यादा चाहता है।
      Kagi असाइनमेंट पूरा होने के बाद कैसा feedback देगा, यह पहले से पूछना अच्छा संकेत नहीं है। ऐसी स्थिति में पक्का जवाब देना संभव नहीं होता। शायद वे सैकड़ों-हज़ारों applications evaluate कर रहे होंगे।
    • लेखक ने काम अच्छा किया, लेकिन अप्रत्यक्ष "बहुत ज़्यादा कोशिश मत करो" वाली शर्त में असफल रहा।
      अगर requirements को clarify करने की ज़रूरत ही नहीं थी, तो फिर सीधे "1~10 के बीच का नंबर बताओ" कहकर गलत चुनने वालों को बाहर करने जैसा ही हुआ।
      सिर्फ़ इसलिए reject करना कि किसी ने असाइनमेंट में मेहनत की और अच्छी finishing दी, इससे मैं सहमत नहीं हूँ।
      ऐसे अस्पष्ट असाइनमेंट असल में सिर्फ़ "culture fit" चुनने का एक और तरीका हैं।
    • मेरे हिसाब से उम्मीदवार का अपनी ideas को validate करने वाला approach आजकल की engineering शैली से मेल खाता है। एक healthy team feature spec को English में समझाकर approval लेकर आगे बढ़ती है।
      "पहले code, feedback बाद में" वाली संस्कृति मेरे करियर का सबसे नुकसानदेह अनुभव रही है। इस उम्मीदवार ने आधुनिक software practices का पालन किया। (मैं 1000+ engineers वाली कंपनी में hiring manager हूँ)
    • hiring manager के नज़रिए से अच्छा takehome वही है जो 30 मिनट में पूरा हो जाए, evaluation criteria साफ़ हों, और जिसमें अलग-अलग approach व trade-off पर सोचने की गुंजाइश हो।
      मैं भी पिछली job search में एक बहुत व्यापक takehome में reject हुआ था क्योंकि समझ ही नहीं आया कि किस हिस्से पर मूल्यांकन हो रहा है। उस अनुभव के बाद से ऐसे असाइनमेंट के प्रति मुझमें कड़ा विरोध है।
    • मुझे लगता है अस्वीकृति का कारण proposal का बहुत बड़ा हो जाना था। निर्देशों में proposal माँगा ही नहीं गया था, और बहुत detailed submission को उल्टा "self-driven execution की कमी" के रूप में पढ़ा जा सकता है। तब code quality का कोई मतलब नहीं रह जाता।
      कंपनी को कम से कम उसी बिंदु पर असाइनमेंट रोक देना चाहिए था, बजाय उम्मीदवार को समय बर्बाद करने देने के।
    • अफ़सोस है कि आजकल industry में requirements समझने की क्षमता की कमी के कारण mind reading के आधार पर developers को छाँटा जाता है।
    • उम्मीदवार का deadline miss करना भी समस्या है। किसी खास वजह के बिना देरी, पहले ही reject होने के लिए काफ़ी है। deadline के भीतर उचित solution design करना ही असाइनमेंट का उद्देश्य था।
    • बिंदु 4 में terminal वाले उल्लेख पर, लेखक द्वारा साझा किए गए full version में उस हिस्से की व्याख्या है।
    • ऐसी चर्चाएँ परिणाम सामने आने के बाद हमेशा आसान लगती हैं। उलटी रणनीति (requirements confirm न करना, सिर्फ़ minimum requirement पूरा करना) अपनाई जाती, तब भी शायद यही नतीजा आता। ऐसी स्थिति में हमेशा यह भी कहा जा सकता है कि "और सक्रिय रूप से requirements clarify करनी चाहिए थी"।
  • code और demo video देखकर मेरा impression यह था कि एक हफ्ते में सिर्फ़ दो-page web app बनाने में काफ़ी समय लग गया।
    सबसे बुनियादी email features (जैसे mail खोलना) भी नहीं हैं, backend engineer role के लिए apply करने के बावजूद असल में postmark और turso जैसे बाहरी products का इस्तेमाल किया गया, और basic features (plain text formatting, view, folders आदि) भी नहीं दिखते।
    admin page, login जैसी सहायक features हैं, लेकिन mail header map जैसी न्यूनतम data structure भी नहीं थी।
    वह अच्छा engineer हो सकता है, लेकिन इस position के लिए उपयुक्त नहीं लगा।
    takehome proposal भी बहुत असामान्य लगा।
    original posting फिर से पढ़ने पर दिखा कि "minimal terminal-inspired email client" और aerc, mutt, himalaya जैसे references साफ़ लिखे थे। यह requirements की स्पष्ट गलत व्याख्या थी।
    • "requirements की गलत व्याख्या" वाली बात पर, मैं जानना चाहता हूँ कि आखिर कौन-सी requirements पूरी नहीं हुईं।
      terminal या web app के रूप में email client, और basic features implement करने की माँग थी, जो मुझे लगता है पूरी हुई।
      terminal-based tools से प्रेरणा लेने वाला हिस्सा subjective है। अगर यह backend position है, तो UI पर ज़रूरत से ज़्यादा ध्यान देना अक्षम भी हो सकता है।
    • उम्मीदवार ने समय लगाया हो और बदले में सिर्फ़ एक rejection email मिले, यह दुखद है।
      कम-से-कम feedback मिल जाए तो growth में मदद मिल सकती है, लेकिन वास्तविकता में वह भी कई बार संभव नहीं होता।
      इसी वजह से takehome असाइनमेंट को लेकर संदेह पैदा होता है। उम्मीदवार और hiring team, दोनों को एक-दूसरे के समय का सम्मान करना चाहिए।
    • "Email client can either be in the terminal (i.e. a TUI) or a web app" यह पंक्ति मौजूद है।
  • takehome evaluation उपयोगी हो सकता है, लेकिन इसमें समय-सीमा ज़रूर होनी चाहिए।
    2~3 घंटे उम्मीदवार का आकलन करने के लिए काफ़ी हैं। अगर समय-सीमा होती, तो उम्मीदवार भी उसी सीमा में उचित समाधान दे सकता था, और कंपनी की अपेक्षा भी साफ़ होती।
    साथ ही कंपनी को यह साफ़ बताना चाहिए कि क्या 'कोई भी उत्तर ठीक है' या 'सबसे अच्छा उत्तर' अपेक्षित है।
    takehome का उद्देश्य test pass करना है, mission completion rate है, या code quality है—यह असाइनमेंट के प्रकार के अनुसार बदलता है, इसलिए उम्मीदवार भ्रमित हो सकता है।
    • recruiter के नज़रिए से Kagi का असाइनमेंट बहुत बड़ा है और उम्मीदवारों के समय के प्रति असम्मानजनक है।
      उल्टा इससे ऐसे लोग छँट सकते हैं जो वास्तव में बहुत व्यस्त या समय से दबे हों।
      हमारी कंपनी बस एक simple ETL problem देती है और 4 घंटे की सीमा रखती है।
      पूरा न कर पाना भी ठीक माना जाता है, और follow-up में code review व सवाल-जवाब का समय होता है।
      असली क्षमता तो इसी follow-up meeting में समझ आती है।
    • उम्मीदवार वास्तविक समय-सीमा से कहीं ज़्यादा समय लगा सकते हैं; hiring side को यह कैसे पता चलेगा, यह सवाल है।
      on-site असाइनमेंट में जहाँ सबके लिए समान समय होता है, takehome में अलग-अलग समय निवेश के कारण लोग नुकसान में पड़ सकते हैं।
      इस हिसाब से 1 घंटे की on-site coding बेहतर है। उम्मीदवार और interviewer दोनों एक ही समय निवेश करें, तभी समय की क़ीमत का पारस्परिक सम्मान होता है।
    • मेरे हिसाब से live review, live coding से कहीं बेहतर है। अगर live coding करनी ही हो, तो बेहतर है कि मैं अपने laptop पर 45 मिनट दूर से काम करूँ और फिर वापस आकर review करूँ।
  • यह सच है कि कंपनी का जवाब असहज और गैर-मददगार था, लेकिन requirements में 'terminal-inspired' साफ़ लिखा था।
    demo video में सिर्फ़ एक सामान्य web app दिखता है। स्पष्ट रूप से कहा गया था कि aerc, mutt, himalaya जैसे existing terminal email clients से प्रेरणा लो।
    मुझे समझ नहीं आ रहा कि क्या मैं कुछ मिस कर रहा हूँ।
    • अगर rejection email में कारण साफ़-साफ़ बताया गया होता तो बेहतर होता, लेकिन मूल असाइनमेंट design में terminal client references सीधे दिए गए थे।
      terminal client की खास UX अभी भी ऐसा क्षेत्र है जहाँ कोई एक 'सही' जवाब नहीं है, इसलिए संभव है कि कंपनी ने उसी बिंदु को evaluation criteria बनाया हो।
    • Go language पर ज़ोर देखते हुए, CLI बनाना 20 lines से भी कम का काम है, तो फिर web GUI बनाने में इतनी ऊर्जा लगाने का फ़ैसला सवाल खड़ा करता है।
    • "Email client can either be in the terminal (i.e. a TUI) or a web app" जैसी guidance मौजूद है।
  • हाल की एक interview process में मुझे भी ऐसा ही अनुभव हुआ। मैंने असाइनमेंट project बहुत अच्छे से जमा किया, लेकिन project पर कोई चर्चा किए बिना सीधे rejection दे दिया गया।
    मेरा मानना है कि अगर takehome माँगा गया है, तो follow-up meeting ज़रूर होनी चाहिए।
    मैं पहले से Kagi का paid user हूँ, लेकिन इस घटना के बाद account बंद करने पर विचार कर रहा हूँ।
    अगर उम्मीदवार से बात करने का समय ही नहीं है, तो शुरुआत में असाइनमेंट माँगना ही नहीं चाहिए।
    • takehome असाइनमेंट सिर्फ़ उम्मीदवार के लिए ही नहीं, उसे evaluate करने वाले interviewer के लिए भी काफ़ी मेहनत का काम है।
      review तक करने के बाद, मेरा मानना है कि feedback पाने का हक़ बनता है।
      लेकिन व्यवहार में, दर्जनों मज़बूत उम्मीदवारों में से सिर्फ़ एक को चुनना हो, तो reject होना हमेशा "काबिलियत की कमी" का मतलब नहीं होता।
      क़ानूनी रूप से भी 'A को क्यों चुना और B को क्यों नहीं?' का औपचारिक जवाब अक्सर सिर्फ़ कमियाँ गिनाने तक सीमित रह जाता है।
    • अगर कंपनी ने यह साफ़ किया होता कि वह कैसे evaluate करेगी, या feedback दिया होता, तो बेहतर होता। असफलता पर बिना feedback के समय बर्बाद होना स्वीकार्य नहीं है।
      कई कंपनियाँ इस हिस्से को बेहतर ढंग से संभालती हैं।
    • क्या वह सच में 'उत्कृष्ट solution' था, इस पर भी संदेह है। minimal terminal-inspired email client और उससे जुड़े references को जैसे पूरी तरह नज़रअंदाज़ कर दिया गया।
      अगर requirements की यह गलतफ़हमी बड़ी हो, तो चर्चा ही छोड़ दी जा सकती है।
  • यह मामला असाइनमेंट के hidden intent को गलत पढ़ने का एक क्लासिक उदाहरण है।
    कंपनी ऐसे व्यक्ति को चाहती थी जो autonomous हो और अपने लक्ष्य खुद तय कर सके।
    अस्पष्टता का मकसद यह देखना था कि उम्मीदवार उत्तर को कई कोणों से खोजकर कैसे निकालता है।
    • वह असाइनमेंट ऐसे व्यक्ति के लिए था जो संभवतः सबसे simple, clever और functional solution दे सके।
      prototype-केंद्रित कंपनी के लिए हर व्यक्ति उपयुक्त नहीं होता, इसलिए कोई उम्मीदवार 10 मिनट सोचकर 60 मिनट में अपनी सर्वोत्तम क्षमता दिखा सकता था।
    • अगर R&D project हो और बस 'minimal' पर ज़ोर दिया गया हो, तो यह समझना मुश्किल है कि वह prototype है, user-facing product है, UX पर ध्यान देना है या नहीं—यह सब evaluator क्या महत्व देता है, इसे भाँपने का खेल बन जाता है।
    • ऐसे "खुद interpret करो" वाले असाइनमेंट में requirements clarify न करने या अतिरिक्त सवाल न पूछने वाला व्यक्ति reject भी हो सकता है।
      लेकिन developers के लिए ऐसे सवाल पूछना बहुत महत्वपूर्ण गुण है। इसलिए hiring process से अपेक्षा भी बढ़ती है और निराशा भी।
    • मेरे हिसाब से "misreading the subtext" नहीं, बल्कि वह बात requirements में ही लिखी थी।
    • शैक्षिक माहौल में 'समझ नहीं आया' कहकर सिर्फ़ छात्र को दोष देना बहुत आसान निष्कर्ष है।
      असली वजह अस्पष्ट explanation होती है।
      अच्छा शिक्षक अधिकतम लोगों को समझा पाता है। अगर बहुत से लोग confused हैं, तो समस्या सवाल बनाने वाले में है।
      विश्वविद्यालय के छात्रों को किसी Zen koan जैसा पहेली-सुलझाव नहीं करना चाहिए।
  • चूँकि पोस्ट लेखक ने खुद यह लिखा है, मैं Kagi में काम कर चुके अनुभव के आधार पर कुछ context देना चाहता हूँ।
    पहले Vlad खुद उम्मीदवारों को evaluate करते थे और असाइनमेंट भी इसी तरह होते थे।
    कंपनी के बढ़ने के साथ लगता है अब दूसरे लोग evaluation कर रहे हैं।
    Vlad की HN-style प्रवृत्ति है और वे ऐसे उम्मीदवारों के साथ काम करना पसंद करते हैं जिन्हें वे "cool" मानते हैं।
    उदाहरण के लिए, अगर कोई लंबा design document लिखकर कहे "हम Galactor इस्तेमाल करेंगे और project flop-ready है," तो इसका ठीक उलटा असर होगा।
    "terminal-inspired" requirement में वे अक्सर keyboard shortcuts जैसी वास्तविक terminal app details की अपेक्षा करते हैं।
    यह अच्छा filter है या नहीं, इस पर बहस हो सकती है, लेकिन अगर आप उस context को समझते हैं और pass करने की क्षमता रखते हैं, तो असाइनमेंट आसान लग सकता है।
    अच्छा होता अगर Kagi यह context बेहतर ढंग से communicate करता। समय बर्बाद होना दुर्भाग्यपूर्ण है, लेकिन उम्मीद है कि लेखक को अपनी प्रवृत्ति के अनुकूल कंपनी मिले।
    • बहुत-सी कंपनियाँ अपने जैसे सोचने वाले लोगों को ढूँढ़ती हैं।
      विविधता रहित टीम एक ही दीवार से बार-बार टकराकर ठहर सकती है।
      यह startup में विशेष रूप से आम है, और शायद 9/10 startups के विफल होने से भी जुड़ा है।
    • मुझे समस्या यह लगती है कि Vlad "cool people" ढूँढ़ने के लिए बहुत ज़्यादा लोगों का समय बर्बाद कर रहे हैं।
      बिना स्पष्ट मानदंड के graded असाइनमेंट मुझे अनुचित लगते हैं।
      अंततः यह "मेरे दिमाग़ वाले जवाब" को match करने जैसा एक implicit task बन जाता है।
      इससे लोगों के प्रति संवेदनशीलता की कमी झलकती है।
    • मेरे मन में यह सवाल आता है, "क्या मुझे सचमुच यह सब पहले से पता होना चाहिए था?"
      अगर संस्कृति ऐसी है, तो क्या हर किसी को undercover की तरह पहले जाँच-पड़ताल करनी चाहिए थी, कहना मुश्किल है।
      मेरे जैसे 'cool नहीं' उम्मीदवारों के लिए भी बेहतर होता कि उन्हें साफ़ संकेत मिले और वे जल्दी दूसरी कंपनियों की ओर बढ़ सकें।
  • code को सीधे review करने पर, पहली file से ही ऐसा लगा कि बिना किसी उद्देश्य के sample code कॉपी किया गया है; comments, mismatched explanation, और ध्यान की कमी दिखाने वाले expressions मिले।
    इन बारीक कमियों के कारण मैं review यहीं रोक देता।
    • मैंने app को अपने domain पर deploy किया था और performance में कोई समस्या नहीं थी। auth और infrastructure जैसे backend पहलू भी अच्छी तरह implement किए थे। लेकिन यह कहना कि मुझे code comments पर और ध्यान देना चाहिए था, इससे मैं सहमत नहीं हूँ।
    • इस मामले की मुख्य समस्या अस्वीकृति नहीं, बल्कि यह है कि बिना स्पष्ट guidance और बिना feedback के ऐसी hiring process उम्मीदवार के समय के प्रति बिल्कुल सम्मानजनक नहीं थी।
  • DuckDuckGo में भी मुझे ऐसा ही अनुभव हुआ, लेकिन वहाँ हर stage पर कुछ compensation मिला।
    simple design proposal से लेकर implementation task तक, हर चीज़ स्पष्ट समय-सीमा के साथ कराई गई।
    अंततः मेरा चयन नहीं हुआ और स्पष्ट कारण भी नहीं बताया गया।
    शायद applicants बहुत ज़्यादा थे, लेकिन यह अनुभव लंबे समय तक भावनात्मक रूप से असर छोड़ गया। OP की भावना समझ सकता हूँ।
  • engineering interviewer के नज़रिए से कहूँ तो leetcode और takehome दोनों ही समय लेते हैं और जानकारी सीमित देते हैं।
    फिर भी, अगर मैं hiring manager होता तो शायद लेखक को reject करता।
    startup को ऐसे लोग चाहिए जो तेज़ी से और practical तरीके से काम करें।
    अतीत में मेरा एक सहकर्मी आसपास के लोगों की राय इकट्ठा करके कई दिन अकेले डूबा रहता था, और तब तक requirements बदल चुकी होती थीं; यह किसी के लिए अच्छा नहीं था।