- Kagi Search की बैकएंड hiring प्रक्रिया में एक डेवलपर ने terminal जैसा email client लगभग एक सप्ताह full-time लगाकर बनाया, लेकिन submission के बाद बिना follow-up interview के reject कर दिया गया
- असाइनमेंट TUI या web app, basic email viewing/sending, fake backend या IMAP/POP/JMAP में से चुनाव जैसे विकल्पों के साथ खुला था, इसलिए implementation scope और evaluation criteria का आकलन उम्मीदवार को खुद करना पड़ा
- उम्मीदवार ने Go web app, AWS ECS Fargate, SSL, Postmark, login, Pulumi, Pocketbase, TEMPL आदि शामिल करते हुए पहले से एक detailed plan भेजा, लेकिन Kagi ने specific acceptance criteria नहीं बताए
- rejection के बाद मांगे गए feedback में केवल यह जवाब मिला कि “और simple और strong submissions” थे, और बताया गया कि इस stage पर आम तौर पर individual feedback नहीं दिया जाता
- यह अनुभव दिखाता है कि unpaid assignment-based interviews और time-limited coding puzzles, वास्तविक engineering capability से ज़्यादा उम्मीदवार के समय और जीवन-परिस्थितियों की परीक्षा ले सकते हैं
आवेदन और असाइनमेंट मिलना
- उम्मीदवार ने Kagi Search के backend role के लिए resume भेजा था, और role summary में ये क्षमताएं शामिल थीं
- backend systems बनाने का अनुभव
- Go में proficiency
- backend systems को scale और maintain करने की समझ
- SRE और team members के साथ collaboration की क्षमता
- Docker जैसी containerization technologies की समझ
- इसके बाद Kagi से अगले step के रूप में Kagi Developer Assessment पूरा करने के लिए email मिला
- assignment URL HackMD के जरिए भेजा गया
- इसमें कहा गया था कि completion के बाद संपर्क करने पर वे review करेंगे, और pass होने पर follow-up interview में approach और solution पर चर्चा होगी
असाइनमेंट requirements और खुले evaluation criteria
- असाइनमेंट का लक्ष्य “minimal terminal जैसा email client” बनाना था
- implementation conditions काफी broadly open थीं
- email client को terminal TUI या web app के रूप में implement किया जा सकता था
- basic email viewing और sending functionality चाहिए थी
- fake backend (DB, in-memory आदि) या real IMAP/POP/JMAP backend इस्तेमाल किया जा सकता था
- rich text messages को छोड़कर केवल plain text handle करना था
- बताया गया कि evaluation में सिर्फ coding ability नहीं, बल्कि Kagi Labs जैसे R&D projects के लिए जरूरी ambiguity और open-ended problems को handle करने की क्षमता भी शामिल होगी
- deliverables की शर्तें इस प्रकार थीं
- developer के रूप में अपनी क्षमता दिखाने वाले तरीके से implement करना
- completed project को GitHub repository पर डालना और कहीं deploy करना ताकि आसानी से test किया जा सके
- README में setup instructions लिखना
recruiter के साथ communication
- उम्मीदवार को requirements बहुत broad लगीं, इसलिए उसने recruiter को सवाल भेजे
- recruiter ने जवाब दिया कि candidates बहुत हैं; कुछ candidates केवल basics implement करते हैं, जबकि कुछ extra features, अच्छी documentation, decision-making explanations, demo deployment और future plans तक देते हैं
- जब पूछा गया कि कौन से extra features को अधिक महत्व दिया जाता है, तो recruiter ने कहा कि “यह खुद evaluation का हिस्सा है” और वे देखना चाहते हैं कि candidate कौन से extra features सोचता है
- उम्मीदवार ने actual coding से पहले पूरे deliverable का detailed implementation plan लिखकर भेजने का फैसला किया
- उसे उम्मीद थी कि proposal accept होने पर phone interview या job offer के करीब पहुंचा जा सकता है
- बाद में परिणाम देखकर उसने माना कि पहले से expectations align करने की कोशिश recruiter के लिए ज्यादा मायने नहीं रखती थी
उम्मीदवार द्वारा प्रस्तावित implementation
- proposal का केंद्र Go web app आधारित email client था
- AWS पर deploy करना
- ECS Fargate इस्तेमाल करना
- SSL/HTTPS लागू करना
- email sending provider के साथ integration
- login screen के जरिए authentication
- form-based email sending
- UI में incoming emails दिखाना
- proposal में delivery date रविवार, 30 मार्च EOD रखी गई थी, और लिखा था कि यह initial email के बाद दो सप्ताह वाले point से दो business days बाद की तारीख है
- technology choices ये थीं
- Go backend: Pocketbase और TEMPL का उपयोग
- infrastructure code: Pulumi का उपयोग, TypeScript SDK चुना
- email service provider: Postmark का उपयोग
- UI: sent/received emails की pagination, login screen, demo के लिए 2 accounts उपलब्ध कराना
- इन choices का कारण role और evaluation scope को व्यापक रूप से दिखाने से जुड़ा था
- backend role होने के बावजूद web frontend जोड़ना web technologies की breadth दिखा सकता था
- database backend role से संबंधित था
- AWS और infrastructure code deployment, IaC, Docker, networking और resilience पर चर्चा से जुड़ता था
- Postmark जैसी email service IMAP/POP integration की complexity घटाते हुए functionality बनाए रखती है
- उम्मीदवार ने पूछा कि “पूरा करने पर Kagi से कैसी प्रतिक्रिया expect कर सकता हूं”, लेकिन जवाब “बहुत interesting है और submission का इंतजार है” के स्तर तक ही सीमित रहा
submission और rejection
- उम्मीदवार ने प्रस्तावित सब कुछ implement किया और बताया कि पूरे काम में एक सप्ताह full-time लगा
- web application demo YouTube पर डाला और code documentation के साथ GitHub पर public किया
- automated rejection email मिलने के बाद feedback मांगने पर Kagi ने इस तरह जवाब दिया
- इस stage पर वे आम तौर पर feedback नहीं देते
- कुछ और simple और strong submissions थे, इसलिए उन candidates के साथ आगे बढ़ने का फैसला किया गया
- हर position के लिए बहुत interest और applications मिलते हैं, इसलिए selection process बहुत competitive है
- future positions देखते रहने और दोबारा apply करने को कहा
rejection के बाद बचे सवाल
- उम्मीदवार का मानना था कि अगर “simpler solution” चाहिए था, तो 18 मार्च को proposal भेजे जाने के समय बताया जा सकता था
- अगर solution role के अनुरूप नहीं था, तो इसी तरह 18 मार्च के proposal stage पर ही यह判断 किया जा सकता था
- उसने लिखा कि 13 मई तक, rejection के डेढ़ महीने बाद भी job posting अब भी live थी
- उसने माना कि company उसी posting से कई roles भर सकती है
- फिर भी उसे इसे “ऐसी competition जिसमें winner की जगह पहले ही भर चुकी थी” जैसा मानना मुश्किल लगा
- original assignment instructions में demo deployment अच्छा माना गया था लेकिन mandatory नहीं था, जबकि submission के बाद instructions को बदलकर deployment को strict requirement बना दिया गया, ऐसा उसने लिखा
बेहतर selection process के लिए सुझाव
- उम्मीदवार ने unpaid assignments की आलोचना की कि ये job seekers, खासकर बेरोजगार अवस्था में savings घट रहे लोगों, पर बड़ा बोझ डालते हैं
- LeetCode-style interviews को लेकर भी उसका रुख negative था
- उसने लिखा कि हाल में Clojure-based role में उसने “coin change” problem solve की, और 50 minutes में लगभग आधे tests pass कर लिए, लेकिन backtracking part implement करने के लिए समय कम पड़ गया
- alternative के रूप में उसने live code review का सुझाव दिया
- उसके अनुसार यह asynchronous या synchronous, दोनों तरीकों से संभव है
- real software project की problems और topics को बातचीत में समझाया जा सकता है
- experienced software engineer की knowledge बेहतर तरीके से सामने आ सकती है
- वह live coding का पूरी तरह विरोध नहीं करता, लेकिन 50 minutes में knapsack solve करने की क्षमता को रोजमर्रा के engineering काम से काफी दूर मानता है
- वह सलाह देता है कि अगर स्थिति बहुत मजबूरी वाली न हो, तो इस तरह का unpaid work मांगने वाले roles को reject कर देना चाहिए
1 टिप्पणियां
Hacker News की राय
भर्ती करने वाले के नज़रिए से देखें तो, take-home assignment मुझे इन वजहों से पसंद नहीं हैं। यह सभी का समय बर्बाद करता है; भर्ती से ठीक पहले आखिरी चरण के रूप में ठीक हो सकता है, लेकिन filter के रूप में इस्तेमाल करना उचित नहीं है
फिर भी क्षमता और ईमानदार कोशिश साफ़ दिखती है; मैं बस दूसरे नज़रिए से devil’s advocate बनकर देख रहा था
“कुछ customers के साथ alpha test कर सकें ऐसा terminal-style email client बना दीजिए” early-stage startup engineer के लिए एक reasonable request है, और details engineer पर छोड़नी ही पड़ती हैं
ख़ासकर “अगर मैं इसे completion तक ले जाऊँ तो Kagi से कैसी प्रतिक्रिया expect कर सकता हूँ, यह जानना चाहता हूँ” वाली request अच्छी नहीं थी। जब सैकड़ों-हज़ारों submissions देखने हों, तो कोई पक्का जवाब देने का तरीका नहीं होता
अगर requirements स्पष्ट करने की कोशिश करना unwanted behavior है, तो यह 1 से 10 के बीच कोई number चुनवाकर गलत चुनने वालों को बाहर करने से अलग नहीं है
take-home test क्षमता दिखाने के लिए होता है; अगर specific guidance न हो तो कोई कैसे अंदाज़ा लगाए कि कितना दिखाना है
polishing तभी बुरी होती है जब वह delivery रोक दे; “बहुत ज़्यादा polish कर दिया” कहकर reject करना ऐसा लगता है जैसे बहुत अच्छा काम करने की वजह से बाहर कर दिया गया हो
इस तरह के ambiguous tests अंततः culture fit नहीं होने के नाम पर लोगों को छाँटने का एक और तरीका लगते हैं
“पहले बनाओ, बाद में review करो” वाले environments मेरे career में सबसे toxic जगहों में रहे हैं; किसी feature पर कई दिन लगाने के बाद पता चले कि वह unwanted feature था, तो सबसे खराब स्थिति होती है
इसलिए feature को लिखकर explain करना और approval लेना project launch के industry standard के क़रीब है, और इस applicant ने healthy organizations द्वारा अपनाई जाने वाली software practices follow कीं
1,000 से ज़्यादा engineers वाली company में hiring manager के तौर पर भी मैं इसे ऐसे ही देखता हूँ
बेशक, यह सिर्फ़ उन candidates को दिया जाना चाहिए जिनके लिए result hiring decision को प्रभावित कर सकता है
आखिरी job search के दौरान मुझे ऐसा ही broad assignment मिला था; job के लिए मैं overqualified था, फिर भी इस वजह से reject हो गया कि मुझे अंदाज़ा नहीं था कौन-सा हिस्सा grade किया जाएगा
आगे referral के बिना job मिलने की संभावना कम लगती है, लेकिन ऐसे assignments लेना और देना, दोनों से अब काफ़ी परहेज़ हो गया है
यह assignment कुछ सवाल पूछने, assumptions लिखने, और ambiguous काम में confidence के साथ कूदकर बनाने की क्षमता देखने के लिए था
शायद वह email जाने के बाद code मायने नहीं रखता था, और company को उसी समय process खत्म कर देना चाहिए था ताकि applicant assignment implement करने में समय बर्बाद न करे
code देखकर और demo video देखने पर मेरा पहला ख़याल था, “दो page वाली web app बनाने में एक हफ्ता लगा, और message खोलने जैसी सबसे basic email functionality भी नहीं है”
requirements देखीं तो यह व्यक्ति “Email Backend Engineer” के लिए apply कर रहा था, लेकिन actual email backend के लिए Postmark और Turso जैसे third-party products इस्तेमाल किए
plain text email format, viewing, folders, कम से कम inbox और sent जैसी basic चीज़ें गायब थीं, जबकि login screen, admin page, backend framework जैसी optional चीज़ें शामिल थीं
backend database में email header map तक नहीं है
वह अच्छे engineer हो सकते हैं, लेकिन इस specific position के लिए fit नहीं दिखते, और मैं भी reject करता
original posting देखी तो title था “The project is to build a minimal, terminal-inspired email client”, और साफ़ लिखा था कि aerc, mutt, himalaya जैसे existing terminal email tools से inspiration लें
यह requirements ठीक से न पढ़ने के स्तर का है, इसलिए hire नहीं किया जा सकता लगता है
दोनों पर्याप्त रूप से पूरी हुई लगती हैं
existing tools से inspiration लेना subjective है, और backend position के assignment में user interface पर समय खर्च करना skill दिखाने का सबसे अच्छा तरीका है, ऐसा उन्होंने शायद नहीं सोचा होगा
popular position में अगर recruiter को सैकड़ों लोगों को review करना पड़े तो यह हमेशा realistic नहीं होता, यह समझता हूँ; लेकिन इसी वजह से take-home process अच्छा नहीं लगता
applicant अपनी ज़िंदगी के कई घंटे कुछ भी हासिल किए बिना बर्बाद कर सकता है, इसलिए दोनों पक्षों को एक-दूसरे के समय का सम्मान करना चाहिए
यह समझ आता है कि जवाब बहुत छोटा था और मददगार नहीं था, लेकिन requirements में साफ़ तौर पर terminal-inspired ईमेल क्लाइंट बनाने को कहा गया था
शेयर किए गए वीडियो https://www.youtube.com/watch?v=yY1sVXMkP_o को देखें तो यह एक साधारण ईमेल वेब ऐप जैसा दिखता है, जिसमें खास तौर पर terminal से प्रेरित कुछ नहीं दिखता
अगर वे वास्तविक TUI या वेब ऐप में से कोई एक चाहते थे, तो बहुत संभव है कि वेब ऐप भी terminal-style होना चाहिए था
पूरी requirements के “Inspiration” में साफ़ लिखा है कि “aerc, mutt, himalaya जैसे मौजूदा terminal email tools से प्रेरणा लें”
फिर भी prompt ने दूसरे terminal clients को inspiration के तौर पर स्पष्ट रूप से बताया था
साथ ही, terminal client वाली requirement evaluation के दायरे को काफ़ी बदल देती है। ईमेल वेब UI लंबे समय से जाना-पहचाना क्षेत्र है, लेकिन terminal client का user experience अभी पूरी तरह “solve” हुआ क्षेत्र नहीं है
संभव है कि evaluation rubric में terminal client design decisions का बड़ा हिस्सा रहा हो, जिसे applicant की submission ने बिल्कुल address नहीं किया
Take-home evaluations interview process में valuable हो सकते हैं, लेकिन उनमें time limit ज़रूरी है। 2–3 घंटे में ज़रूरी जानकारी पर्याप्त मिल जाती है; उससे आगे यह लगभग उन freshers को छांटने जैसा हो जाता है जिन पर dependents, hobbies या responsibilities नहीं हैं
अगर इसे 3 घंटे तक सीमित किया गया होता, तो worst case में applicant सिर्फ 3 घंटे गंवाता, और ज़्यादा संभावना यह थी कि वह उस समय सीमा के हिसाब से बिल्कुल अलग proposal या solution देता
applicant को यह भी confirm करना चाहिए कि “आपको कोई भी जवाब चाहिए, या अच्छा जवाब चाहिए”
कुछ assignments सिर्फ test suite pass होने को देखते हैं, approach मायने नहीं रखती; लेकिन कुछ assignments requirements का 80% ही पूरा होने पर भी बेहतर code को prefer करते हैं। मैंने दोनों तरफ applicants को गलत अंदाज़ा लगाते देखा है
ऐसे assignments उन लोगों को filter कर सकते हैं जो project पर बहुत समय बर्बाद कर सकते हैं, और उल्टा busy लोगों—यानी जिन लोगों को शायद आप चाहते हों—को दूर कर सकते हैं
data engineering क्षमता के लिए मैं एक simple ETL assignment देता हूं। ZIP file से data निकालना, transform करना और किसी भी database में डालना
कुछ ambiguity छोड़ देता हूं, और dataset में unexpected null values या गलत format वाले CSV जैसे hidden elements डालता हूं ताकि execution ability देखी जा सके
इसे 4 घंटे तक सीमित करता हूं, लेकिन time कम पड़ने पर क्या करें इसकी guidance नहीं दी थी; यह एक अच्छा suggestion है
बाद की call में code साथ में देखते हैं और “अगर dataset memory में पूरा fit न हो तो?” जैसे सवालों से improvements पूछते हैं, और वही असली technical evaluation बनता है
इस बात की कोई guarantee नहीं कि सभी applicants ने समान समय लगाया, इसलिए यह game theory की समस्या बन जाती है, और applicant आम तौर पर किसी न किसी रूप में नुकसान में रहता है
कई मामलों में सही जवाब यह होता है कि ज़्यादा समय लगाकर बहुत polished, लेकिन ज़रूरत से ज़्यादा polished नहीं, solution बनाया जाए और फिर time limit मानने का दिखावा किया जाए
3 घंटे भी उस applicant के लिए बहुत लंबा समय है जिसे यह भी नहीं पता कि वह next person से बात कर पाएगा या नहीं
1 घंटे के interview में programming assignment कराते हुए यह ensure किया जा सकता है कि applicant extra समय बर्बाद नहीं कर रहा
अगर applicant चाहे तो बाद में improved answer भेजने दे सकते हैं, और आम तौर पर उस point पर मैं पहले ही उसकी capability को अच्छा मान चुका होता हूं, इसलिए कह सकता हूं कि “करना चाहें तो करें, लेकिन आप already pass हैं”
applicant और interviewer के time investment को बराबर रखें, तो जैसे मैं अपने समय का सम्मान करता हूं वैसे applicant के समय का भी सम्मान करूंगा
अगर hiring manager applicant के समय का सम्मान नहीं करता, तो लगता है कि वह employees के समय का भी शायद सम्मान नहीं करेगा
हाल में कई जगह interviews दिए और यह अनुभव इससे बहुत मिलता-जुलता था। assignment के लिए बेहतरीन solution दिया, लेकिन deliverable पर कोई discussion किए बिना reject कर दिया गया
recruiter के तौर पर take-home process कई बार चलाने के अनुभव से मेरा मानना है कि अगर किसी से घर पर assignment करवाया है, तो code पर बातचीत ज़रूर करनी चाहिए
अगर take-home मिलता है, तो यह ज़रूर confirm करें कि evaluation result चाहे जो हो, follow-up conversation होगी या नहीं; अगर आप सहमत नहीं हैं, तो “homework” न करने की strongly सलाह दूंगा
सच कहूं तो कई hiring teams का level कम होता है, इसलिए अच्छा solution implement करना उल्टा minus बन सकता है। आप इस frustrating वजह से reject हो सकते हैं कि hiring team उस level की नहीं है
मैं Kagi का early user था, लेकिन इस वजह से account cancel करने पर विचार कर रहा हूं। अगर applicant से बात करने का समय नहीं है, तो शुरुआत में ही उससे काम नहीं करवाना चाहिए
take-home सिर्फ applicant के लिए नहीं, बल्कि उसे चलाने वाले व्यक्ति और hiring team के लिए भी काफ़ी effort मांगता है, और अगर project review किया गया है तो request करने पर feedback या response की उम्मीद करना reasonable है
लेकिन reality भी है। अगर एक position के लिए 20 excellent candidates हों, तो बहुत capable लोग भी reject होंगे। इसका मतलब यह नहीं कि वे कमजोर थे या “fail” हुए
अगर legally यह explain करना पड़े कि A को क्यों hire किया और B को क्यों नहीं, तो “दोनों excellent थे, लेकिन हमें एक को चुनना था” कहना मुश्किल होता है, और अंत में लोग उन flaws को भी ढूंढने लगते हैं जो वास्तव में मौजूद नहीं थे
अमेरिकी corporate culture में ऐसी approach अक्सर दिखी है, और Kagi Palo Alto-based है
assignment में fail होना ठीक है, लेकिन बिना कुछ लौटाए किसी का समय बर्बाद करना स्वीकार करना कठिन है
लोकप्रिय startups समेत कई companies हैं जो इसे अच्छे से handle करती हैं
result “minimal terminal-style email client” जैसा बहुत कम दिखता था, और जिन tools से inspiration लेने को कहा गया था उन्हें भी पूरी तरह ignore किया गया लगता है
अगर requirements को इतने बड़े स्तर पर गलत समझा गया हो, तो मैं भी discussion पर समय नहीं लगाता
यह छिपे हुए संदर्भ को गलत पढ़ने का एक क्लासिक मामला है। कंपनी ऐसे व्यक्ति को चाहती थी जो स्वतंत्र रूप से अपना काम और लक्ष्य बना सके
असाइनमेंट की अस्पष्टता कई ईमेल भेजकर कुरेदने के लिए नहीं थी, बल्कि एक खाली कैनवस थी: काफी व्यापक काम लेकर खुद problem space explore करना और नतीजा बनाकर दिखाना
यूनिवर्सिटी में काम करते हुए यह बहुत वैसा ही दिखता है जैसे कोई छात्र असाइनमेंट न समझे, अप्रत्याशित अंक पाए और फिर शिकायत करे
इंटरव्यू जैसी स्थिति में, जहां लोग प्रभाव जमाना चाहते हैं, “आलसी” दिखने की हिम्मत बहुत कम लोगों में होती है
अगर कंपनी का तरीका जल्दी प्रयोग launch करना और prototype-केंद्रित है, तो कुछ लोग सचमुच fit नहीं होंगे, और यह सभी के लिए बुरा है
शायद किसी उम्मीदवार ने 10 मिनट यह सोचने में लगाए होंगे कि 60 मिनट में क्या किया जा सकता है, HTTP authentication और forms का उपयोग करके एक छोटा Go backend चलाया होगा, और उसे छोटे से ईमेल के साथ भेज दिया होगा। प्रक्रिया में ऐसा व्यक्ति शायद कहीं बेहतर दिखा होगा
यह पता नहीं चलता कि यह फेंक देने वाला prototype है, असली users को दिखने वाली चीज है, अधूरे user experience पर आलोचना होगी या वे बस कुछ देखना चाहते हैं
आखिर में यह reviewer की पसंद का अनुमान लगाने की ट्रेनिंग बन जाती है
उलटे, कुछ लोग इसलिए भी reject होते होंगे कि उन्होंने requirements को लगातार push करके स्पष्ट नहीं कराया, जबकि यह engineer के लिए अहम गुण है
जिंदगी निष्पक्ष नहीं है, लेकिन hiring managers से हम ज्यादा उम्मीद करते हैं, और इसलिए बार-बार निराश होते हैं
हो सकता है छात्र mind-reading न कर पाया हो और instructions बेहद खराब लिखे गए हों, इसलिए गलतफहमी हुई हो
अच्छा शिक्षक वह है जो अधिकतम छात्रों को समझा सके; खराब शिक्षक इसका उलटा होता है
सबसे अच्छे शिक्षकों के तहत grading criteria शुरू से transparent होते थे, इसलिए अंकों पर शक करने की जरूरत नहीं पड़ती थी
अगर बहुत से छात्र confused हैं, तो common denominator शिक्षक हो सकता है
बौद्ध भिक्षु कोआन जैसी कठिन पहेलियां हल करके सीखते हैं, इसका मतलब यह नहीं कि फीस देने वाले कॉलेज छात्रों पर भी वही तरीका लागू किया जाए
लगता है लेखक ने खुद यह पोस्ट किया है, इसलिए मैं मिले response का संदर्भ समझाने की कोशिश करूंगा। मैं पहले Kagi में काम कर चुका हूं और इसी तरह के take-home test से गुजरा था
तब कंपनी बहुत छोटी थी, Vlad खुद candidates को review करता था और ऐसे project-style असाइनमेंट इस्तेमाल करता था। अब कंपनी बड़ी हो गई है, इसलिए हो सकता है वह सीधे न देखता हो, लेकिन core बात वैसी ही लगती है
Vlad से बात करने पर वह लगभग Hacker News commenter का आदर्श रूप लगता है, और interview ज्यादा “क्या यह ठीक-ठाक इंसान लगता है” वाली vibe check जैसा होता है
उसे लंबा design document लिखकर “Galactor इस्तेमाल करूंगा, इसे florp-ready बनाऊंगा, और fleem करूंगा” कहना cool होने के बिल्कुल उलट है
अगर असाइनमेंट “terminal-style email client” है, तो लगभग perfect project शायद ऐसी चीज होगी जिसमें हर feature के लिए keyboard shortcuts हों और एक paragraph में बताया गया हो कि एक frame draw करने में 2ms से ज्यादा नहीं लगते
interviewer ने शायद समझा कि candidate Kagi में काम करने के लिए बहुत ज्यादा enterprise-style thinking रखता है
बेशक, यह चयन तरीका अच्छा है या नहीं, यह अलग बात है। Vlad अपने जैसा सोचने वाले लोगों को चाहता है, और ऐसे interviews में लंबे समय से चर्चा और research किए गए कई problems हैं
फिर भी, अगर आप इसे समझते हैं और ऐसी प्रक्रिया झेलने की गुंजाइश रखते हैं, तो असाइनमेंट वास्तव में समझ में आता है। Kagi यह बात बेहतर तरीके से communicate कर सकता था
अफसोस है कि आपका काफी समय बर्बाद हुआ, लेकिन उम्मीद है आप अपने working style के ज्यादा अनुकूल जगह पाएंगे
किसी problem पर नई insight देने के लिए विचारों की विविधता चाहिए। अगर सभी एक ही तरीके से सोचते हैं, तो एक व्यक्ति अटकने पर सभी के अटकने की संभावना होती है
यह startups में आम समस्या लगती है, और शायद इस बात का संकेत भी हो सकता है कि 10 में से 9 startups क्यों fail होते हैं
यह ability test करने से अलग है। यहां पास होने के लिए उन metrics पर high score चाहिए जिनके बारे में बताया ही नहीं गया
“कुछ भी code कर दो, क्योंकि ambiguity handle करनी आनी चाहिए” कहकर असाइनमेंट देना, और असल में मेरे दिमाग में जो है उसे guess करने को कहना, इससे बहुत अलग नहीं है
यह लोगों के प्रति बहुत असंवेदनशील तरीका है, और Vlad नाम के व्यक्ति के बारे में भी अच्छा संकेत नहीं देता
क्या इसे जानने के लिए कंपनी के लोगों के social media खंगालने थे
आखिर अगर मैंने पर्याप्त रूप से दिखा दिया था कि मैं cool नहीं हूं, फिर भी “आगे बढ़ो” कहकर उन्होंने बस अपनी जिज्ञासा पूरी की, तो उम्मीद है उन्हें भी दूसरों से वैसा ही व्यवहार मिले जैसा वे करते हैं
explanation देने के लिए धन्यवाद, कोई बुरी भावना नहीं है। बस काश ऐसा लेख पहले देख लिया होता
आगे से जिन नौकरियों में “take-home” होगा, उन्हें cool बच्चों वाली नौकरियां मान लेना बेहतर होगा। तब boring लेकिन अनुभवी engineers कंपनियों पर दबाव डाल सकेंगे कि अगर वे सच में हमारा श्रम चाहती हैं तो तरीका बदलें
जो कंपनियां नहीं बदलतीं, उनसे उस role को “offer” करने वाली कंपनी कैसी है, इसका अंदाजा लगाया जा सकता है
यह देखने के लिए code देखा कि reviewer इसे कैसे देखेगा
पहली खोली गई file में यहां तक देखकर ही मैं रुक गया होता: https://github.com/Sleepful/mymail/blob/main/app/router/page...
पहला comment काम से असंबंधित और बहुत अजीब है, और ऐसा लगता है जैसे किसी blog example से copy किया गया हो। किसी भी हालत में उसे वैसे ही छोड़ देना attention की कमी है
दूसरी line की phrasing तीसरी line से consistent नहीं है
मैं review यहीं रोक देता। यह details पर ध्यान की कमी है, और साफ सोचने की क्षमता नहीं दिखाता
लेकिन वापस आया सिर्फ एक खाली rejection email
उस स्थिति में यह कहना कि मुझे code comments पर और समय लगाना चाहिए था, इससे सहमत होना मुश्किल है
एक engineering interviewer के तौर पर कहना चाहूंगा। मुझे न LeetCode पसंद है, न take-home assignment। दोनों में बहुत समय लगता है और signal कम मिलता है
फिर भी इस मामले में लेखक को reject करने की संभावना ज्यादा थी। Kagi Search एक startup है, और ऐसी जगहें आम तौर पर तेजी से आगे बढ़ने वाले व्यावहारिक आशावादी और depth-बreadth का संतुलन बना सकने वाले लोगों को ढूंढती हैं
पहले मेरा एक colleague था जिसने inputs इकट्ठे किए, कई दिनों तक कमरे में बंद होकर solution बनाया और जब बाहर आया तो इस बीच requirements बदल चुकी थीं। यह किसी के लिए भी सुखद अनुभव नहीं था
मुझे take-home process सच में बहुत नापसंद है
“यह project सिर्फ coding ही नहीं, ambiguity और open-ended problems से निपटने की क्षमता भी test करता है” जैसी लाइन असल में ऐसा लगती है मानो a) assignment इतना खराब design किया गया है कि evaluation rubric भी नहीं बनाया गया, या b) work environment इतना अव्यवस्थित है कि कोई specification या requirement साफ-साफ define ही नहीं की जाती
ऊपर से “अपनी technical skills दिखाइए” और “practical और functional solution दीजिए” जैसी instructions आपस में टकराती हैं। अच्छा simple solution चमकदार नहीं होता
आप HTTP request बना सकते हैं और basic CRUD edit screen बना सकते हैं, यह लगभग कुछ भी नहीं बताता। AI tools भी ऐसी चीजें जल्दी और काफी ठीक quality में बना देते हैं
मैं यह देखना चाहता हूं कि engineer awkward business logic को कैसे implement करता है
क्या वह लाखों nested if और “यहां ड्रैगन हैं” comments बन जाता है, या सही patterns खोजकर ऐसा code लिखता है जिसे पढ़ा और reason किया जा सके
असली काम में यह कहीं ज्यादा valuable है, interview signal भी मजबूत है, AI के लिए सही करना भी ज्यादा मुश्किल है, और time भी कम लगता है
अच्छा simple solution बनाना ही शायद skill दिखाने का तरीका हो सकता है
मेरे हिसाब से यह senior software engineer की बड़ी जिम्मेदारी है
यह format उसे test करने का best तरीका नहीं हो सकता, लेकिन “हम देखेंगे कि आप ambiguity handle कर सकते हैं या नहीं” का मतलब यह नहीं कि हर काम ambiguous है
इसका मतलब यह हो सकता है कि हर काम को “ambiguous requirements” से “clear specification” तक ले जाने की प्रक्रिया से गुजरना होगा