HackerRank के ओपन सोर्स ATS में एक ही रिज़्यूमे का स्कोर 90, 74 और 88 के बीच डगमगाया

 (danunparsed.com)
2 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक ही रिज़्यूमे और एक ही कमांड के साथ HackerRank के ओपन सोर्स ATS hiring-agent को बार-बार चलाने पर स्कोर 66 से 99 तक डगमगाया, और 85 के cutoff पर 65% रन में रिजेक्ट होने का नतीजा सामने आया
  • यह टूल PDF रिज़्यूमे को parse करता है और LLM को 6 बार कॉल करके बेसिक जानकारी, अनुभव, शिक्षा, स्किल्स, प्रोजेक्ट और अवॉर्ड्स को structured रूप में बदलता है, फिर GitHub जानकारी जोड़कर 100 अंक + 20 बोनस के आधार पर मूल्यांकन करता है
  • तकनीकी स्किल्स 100 में से 98 बार 8/10 के लगभग स्थिर रहे, लेकिन प्रोजेक्ट मूल्यांकन “architecture complexity की कमी” और “वास्तविक deployment दिखाता है” के बीच झूलता रहा, जिससे बड़ी अस्थिरता दिखी
  • डिफ़ॉल्ट मॉडल gemma3:4b में temperature 0.1 ही नहीं, temperature 0 पर भी non-determinism बना रहा, और Gemini पर बदलने के बाद भी 60 cutoff के आधार पर 28% rejection rate आया
  • अनुभव सेक्शन में सिर्फ एक internship वाला पुराना रिज़्यूमे भी 25/25 अंक ले गया, जिससे संकेत मिलता है कि LLM scoring उम्मीदवार की गुणवत्ता अलग करने के बजाय किस्मत-आधारित filtering बन सकती है

एक ही रिज़्यूमे को हर बार अलग स्कोर मिला

  • HackerRank के ओपन सोर्स ATS hiring-agent ने LinkedIn और Reddit पर ध्यान खींचने के बाद परीक्षण का विषय बना
  • पहले रन में स्कोर 90/100 था, और debug output हटाने के बाद उसी रिज़्यूमे और उसी कमांड से दोबारा चलाने पर 74/100 मिला
  • DEVELOPMENT_MODE बंद करके 100 बार दोहराने पर स्कोर रेंज 66 से 99 तक फैल गई
  • अगर कंपनी का पासिंग cutoff 85 हो, तो वही रिज़्यूमे भी 65% संभावना से रिजेक्ट हो सकता है

मूल्यांकन पाइपलाइन और स्कोरिंग संरचना

  • टूल PDF रिज़्यूमे को टेक्स्ट में parse करने के बाद LLM को कई बार कॉल करके उम्मीदवार की जानकारी को structured बनाता है
    • बेसिक जानकारी
    • अनुभव
    • शिक्षा
    • स्किल्स
    • प्रोजेक्ट
    • अवॉर्ड्स
  • यह GitHub प्रोफ़ाइल और शीर्ष repositories को scan करता है, फिर इस जानकारी को अतिरिक्त context के रूप में जोड़कर पूरे डेटा को एक साथ LLM evaluation में डालता है
  • डिफ़ॉल्ट मॉडल लोकल पर चलने वाला gemma3:4b है और temperature 0.1 पर सेट है
  • स्कोर 100 अंकों का है, और अधिकतम 20 अंकों का बोनस जोड़ा जाता है
    • ओपन सोर्स योगदान: 35 अंक
    • पर्सनल प्रोजेक्ट: 30 अंक
    • कार्य अनुभव: 25 अंक
    • तकनीकी स्किल्स: 10 अंक
    • startup अनुभव, portfolio site, तकनीकी ब्लॉग आदि: अधिकतम 20 बोनस अंक

कौन-से सेक्शन स्थिर रहे और कौन-से डगमगाए

  • तकनीकी स्किल्स 100 में से 98 रन में 8/10 रहे, यानी लगभग स्थिर
    • React जैसी तकनीक का होना checklist जैसा है, इसलिए LLM की subjective judgment की गुंजाइश कम है
  • इसके उलट प्रोजेक्ट सेक्शन में हर रन में निर्णय काफ़ी बदलता रहा
    • कुछ रन में प्रोजेक्ट को “architecture complexity की कमी” कहा गया
    • दूसरे रन में उसे “वास्तविक deployment दिखाता है” बताया गया
  • temperature 0.1 कम सेटिंग है, लेकिन इसे 0 करने पर भी समस्या गायब नहीं हुई
  • अक्टूबर 2025 में खोले गए GitHub issue में भी temperature 0 पर लगातार 6 रन में स्कोर 27, 34, 32, 34, 34, 30 रहे

मॉडल बदलने पर भी अस्थिरता बनी रही

  • क्योंकि gemma3:4b एक लोकल मॉडल है, इसलिए मॉडल के प्रभाव की भी जांच की गई
  • Gemini इस्तेमाल करने पर स्कोर वितरण 48 से 64 तक सिमट गया
  • लेकिन अगर cutoff 60 हो, तो उम्मीदवार अपने रिज़्यूमे की सामग्री से अलग 28% संभावना से रिजेक्ट हो सकता है
  • ओपन सोर्स स्कोर अधिक स्थिर हुआ, लेकिन प्रोजेक्ट स्कोर अब भी काफ़ी डगमगाता रहा

अनुभव स्कोर की उलटी समस्या: स्थिर, लेकिन बेकार

  • अनुभव सेक्शन में हर रन में 25/25 अंक मिले
  • सिर्फ एक internship वाले पुराने रिज़्यूमे को भी 25/25 मिला
  • evaluation prompt में Production सेक्शन सिर्फ दो पंक्तियों का है
    • work और volunteer सेक्शन से वास्तविक काम, internship और production अनुभव का विश्लेषण करें
    • founder, co-founder और शुरुआती startup engineer भूमिकाओं को अतिरिक्त consideration दें
  • 15 और 25 अंक के बीच फर्क करने के लिए कोई मानदंड, उदाहरण या baseline नहीं है
  • नतीजतन, एक junior engineer की internship, 10 साल के distributed systems अनुभव वाला principal engineer, और परीक्षण में इस्तेमाल किया गया रिज़्यूमे — सभी 25/25 पा सकते हैं

रिज़्यूमे screening में व्यावहारिक जोखिम

  • LLM से रिज़्यूमे को structured data में parse कराना या यह जांचना कि उम्मीदवार को Python आता है या नहीं, अपेक्षाकृत उपयुक्त उपयोग हो सकते हैं
  • लेकिन यह तय करना कि किसी उम्मीदवार का अनुभव 18 अंक का है या 24, vibe-check जैसे नतीजे पैदा करता है
  • ओपन सोर्स और प्रोजेक्ट को मिलाकर 65% वजन देना भी hiring judgment को विकृत कर सकता है
    • 30 साल के अनुभव के साथ S3 बनाने वाले engineer की तुलना में, 2 internships और एक ओपन सोर्स प्रोजेक्ट वाले उम्मीदवार को अधिक स्कोर मिल सकता है
    • GitHub पर दर्ज न हुए महत्वपूर्ण काम करने वाले engineer अपने आधे से ज़्यादा अंक खो सकते हैं
  • जिन engineers के पास रिज़्यूमे screening में AI टूल लागू करने का अधिकार है, उन्हें सावधान रहना चाहिए कि गुणवत्ता अलग न कर पाने वाला टूल सिर्फ उम्मीदवारों को छाँटने वाली मशीन न बन जाए

सुधार नोट

  • resume_evaluation_criteria.jinja टेम्पलेट की पहली पंक्ति में “Software Intern” लिखा है
  • यह वाक्यांश documented नहीं है और repository में कहीं और reference भी नहीं होता
  • इसी टेम्पलेट में आगे founder, co-founder और शुरुआती startup engineer भूमिकाओं के लिए बोनस भी दिया जाता है
  • स्पष्ट रूप से Senior SWE prompt डालकर दोबारा चलाने पर भी परिणाम वही रहे, और स्कोरिंग dimension job level से स्वतंत्र रूप से काम करता रहा

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • यह देखकर हैरानी होती है कि कितने लोग नहीं जानते कि LLM एक शुद्ध probabilistic process की तरह काम करता है, इसलिए ऐसी गहराई वाली पोस्ट देखकर अच्छा लगा
    मैं नौकरी ढूंढ रहा हूं, और शायद आजकल callbacks मिलना इतना मुश्किल इसी वजह से है। लगता है resume बस किसी LLM black hole में फेंक दिया जाता है, और असल में यह कैसे काम करता है, किसी को नहीं पता
    लेख में “temperature 0.1 — कम मान, इसलिए माना जाता है कि यह model को deterministic output की ओर ले जाता है” वाली व्याख्या सही नहीं है। temperature कोई determinism switch नहीं है, बल्कि sampling distribution को प्रभावित करने वाली value है; distribution बस ज्यादा नुकीला हो जाता है, लेकिन फिर भी distribution ही रहता है

    • सिद्धांत रूप में temperature 0 LLM को deterministic बना सकता है
      और सख्ती से कहें तो temperature 0 स्वयं मौजूद नहीं होता। गणितीय रूप से जैसे-जैसे temperature 0 के करीब जाता है, distribution और नुकीला होता जाता है, सबसे संभावित sample लगभग अनंत के करीब चला जाता है और बाकी लगभग 0 के करीब
      वास्तविक implementations में temperature=0 पर 0 से अलग values के लिए इस्तेमाल होने वाला formula नहीं लगाया जाता; 0 से division से बचने के लिए if statement की अलग branch में सबसे common sample चुन लिया जाता है
      हालांकि batch processing या implementation-specific floating-point errors की वजह से probability distribution खुद हर run में अलग हो जाता है, और नतीजतन sample भी बदल जाता है
    • text understanding कुल मिलाकर uncertainty के तहत inference की समस्या है। लोग किस “witch” की बात कर रहे हैं, यह हमेशा पक्का नहीं कहा जा सकता, और कोई भी hiring process इस्तेमाल करें, hired व्यक्ति सफल भी हो सकता है और असफल भी
      एक ही resume को दो लोग देखकर एक ही निष्कर्ष पर पहुंच सकते हैं, और समान symptoms और clinical presentation वाले दो patients को अलग-अलग diseases भी हो सकती हैं
      पुरानी AI मुख्यतः knowledge base बनाए रखने की लागत के कारण खत्म हुई—यह explanation मुझे बहुत convincing नहीं लगती; मुझे लगता है असली मुद्दा uncertainty को संभालने वाली universal inference system की कमी थी
      Spock का हमेशा “Captain, इस mission में survival की probability 21% है” जैसी बातें कहना मुझे निजी तौर पर running joke जैसा लगता था। Bayesian नजरिए से probability distributions के ऊपर भी probability distributions होते हैं, इसलिए “इस mission में survival की संभावना β(5,1) है” कहना ज्यादा सही expression के करीब है
      उस लिहाज से resume को उस machine में 100 बार डालकर scores की probability distribution देखना भी इतना अजीब नहीं है
      [1] फिर भी, मैं उस तरह का पागल हूं जो बिस्तर पर लेटकर tablet पर images organize करता रहता है, जब तक visual system गड़बड़ा न जाए
    • स्पष्ट कर दूं: temperature 0 deterministic है, और बिल्कुल same input के लिए किसी भी seed selection पर same output देता है
      लेकिन अगर MoE है, तो duplicate input पूरे batch में भी identical होना चाहिए। batch neighbours expert selection को प्रभावित कर सकते हैं
      kernels deterministic होने चाहिए, और reasoning models में cluster-wide load जैसी चीजों पर react करने वाला system-level effort switch नहीं होना चाहिए
      निष्कर्ष यह है कि मौजूदा cloud infrastructure में temperature 0 भी शायद deterministic नहीं है, लेकिन edge inference में यह काफी स्थिर रूप से deterministic हो सकता है
      0.1 ज्यादा deterministic है—इस expression को मैं काफी reasonable summary मानता हूं। temperature 0.9 की तुलना में 0.1 पर “temperature 0 वाला जवाब” कहीं ज्यादा बार sample नहीं होता क्या?
    • मेरे कई self-proclaimed AI expert colleagues इसे gospel की तरह दोहराते हैं
      “consistent results पाने के लिए temperature को 0 पर set करो” यह बात मैंने अनगिनत बार सुनी है
    • जिस distribution में सारी probability mass एक ही result पर केंद्रित हो, वह deterministic होता है, इसलिए सिद्धांततः temperature को 0 पर set करने से deterministic output मिलना चाहिए
      ऐसा न होने के कुछ कारण हो सकते हैं, लेकिन जब लेखक की तरह local model चलाया जा रहा हो, तो मुझे नहीं लगता वे कारण लागू होते हैं

  • AI द्वारा बनाए गए code को AI के “पसंद” करने की प्रवृत्ति और दूसरे biases को जोड़ दें, तो यह तरीका EU में भेदभाव-रोधी कानून का कई तरीकों से उल्लंघन करते हुए बहुत हद तक गैरकानूनी हो सकता है
    resumes बहुत ज्यादा हैं, इसलिए उन्हें random तरीके से छांट देना आम तौर पर स्वीकार्य माना जा सकता है। लेकिन वह सचमुच random होना चाहिए, और resume की सामग्री से स्वतंत्र होना चाहिए
    AI में randomness वास्तविक resume मूल्यांकन से स्वतंत्र नहीं होती, इसलिए यह लागू नहीं होता
    आम तौर पर यह गारंटी नहीं दी जा सकती कि AI systematic bias लागू नहीं करता, और असल में ऐसा होने की संभावना के बड़े संकेत भी हैं
    इंसानों को bias को नजरअंदाज करने की training और निर्देश दिए जा सकते हैं। बेशक वह भी भरोसेमंद ढंग से काम नहीं करता, लेकिन कम से कम illegal bias की जिम्मेदारी उस recruiter पर चली जाती है जिसने निर्देशों का उल्लंघन किया
    इसके उलट AI के इस्तेमाल में, चाहे आपने क्या निर्देश दिए हों, जिम्मेदार user ही होता है। किसी खास context में कोई खास AI बहुत biased है, इसे तकनीकी रूप से “दिखाया या साबित” भी किया जा सकता है। इंसानी कर्मचारी के मामले में भी तकनीकी रूप से संभव है, लेकिन practical तौर पर यह लगभग मुश्किल नहीं होता
    आखिरकार legal risk “व्यक्तिगत और काफी हद तक नकारे जा सकने वाले” स्तर से systematically provable bias के क्षेत्र में चला जाता है। दूसरे शब्दों में, अगर लोगों को पता चल जाए कि hiring में AI इस्तेमाल हो रहा है, तो वे इसे कानूनी रूप से systematic तरीके से चुनौती दे सकते हैं

    • हर चीज का हर चीज से correlation होता है [1]
      यानी सिर्फ गणितीय रूप से देखें तो भी इसकी संभावना ज्यादा है कि यह अमेरिका में race, gender और दूसरे protected groups से किसी न किसी तरह correlate करेगा
      इसलिए अमेरिका में भी एक अच्छा lawsuit इसे illegal बना सकता है। जीतना जरूरी भी नहीं; बस court में पर्याप्त देर तक टिक जाना ही दूसरी companies को इसे इस्तेमाल करने से डराने के लिए काफी हो सकता है
      मैं ऐसा defendant नहीं बनना चाहूंगा जिसे साबित करना पड़े कि मेरा AI screener सभी hiring laws का पूरी तरह पालन करता है। यह किसी nightmare जैसा होगा
      [1]: https://gwern.net/everything
    • resumes को पूरी तरह random और सामग्री से स्वतंत्र तरीके से filter करना बिल्कुल समस्या नहीं है
      ढेर में से चौथा resume उठाकर उस व्यक्ति को job offer करना बेवकूफी है, लेकिन hiring decision लेने का पूरी तरह fair तरीका है
      लेकिन AI bias पकड़ने में बहुत अच्छा है, इसलिए अगर उसे resumes filter करने को कहा जाए, तो यह हैरानी की बात नहीं होगी कि वह candidate के नाम जैसी उन चीजों को आधार बना ले जिन्हें कभी criteria नहीं बनाना चाहिए
      हो सकता है जिन resumes में लिखा हो कि उन्होंने किसी बड़े open source project में typo ठीक किया, वे सभी pass हो जाएं, लेकिन सिर्फ अपने project लिखने वाले resumes 60% probability से reject हो जाएं। तब आप खराब candidates से ज्यादा अच्छे candidates खो देंगे
    • मुझे नहीं पता कि यह साबित करना इतना आसान होगा कि यह Council Directive 2000/78/EC जैसी employment से जुड़ी non-discrimination requirements का उल्लंघन है
      मैं मानता हूं कि यह एक irrational gambling machine की तरह काम करता है, इसलिए इसके अनचाहे indirect discrimination effects हो सकते हैं। लेकिन शायद यह दिखाना आसान नहीं होगा कि यह “धर्म या विश्वास, disability, उम्र, sexual orientation” के आधार पर भेदभाव करता है। संभव है, लेकिन lawyers को court में साबित करने के लिए काफी काम करना पड़ेगा
      ज्यादा दिलचस्प हिस्सा EU AI Act है। यह हिस्सा 2 दिसंबर 2027 तक अभी लागू नहीं हुआ है, लेकिन hiring या natural persons के selection में इस्तेमाल होने वाले AI systems, खासकर targeted job ads की placement, applications के analysis/filtering और candidates के evaluation में इस्तेमाल होने वाले systems स्पष्ट रूप से high-risk AI systems हैं
      इसका मतलब यह नहीं कि वे banned हैं, लेकिन बाद में LLM को high-risk AI use cases से बाहर रखा जा सकता है। क्योंकि वे बिना exception Article 6 के दायरे में आ सकते हैं
      जब standards अभी प्रकाशित नहीं हुए हैं, मुझे बिल्कुल समझ नहीं आता कि ऐसे कामों में LLM इस्तेमाल करते समय Article 10 के नीचे दिए हिस्से का compliance कैसे कराया जाएगा
      “(f) ऐसे bias की जांच करना जो लोगों के health और safety को प्रभावित कर सकते हों, fundamental rights पर नकारात्मक असर डाल सकते हों, या EU law के तहत प्रतिबंधित discrimination तक ले जा सकते हों। खासकर जब data outputs भविष्य के operations के input को प्रभावित करते हों
      (g) (f) के अनुसार पहचाने गए संभावित bias को detect, prevent और mitigate करने के लिए उपयुक्त measures”
      फिलहाल मुझे लगता है कि model provider पूरी तरह सहयोग करे तब भी सामान्य LLMs के साथ यह technically impossible है। छोटे models का meaningful audit शायद संभव हो
      EU AI Act अंततः Annex III के high-risk use cases में “LLM इस्तेमाल तो कर रहे हैं, लेकिन क्यों कर रहे हैं यह ठीक से नहीं पता” वाले vibe coding approach को पूरी तरह बाहर कर सकता है, और यह उचित लगता है
      https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
    • GDPR Article 22 के तहत यह आम तौर पर illegal है
      “data subject को यह अधिकार है कि profiling सहित केवल automated processing पर आधारित ऐसे decision का subject न बने, जिससे उसके लिए legal effects पैदा हों या उस पर इसी तरह significant effect पड़े”
      22(2) के exceptions लागू होना मुश्किल है। यह दावा करना मुश्किल है कि यह सचमुच necessary है, और employment context में consent भी लगभग成立 नहीं होता। अगर EU या member state का कोई specific law अनुमति देता हो तो संभव है, लेकिन अलग legal basis चाहिए

  • इस point पर “मैं unlucky व्यक्ति को hire नहीं करना चाहता, इसलिए आंखें बंद करके आधे resumes फेंक देता हूं” वाला joke बस अपना लिया जाए तो भी चलेगा

    • पहले UK के प्रमुख medical schools में से एक Barts and The London School of Medicine and Dentistry, यानी Queen Mary University of London के एक हिस्से ने qualified applicants के लिए random selection शुरू किया था
      यह तरीका उस समय की manual resume evaluation criteria को game करने की क्षमता रखने वाले students की तुलना में कम affluent backgrounds से आए qualified students के लिए ज्यादा फायदेमंद था
      “क्या आप future doctors को gambling से चुनेंगे?” जैसी organized campaign चली, और आखिरकार lottery system चुपचाप खत्म कर दिया गया
    • किसी व्यक्ति की जिंदगी भर की luck की कुल मात्रा स्थिर होती है
      बचे हुए आधे candidates इस selection में पहले ही अपनी कुछ luck खर्च कर चुके हैं, इसलिए औसतन वे फेंके गए आधे candidates से कम lucky होंगे
    • ज्यादा मूल बात यह है कि आम तौर पर positions की तुलना में qualified applicants बहुत ज्यादा होते हैं
      पिछले कई दशकों में training और education बहुत बढ़े, job seekers लगातार बढ़े, लेकिन job creation उस रफ्तार से नहीं बढ़ पाया
    • LLM resume screening किसी बड़ी समस्या का symptom हो सकता है
      अगर एक vacancy पर दर्जनों candidates आ जाते हैं, तो employer resumes को खराब तरीके से screen करे या आधे फेंक दे, फिर भी वह qualified व्यक्ति को hire कर सकता है

  • “मैं 65% संभावना से रिजेक्ट हो जाता हूँ। बिल्कुल वही रिज्यूमे, अलग किस्मत” वाला नतीजा, पिछले कुछ सालों में टेक रोल्स की hiring pipeline चलाने के अनुभव से देखें तो असल में एक शानदार नंबर है
    यह कहना मुझे objectively पसंद नहीं है, लेकिन सच यही है
    बिना मेहनत के टेक talent को अगले चरण में भेजने की 35% संभावना? domain-specific screening questions लगाने के बाद भी मैंने घंटे में 100 से ज्यादा applicants देखे हैं। तब इसका मतलब हुआ एक घंटे में 35 “screened” candidates
    क्या valid candidates छंट गए? हाँ। फिर भी क्या आपके पास जरूरत से 35 गुना बड़ा candidate pool रह जाता है? दुर्भाग्य से, यह भी हाँ
    applicants इतने ज्यादा हैं कि AI के बिना अगले चरण तक पहुँचने की संभावना उल्टा काफी कम हो जाती है। अगर आपने तुरंत apply नहीं किया, और वह भी AI bot से apply नहीं किया, तो आपके आगे 50 से ज्यादा लोग हैं और किसी थके हुए tech lead को कभी न कभी आपके रिज्यूमे तक पहुँचना होगा
    referral bonus मौजूद होने की वजह होती है

    • तो मेरे पास बेचने के लिए एक pre-screening system है
      latest technology के जरिए सिर्फ top* 1% applications को pass करता है
      *हमारे proprietary, private और non-deterministic metrics के आधार पर, जो Math.random भी हो सकता है और नहीं भी
    • क्या सच में ऐसा है? या फिर किसी इंसान के देखने से पहले ही रिज्यूमे के ignore हो जाने की संभावना 65% है, इसलिए hiring pipeline की qualified candidate पकड़ने की संभावना भी उतनी ही घट जाती है?
      रिज्यूमे inflow कम करने वाला gate तभी उपयोगी है जब वह कमी quality से correlated हो। वरना यह hiring process को बस लंबा खींचता है, या आखिर में hiring bar को बेवजह नीचे लाने पर मजबूर करता है
    • logical उपाय यह है कि candidate contact info थोड़ा-थोड़ा बदलकर कई बार apply करे
      जैसे “John Schmidt”, “John J. Schmidt”, “John J. J. Schmidt”, “John Jacob J. Schmidt”, “J. J. Jingleheimer Schmidt”
    • अगर accuracy requirement नहीं है तो applicants के 35% को random तरीके से अगले चरण में भेज देना चाहिए
      अगर पहले apply करने वाले 50 लोग सभी bots हैं, तो रिज्यूमे application order में क्यों पढ़े जा रहे हैं?

  • ज्यादा चिंता की बात यह है कि अगर दूसरे systems भी इस ATS की तरह काम करते हैं, तो वे काफी ठीक-ठाक या अच्छे candidates को बड़े पैमाने पर reject करने वाले factors के आधार पर judge करते लगते हैं
    उदाहरण के लिए personal projects और open source contributions के combination को 65 points दिए गए हैं। अगर tech ही आपकी एकमात्र दिलचस्पी है और आपके पास family, dependents, दूसरी या तीसरी नौकरी नहीं है, तो यह अच्छा हो सकता है
    लेकिन इनमें से कुछ भी हो तो odds बहुत ज्यादा आपके खिलाफ लगते हैं
    सोचता हूँ कि ऐसे systems कितनी हद तक अमीर लोगों के पक्ष में design हैं, जिनके पास college जाने या अपनी पसंद की industry में सिर्फ एक नौकरी करने के अलावा कोई चिंता नहीं होती और जो tech पर लगभग special-interest level तक obsess कर सकते हैं

    • personal projects और open source projects को overvalue करना चिंताजनक और खराब है
      खुद को उदाहरण के तौर पर लूँ तो, कंपनी के बाहर मैं personal projects लगभग नहीं करता। मेरी वास्तविक programming career पूरी की पूरी work hours में employers के लिए किए गए काम से बनी है
      मेरे hobbies 3D printing, hardware/Arduino, photography जैसे tech-adjacent क्षेत्रों में हैं, लेकिन GitHub पर ढेर सारे projects बनाकर डालने वाली चीज नहीं
      potential employers को दिखाने के लिए fake CRUD या SaaS app बनाना भी मैं कभी नहीं करूँगा। यह समय की बर्बादी है
      मैंने जानबूझकर ऐसा कोई online presence बिल्कुल नहीं बनाया। मेरे GitHub में public repositories नहीं हैं, और मैं blog भी नहीं करता
      यह trend मेरे operations/system administration वाले काम तक भी फैल गया है, और वहाँ तो और भी ज्यादा है। जाहिर है मैंने अपने GitHub पर environment-specific scripts का ढेर नहीं डाल रखा, और डालूँ भी क्यों? मेरी मौजूदा कंपनी के मेरे department में काम न करने वाले किसी व्यक्ति के लिए उनका कोई मतलब नहीं है

  • determinism शब्द का ऑनलाइन लिखाई को छूते ही बिगाड़ देने वाला कोई जादुई असर है
    वह शब्द सुनते ही लगभग guarantee है कि बात गलत दिशा में जाएगी। फिर भी इस बार सच में same input तो same output वाली वास्तविक determinism की बात हो रही है, किसी बेकार असंबंधित चीज की नहीं
    determinism reproducibility के लिए अहम है, लेकिन इस मामले में क्या आप सच में चाहते हैं कि output reproduce हो? LLM output को deterministic बनाना अपेक्षाकृत मामूली है। batching इस्तेमाल कर रहे हों तो batch-invariant kernels इस्तेमाल करें, temperature को 0 पर set करें—या ऐसा न करें क्योंकि random sampling की वजह होती है—और बेहतर यह है कि seed fix कर दें। कुछ systems में यह पहले से संभव है
    लेकिन इससे result ज्यादा useful नहीं होगा। यह सिर्फ इस तथ्य को छिपाएगा कि agent असल में sure नहीं है। score range देखिए। वह अब भी कुछ predict नहीं करेगा, बस हर बार score same हो जाएगा। क्या आप सच में यही चाहते हैं?
    यहाँ हो यह रहा है कि बहुत कम जानकारी दी जा रही है, लगभग noise-level का सिर्फ एक रिज्यूमे दिया जा रहा है, और उससे बहुत व्यापक implications वाला जवाब अपेक्षित है
    LLM इस्तेमाल हो या न हो, यह fundamental design mistake है। हर survey, exam, law, voting system बहुत कम information पर काम करता है इसलिए framing के प्रति बेहद sensitive होता है। फर्क बस इतना है कि वे, इस चीज के उलट, vacuum में exist नहीं करते

    • non-determinism का मतलब यह नहीं कि सही output तक reliably पहुँचना असंभव है। हाँ, कभी-कभी इसका मतलब ऐसा भी हो सकता है
      Las Vegas algorithms non-deterministic होते हैं लेकिन 100% correct होते हैं। इसके बदले सही जवाब तक पहुँचने के समय में बहुत ज्यादा variation का trade-off होता है
      यहाँ गलती non-deterministic system इस्तेमाल करना नहीं है। कुछ मायनों में गलती यह हो सकती है कि उसका बहुत कम इस्तेमाल किया गया। उसी रिज्यूमे को 5 बार फिर से evaluate करके score variance बड़ा है यह देखना, सिर्फ एक बार evaluate करने से ज्यादा useful signal है
    • यह बात मशहूर है कि human judges और examiners भी उतने deterministic नहीं होते जितना हम चाहते हैं
      lunch से ठीक पहले वाले घंटे में ज्यादा सख्त sentences सुनाए जाने की बात सबने सुनी होगी
    • non-determinism bug नहीं, feature भी है
      अगर आप नहीं चाहते कि लोग filtering process के हिसाब से optimize करें, तो उसे कुछ हद तक non-deterministic बनाना होगा
      उदाहरण के लिए top 100 पर सीधा cut लगाने के बजाय बेहतर candidate के filter pass करने की संभावना को exponentially बढ़ाना
      तब filtering process को Goodhart-style exploit करने की value कम हो जाती है। probability मुश्किल से बढ़ती है, और समय का बेहतर उपयोग करने की जगहें बहुत ज्यादा होती हैं

  • अगर default model gemma3:4b है, तो यह बहुत छोटा model है
    कोई भी LLM परफेक्ट और repeatable जज नहीं होगा, लेकिन ऐसे system में 4B model लगाना random number generator जोड़ने जैसा है
    पूरा experiment ऐसा लगता है जैसे किसी ने open source ATS project बनाना चाहा, vibe coding से ATS बनाया और फिर बस इतना tweak किया कि tests pass हो जाएँ

    • ऐसे models को सही तरीके से इस्तेमाल किया जाए तो छोटे problems के लिए ठीक हो सकते हैं
      इस model से भी resume analysis का कोई तरीका शायद ठीक से काम कर सकता है। लेकिन “अरे कबाड़, इस व्यक्ति ने कौन-सा project किया था?” जैसा तरीका नहीं
      extraction, organization, शायद OCR के जरिए comparison और extra cleanup, हर signal पर कई बार LLM analysis, judge वगैरह की जरूरत होगी
      इनमें से किसी के लिए भी बड़ा model होना जरूरी नहीं है। बड़ा model इस्तेमाल करने पर थोड़ा बेहतर हो सकता है, लेकिन context बहुत कम होने की वजह से सही तरीके से इस्तेमाल करने पर ऐसे models भी अच्छा काम कर सकते हैं

  • मैंने ATS खुद चलाकर देखा और लगभग वैसा ही अजीब अनुभव हुआ
    यह मेरा GitHub profile नहीं ढूँढ पाया, इसलिए score 70s में आया, और फिर इसे मेरी बनाई कुछ मशहूर Ruby libraries पसंद नहीं आईं
    कुछ बार चलाने के बाद यह उन्हें ठीक से पहचानने लगा, लेकिन formal education पर हमेशा points काटता रहा
    ऐसी चीज़ घिनौनी है

    • मेरा अनुभव भी मिलता-जुलता था। एक run में score करीब 65 आया, क्योंकि इसे यह बात पसंद नहीं आई कि open source contributions नहीं हैं
      certifications या awards भी यह पकड़ नहीं पाया। मैंने लोगों द्वारा सुझाए गए सुधारों वाले कुछ PR apply करके देखे (https://github.com/Zem-0/hiring-agent), और मदद तो हुई, लेकिन कुल मिलाकर यह ATS बड़े पैमाने के GitHub open source contributions वाले लोगों की तरफ काफी biased है

  • मुझे हमेशा हैरानी होती रही है कि अच्छी engineer talent मिलना मुश्किल है, इस वजह से tech companies $300k से ज्यादा pay करती हैं, लेकिन असल में recruiters बिना support के काम करते हैं और “अच्छे candidate” के criteria भी पूरी तरह अलग होते हैं
    ATS घटिया filtering heuristics की वजह से 50% से ज्यादा resumes को black hole में भेज देता है, hiring teams ने Google Gmail integration जैसी वजहों से ATS चुना होता है, और उस ATS की filtering technology को engineering team या data team में किसी ने review तक नहीं किया होता

  • मैंने अपने resume पर try किया तो somehow मुझे GSoC bonus points मिल गए
    BONUS POINTS: 5.0
    ------------------------------
    Google Summer of Code (GSoC) participation: +5
    लेकिन मैंने कभी GSoC किया ही नहीं, और resume में भी ऐसा नहीं लिखा