जॉब मार्केट में घबराहट

 (matt.sh)
1 पॉइंट द्वारा GN⁺ 2024-07-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • टेक जॉब मार्केट ब्याज दरों में बढ़ोतरी, VC फंडिंग में कमी, ग्राहक खर्च में सुस्ती, और standardized hiring process के एक साथ असर से डेवलपर्स के खिलाफ़ दिशा में बदल रहा है
  • कंपनी की फंडिंग, रेवेन्यू और growth stage के अनुसार compensation और stability अलग होती है, और high-interest-rate माहौल में VC पर निर्भरता ज़्यादा होने पर कंपनियाँ टूट जाती हैं या survival mode में सिमट जाती हैं
  • आधुनिक टेक hiring वास्तविक काम के अनुभव से ज़्यादा coding test और behavioral interview पर झुकी हुई है, और छोटे startup से लेकर बड़ी tech companies तक मिलती-जुलती प्रक्रियाएँ कॉपी कर रही हैं
  • “Everything Bagel” शैली के job post application development, infra, security, customer support, on-call, cost optimization और documentation तक कई विभागों का काम एक ही role में भर देते हैं
  • टेक roles, product और organization को साथ में बेहतर बनाने वाली भूमिका से बदलकर कम discretion वाले ऐसे worker role में जा रहे हैं जो सिर्फ़ दूसरों की priorities पूरी करता है, और skilled developers के अनुभव व judgment का ठीक से उपयोग नहीं होता

ब्याज दरों और टेक नौकरियों का संबंध

  • लगभग “free money” जैसे low-interest-rate दौर के ख़त्म होने और rates के 5% से ऊपर जाने के साथ यह आधार बन गया है कि पैसे की अपनी लागत अब महँगी हो चुकी है
  • जब ब्याज दरें ऊँची होती हैं, तो cash रखने वाले संगठन अनिश्चित कंपनियों में निवेश करने के बजाय सरकारी गारंटी वाले ब्याज उत्पादों जैसी सुरक्षित जगहों पर पैसा रख सकते हैं
  • टेक कंपनी में निवेश को अनिश्चित भविष्य की risk asset की तरह देखा जाता है, और high-interest-rate दौर में कमज़ोर कंपनियाँ गिरती हैं जबकि मज़बूत कंपनियाँ भी “clean house” के नाम पर कर्मचारियों की कटौती करती हैं
  • नतीजतन, यह देखने में आता है कि लाखों high-compensation tech workers को 2 से 4 साल तक कम नौकरियों वाले बाज़ार का सामना करना पड़ सकता है
  • बढ़ती ब्याज दरों के दौर में minimum wage वाली part-time या construction jobs बढ़ सकती हैं, लेकिन tech jobs कहीं अधिक VC funding और customer spending से जुड़ी होती हैं

कंपनी के प्रकार और compensation structure

  • टेक कंपनियों को फंडिंग और growth की स्थिति के आधार पर चार हिस्सों में बाँटा गया है
    • nepo company: ऐसी कंपनी जो परिवार, जान-पहचान या reality check से कटी हुई funding के सहारे अवास्तविक product बना सकती है
    • speculation company: ऐसी कंपनी जो product, customer या market validation के बिना ideas को आज़माने के लिए funding पाती है
    • initial growth company: ऐसी कंपनी जो शुरुआती demand आने के बाद growth capital लेकर revenue बढ़ाने की कोशिश करती है
    • stable era company: ऐसी स्थिर कंपनी जिसके पास repeatable go-to-market path, customer access और recurring revenue हो
  • high-interest-rate माहौल में कम सफल कंपनियाँ VC funding पर ज़्यादा निर्भर होती हैं, और funding flow धीमा पड़ने या रुकने पर वही सबसे ज़्यादा हिलती हैं
  • ग्राहकों के spending conditions भी सीमित होते हैं, इसलिए customer churn या spending cut एक साथ हो सकते हैं
  • speculation company को ऐसी जगह के रूप में दिखाया गया है जो market rate का 50–80% compensation देती है लेकिन 200–500% ज़्यादा काम की उम्मीद करती है
  • initial growth company high-risk, low-reward का मेल बन सकती है, और असफल growth companies कम compensation और बार-बार layoffs के साथ फँसी रह सकती हैं
  • stable era company को फिर तीन प्रकारों में बाँटा गया है
    • स्थिर रूप से बढ़ने और profit कमाने वाली कंपनी
    • प्रसिद्ध CEO के स्वभाव के अनुसार growth और contraction दोहराने वाली कंपनी
    • ऐसी कंपनी जो economy के एक या अधिक sectors पर क़ब्ज़ा रखती है और आसानी से नहीं टूटती
  • आधुनिक बड़ी growth companies annual stock compensation सहित skilled कर्मचारियों को प्रतिदिन 10,000 से 50,000 डॉलर के बराबर compensation दे सकती हैं, जबकि दूसरी कंपनियों में 10 साल तक real wage growth नहीं हो सकती या meaningful stock compensation नहीं होता

hiring process वास्तविक क्षमता को पहचान नहीं पाता

  • टेक hiring में तीन विरोधाभास बार-बार दिखते हैं
    • requirements ख़राब हैं
    • interview process ख़राब है
    • ज़्यादातर कंपनियाँ वही requirements और वही interview style अपनाती हैं
  • interviewers शायद ऐसे उम्मीदवार का भरोसेमंद आकलन न कर पाएं जो उनकी अपेक्षित answer से बेहतर answer दे दे
  • आधुनिक tech interview वास्तविक काम से असंबंधित तात्कालिक tasks करवाते हैं, और failure होने पर उम्मीदवार को कम क्षमता वाला मान लेते हैं, लेकिन अधिक उच्च स्तर के experienced candidates में फ़र्क नहीं कर पाते
  • Google-शैली के coding test और Amazon-शैली के behavioral interview पूरे industry में कॉपी किए गए हैं, और छोटे startup से लेकर बड़ी कंपनियों तक समान प्रक्रिया माँगी जाती है
  • behavioral interview “आपने conflict कैसे resolve किया”, “किस गलती के लिए माफ़ी माँगी” जैसे सवाल दोहराते हैं, और व्यवहार में इन्हें इस रूप में समझा जाता है कि उम्मीदवार progress और kindness के बीच संतुलन कैसे संभालता है
  • culture fit को सवाल-जवाब के फ़ॉर्मेट में code कर देने से कंपनी के औसत personality pattern से अलग लोगों को छाँटने वाली personality homogenization हो सकती है
  • जब कंपनियाँ interview rounds बढ़ाती जाती हैं और वे वास्तविक काम, अनुभव, क्षमता और insight से दूर होती जाती हैं, तो पूरा tech industry inefficient हो सकता है

“Everything Bagel” job post

  • “Everything Bagel” job post ऐसा फ़ॉर्म है जिसमें एक Software Development Engineer से एक साथ बहुत ज़्यादा ज़िम्मेदारियाँ माँगी जाती हैं
  • example requirements में ये शामिल हैं
    • React, Vue, TypeScript, Node, Python, Rust, Go आदि में application लिखना
    • PHP, Ruby, C-आधारित legacy applications की maintenance
    • AWS, Docker, Kubernetes, Terraform, Lambda, EventBridge, Step Functions आदि के साथ infra deploy करना
    • AWS cost optimization, CI/CD, 24/7 on-call, logs, monitoring, alerting और observability सुनिश्चित करना
    • application security, dependency security, SOC-2 से जुड़ी infra security
    • customer support, internal staff support, code review, mentoring, documentation
    • 37 JavaScript SaaS plugins और अतिरिक्त tracking scripts की maintenance
  • इस तरह की single-role requirement वास्तव में 5 departments और 20 लोगों के काम के क़रीब होती है
  • industry का एक हिस्सा मानता है कि technicians में specialization होनी चाहिए, इस विचार को छोड़ दिया गया है, और “devops means DEVS DO OPS” की तरह operations experience न रखने वाले developers पर भी ops डाल दिया जाता है
  • ऐसी संरचना में जहाँ application developer को part-time AWS architect भी बनना पड़े, अच्छे नतीजों की उम्मीद करना मुश्किल है, और यह भी माना गया है कि ऐसी क्षमता आम तौर पर 5 साल या उससे अधिक focused practice से बनती है
  • अत्यधिक requirements काम को शारीरिक रूप से असंभव बना देती हैं, और हर item अपने-आप में हफ़्ते के कई दिनों का काम हो सकता है, इसलिए joining के पहले दिन से ही backlog शुरू हो जाता है

field experience से दिखने वाली organization और infra समस्याएँ

  • कई कंपनियों ने कहा कि “site slow है”, लेकिन असल में basic AWS metrics और system management को न देखने की वजह से समस्याएँ पड़ी रहीं
  • एक कंपनी पूरी service को 2-core, 16GB RAM वाले एक MySQL पर चला रही थी, database 3TB तक बढ़ गया था, और CPU 99.99% की स्थिति 2 साल तक बनी रही
    • 64GB ARM server और reserved IOPS पर बदलने के बाद batch data conversion time 16 घंटे से घटकर 20 मिनट हो गया, और replication lag 4–6 हफ़्तों से बदलकर real-time sub-second स्तर पर आ गई
  • दूसरी कंपनी एक unused research cluster पर हर महीने 5,000 डॉलर खर्च कर रही थी, जबकि वास्तविक production cluster पर सिर्फ़ 500 डॉलर प्रति माह के resources इस्तेमाल हो रहे थे
    • resources को production cluster में लाकर और ARM पर switch करने से user response time 7 सेकंड से घटकर 200ms हो गया
  • एक कंपनी का internal data processing API ग्राहक web server के साथ वही 2-core EC2 की दो मशीनों पर चल रहा था, और batch processing में 20 घंटे लगते थे
    • ECS-on-EC2 आधारित auto-scaling containers में ले जाने के बाद 20–50 containers ने एक साथ processing की और समय घटकर 30 मिनट रह गया
  • एक कंपनी का MySQL से Redshift में data ले जाने वाला tool 80 घंटे लेता था, क्योंकि वह 3 अरब rows वाली table पर पहले SELECT COUNT(*) चलाता था और फिर LIMIT/OFFSET से पूरी table को traverse करता था
    • database cursor, S3 streaming writes और in-memory compression लाने से extraction time 80 घंटे से 40 मिनट रह गया
  • अगर “cloud native” होने के नाम पर system management और architecture experience को कमतर आँका जाए, तो समस्या पहचानने वाला भी कोई नहीं बचता, और वही समस्या लंबे समय तक पड़ी रह सकती है
  • ऐसे उदाहरण भी आते हैं जहाँ ग्राहक छोड़कर जा रहे होते हैं, फिर भी VC “और sales people” माँगता है, और ढाँचा 5 developers बनाम 50 sales-marketing staff का हो जाता है
  • अगर revenue गिरती कंपनी product pivot या improvement के बजाय पुराने idea और sales-first strategy पर अड़ी रहे, तो developers अपनी इच्छित product नहीं बना पाते और कंपनी failure की ओर जाती है

अनुभव और वास्तविक output को नज़रअंदाज़ करने वाला hiring market

  • यह धारणा मौजूद है कि tech hiring का तरीका 10–20 साल में “computer अच्छे से चला लेता है” जैसी साधारण जाँच से बदलकर social status और interview game-केंद्रित ढाँचे में बदल गया है
  • वास्तविक काम, अनुभव और क्षमता से ज़्यादा महत्व तुरंत problem solve करने और बोलकर दिखाने की प्रक्रिया को दिया जाता है
  • personal projects और वास्तविक outputs को भी interview evaluation में पर्याप्त महत्व नहीं दिया जाता
    • mpreg: distributed hierarchical topological sorting और automatic dependency resolution वाला data processing system
    • CRC processing improvement: ऐसा code जिसका ज़िक्र global file formats और space station information verification में उपयोग के रूप में किया गया है
    • icli: manual और automatic stock trading के लिए CLI
  • industry वास्तविक क्षमता से ज़्यादा social-political status और power के क़रीब चली गई है, और hiring को अधिक “us” बनाने की दिशा में जाना चाहिए — यही समस्या-बोध सामने रखा गया है
  • टेक roles में एक व्यक्ति पर बहुत चौड़ा काम डाल दिया जाता है, और साथ ही hiring में उसके वास्तविक अनुभव को पर्याप्त रूप से नहीं देखा जाता, जिससे job seeker के लिए टिके रहना कठिन हो जाता है

डेवलपर की discretion और product leadership

  • निष्कर्ष यह निकलता है कि tech industry की नौकरियाँ अत्यधिक speculative funding से जुड़ी थीं, और funding व customers दोनों घटने पर नौकरियाँ भी गायब हो गईं
  • कई tech roles ऐसी संरचना में बदल गए हैं जहाँ वे “software servant” की तरह non-technical product teams द्वारा तय tasks और priorities को सिर्फ़ execute करते हैं
  • Engineering-led management में काम करने वाला व्यक्ति ही product define करता है, users से बात करता है, requirements तय करता है और features implement करता है
  • कभी developer की भूमिका पूरे business perspective से problems solve करने की मानी जाती थी, लेकिन अब उसे दूसरों के ideas और priorities execute करने वाले project management worker के क़रीब देखा जाता है
  • एक ही role और effort के लिए किसी कंपनी में 400 डॉलर प्रतिदिन और दूसरी में 20,000 डॉलर प्रतिदिन तक compensation gap हो सकता है, और ऐसी तुलना job seekers की बेबसी बढ़ाती है
  • अच्छे product, अच्छे systems, और बढ़ती हुई products व economy बनाना ही वह दिशा है जिसकी ओर technologists को बढ़ना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2024-07-18
Hacker News की राय

  • यह सिर्फ software engineering या उससे जुड़े industries की समस्या नहीं है। यूरोप में मेरे जान-पहचान वाले भी finance से लेकर fashion तक बिल्कुल अलग-अलग industries में job switch या vertical/horizontal promotion की कोशिश कर रहे हैं, लेकिन काफी बुरी तरह असफल हो रहे हैं
    आजकल ज़्यादातर hiring व्यक्ति के अनुभव या उसके योगदान की संभावना को देखने के बजाय बस gate after gate पार करवाने जैसी हो गई है। Job portals पर डाली गई résumé pile के सबसे नीचे बैठ जाने वाली तलछट जैसी होती है, इसलिए जितना हो सके network और परिचितों का इस्तेमाल करना बेहतर है
    मुझे भी tech jobs में कमी का झटका लगा; एक software consulting company में जाने की कोशिश की, लेकिन 8 महीने bench पर रहा। आखिरकार छोड़कर corporate और tax valuation work में लौट आया। Underemployment ही सही, कुछ न होने से, खासकर mentally, बेहतर है
    मूल source में “आलसी बंदर की तरह इस केले पर फिसल गया” जैसा एक छोटा phrase भी है

    • “आजकल hiring में gates ही बहुत हैं और व्यक्ति के अनुभव या योगदान की संभावना को नहीं देखा जाता” — यही मुख्य बात है। पहले जब मैंने apply किया था, तो मुझसे “C++ या advanced graph algorithms का अनुभव है?” जैसे सवाल पूछे गए, जबकि मेरे profile या résumé में ऐसी कोई बात बिल्कुल नहीं थी
      फिर भी प्रतिक्रिया ऐसी थी मानो software और related experience के 10 साल अचानक अमान्य हो गए हों। जिसने कई languages सीखी और इस्तेमाल की हों, उसे सिर्फ इसलिए C++ बिल्कुल न कर पाने वाला मानना अजीब है कि उसने C++ को implicit तौर पर थोड़ा ही इस्तेमाल किया है
      एक company ने job post में लिखा था कि Python experience की ज़रूरत नहीं है, लेकिन पहली phone interview में low-level Python implementation questions की बौछार कर दी। अगर ऐसा ही करना है तो interview लेने का मतलब समझ नहीं आता; यह सबके समय की बर्बादी है
      अंत में, companies को hiring करना बिल्कुल नहीं आता, और इसी वजह से mentoring और training भी नहीं आती। हालांकि candidate के नजरिए से यह एक natural filter भी बन जाता है, क्योंकि जो जगह hiring नहीं कर सकती, उसके काम करने के लिए अच्छी जगह होने की संभावना कम है
    • पिछले कुछ सालों से मैं computer science graduates को mentor कर रहा हूं, और कभी-कभी interview process में कुछ companies बहुत ज़्यादा बड़े assignments मांगती हैं, जैसे पूरा app या website बनाना। ऐसे मामलों में मैं उन्हें मना करने की सलाह देता हूं, लेकिन असल में यह rare ही है
      लोग अक्सर complain करते हैं कि interview process बहुत लंबा है, लेकिन detail में सुनने पर आम तौर पर यह कुल 4–5 घंटे का होता है। कुछ साल पहले छोटे interview से ही लोगों को hire कर लेने वाले दौर के standards ने expectations को distort कर दिया, और उस समय join करने वाले young engineers को अब किसी भी मात्रा का interview unreasonable लगता है
      Reddit पर सभी assignments ठुकराने को कहा जाता है, इसलिए अक्सर मुझे लोगों को समझाना पड़ता है कि 60 मिनट से कम के simple assignment को भी reject न करें। कई महीनों से unemployed होने के बावजूद, न्यूनतम time investment से application आगे बढ़ाने वाले assignment को फिर “बहादुरी” से ठुकराते देखना frustrating है
      एक और समस्या वे लोग हैं जो किसी एक company से reply आते ही job search रोक देते हैं। उन्हें बार-बार बताना पड़ता है कि job search sequential processing नहीं, बल्कि parallel processing है। अगर आप एक slow company के साथ interview करके महीनों तक जवाब का इंतज़ार करते हैं, तो यह candidate के लिए बहुत नुकसानदेह है
      जरूरत से ज्यादा लंबे interview loops निश्चित रूप से मौजूद हैं, लेकिन average case internet पर पढ़ी जाने वाली बातों जितना खराब नहीं लगता
    • Title वाली तरफ यह कुछ हद तक काम कर गया लगता है, लेकिन Minions वाले हिस्से में उतना कामयाब नहीं हुआ
      Example output ने “Panic! at the Tech Job Market” को summarize करने के नाम पर LIKE SLUGS THROUGH THE HOURGLASS, THESE ARE THE DAYS OF OUR TECH TRIUMPHS जैसा phrase बनाया, और interest rates, tech hiring, company types को organize किया, लेकिन Minions instruction पर ठीक से respond नहीं किया लगता है
    • European Union किसी हद तक recession में है, और interest rates और unemployment rate का connection भी well-known है। ECB द्वारा rates बढ़ाने के बाद यूरोप में job पाना मुश्किल हुआ, यह चौंकाने वाला नहीं है। अच्छी बात है कि अब rates घटाए जा रहे हैं
      असली explanation यह चाहिए कि जब अमेरिका का overall job market कई सालों तक असाधारण रूप से मजबूत रहा, तब सिर्फ US tech industry ने layoffs और hiring freezes क्यों झेले। जवाब interest rates जैसा दिखता है, लेकिन यह ठीक से समझाना होगा कि tech industry travel और leisure जैसी industries से ज्यादा प्रभावित क्यों हुई
      निजी तौर पर मुझे लगता है कि interest rates peripheral role निभाते हैं, लेकिन लेखक ने February 2020 को tech hiring का reference point बनाया, यह अच्छा नहीं था। January 2020 और उससे पहले का समय अपेक्षाकृत normal था, लेकिन pandemic ने tech hiring को तेज़ी से बढ़ा दिया और chart 70 से 220 तक पहुंच गया
      अगर 3 साल की hiring 1 साल में कर दी जाए, तो कभी न कभी रुकना ही पड़ता है, और rate hikes उस रुकने का signal बन गए। यह उस समय से भी overlap करता है जब लगभग बाकी सभी industries government orders के कारण furlough जैसी स्थिति में थीं, इसलिए यह भी समझ आता है कि 2024 में tech industry बाकी industries से अलग क्यों दिखती है
    • मूल source का phrase मजेदार था, इसलिए मैंने देखा कि ChatGPT instructions follow करता है या नहीं, और उससे page summarize कराया। उसने basic income पर एक छोटा paragraph दे दिया। लेकिन मूल text में ऐसा कुछ था ही नहीं
      जब पूछा कि यह गलत क्यों है, तो पहले कहा कि अभी summarize किया है, फिर जवाब दिया कि असल में वह webpage summarize नहीं कर सकता। मैंने कहा कि यह बात logically ठीक नहीं है, तो message delete हो गया और ChatGPT content policy violation का notification आ गया
      यानी आखिरकार computer ने एक बार झूठ बोला, फिर दोबारा झूठ बोला, और फिर इस प्रतिक्रिया से computer नाराज न हो जाए इसलिए censor कर दिया गया। लोग इस कचरे को कैसे इस्तेमाल करते हैं, समझ नहीं आता
      Gemini से करने पर interest rates और layoffs का summary मिला, और वह expected result के ज्यादा करीब था

  • कभी-कभी यह सोचकर उदास हो जाता/जाती हूँ कि मुझे Google के compensation के आधे से भी कम मिलता है, लेकिन आँख खोलते ही दिखता है कि मेरी बेटी के किंडरगार्टन के शिक्षक 30 छोटे बच्चों की देखभाल करते हुए मेरी कमाई के आधे से भी कम पर काम कर रहे हैं। नर्सें और डॉक्टर ऐसे हालात में काम करते हैं जिनमें कुछ महीने टिकना भी मुश्किल हो, और सुपरमार्केट·पेट्रोल पंप·पुलिस·फायर सर्विस·सोशल वर्क·शिक्षक भी ऐसे ही हैं
    इसलिए समझ नहीं आता कि हमें किस बात की शिकायत करनी चाहिए। 3 लोगों वाले startup का “कम” compensation हो या कुछ भी, हम दिन भर code puzzles हल करते हैं और उसके बदले बहुत पैसा पाते हैं
    Google में काम करने वाले दोस्त से तुलना बंद करके, शांत और खुश मन बनाना सीखना बेहतर है

    • एक Xoogler के तौर पर कहूँ तो Google अब पहले जैसा नहीं रहा। ऊँची salary की कीमत में, आपको यह सहना पड़ता है कि जिन अधिकतर लोगों के साथ आप काम करते हैं, वे Google से और कितना पैसा निकाल सकते हैं, इसी में रुचि रखते हैं
      छोटे बच्चों की देखभाल करना, मिली हुई एक ही जिंदगी बिताने के लिए ऊपर से भी बेहतर दिशा लगता है
    • कभी-कभी यकीन करना मुश्किल होता है कि इतने कम input से इतना पैसा कमाना नैतिक है या नहीं। Work from home के दौरान पत्नी के साथ कस्बा घूम रहा था, तभी 360Kč के बिल पर 500Kč देने पर waitress यह सोचकर घबरा गई कि कितना change लौटाना है; वहीं मुझे तुरंत जवाब मिल गया
    • मेरे पिता स्कूल के caretaker के रूप में काम करते थे और हाल ही में retire हुए; उन्होंने कहा कि काम इतना इंसान को पीस देता था कि अब जाकर राहत मिली है। जीवनसाथी nurse है और नियमित रूप से काम पर जाने से डरता/डरती है। दूसरी ओर मुझे काम पर जाने से डर नहीं लगता, बल्कि लगता है कि मैं grow कर रहा/रही हूँ
      पैसे की जरूरत न भी हो तो भी शायद मैं यह काम जारी रखूँगा/रखूँगी। मैं वह कर सकता/सकती हूँ जो मुझे सच में पसंद है, अपनी skills से उपयोगी बन सकता/सकती हूँ और दूसरों को खुश कर सकता/सकती हूँ। ऊपर से मुझे पिता और जीवनसाथी से करीब 3 गुना मिलता है
      HN के बहुत से लोग bubble के अंदर हैं। बाहर की दुनिया कैसी है, उन्हें बिल्कुल पता नहीं। क्योंकि व्यवहार में उनके साथ राजघराने जैसा बर्ताव होता आया है। इंसान जहाँ भी हो, जो उसके पास है उसे छिनते नहीं देखना चाहता और पीछे नहीं हटना चाहता। भले ही उसने किसी और के अंतिम मुकाम से भी आगे से शुरुआत की हो
      क्या आपको लगता है programming बेकार है? क्या आपको लगता है कि technology की जरूरत वाले business नहीं हैं? बस आप ऐसी tech company में नहीं, जो ads बेचने के लिए addictive चीजें बनाती है, बल्कि ऐसे उपयोगी business में काम करेंगे जो सचमुच समाज में योगदान देते हैं
    • अभी कही गई हर बात पर शिकायत करनी चाहिए। पूरा system खराब है
      हर किसी को ऐसे भयानक हालात में न रहते हुए जीने का अधिकार होना चाहिए, लेकिन सामाजिक रूप से हम उन्हें बराबर नहीं मानते, इसलिए इसे होने देते रहते हैं। अगर व्यक्ति खुद somehow टिक सकता है, तो दूसरे लोग जो दर्द झेलते हैं उसे नजरअंदाज करना आसान हो जाता है
      अगर सब बेहतर जीवन जी सकें तो मैं खुशी-खुशी कम में रह लूँगा/लूँगी। असल में wealth accumulation का scale इतना बड़ा है कि इतना ज्यादा त्याग करना भी जरूरी नहीं। उस wealth को redistribute करना ही काफी होगा
      system की समस्या को individualistic समाधान से हल करने की कोशिश नहीं करनी चाहिए। हमारे छोटे bubble के बाहर हर कोई दुख झेल रहा है, ऐसे में शांत और खुश मन कैसे रख सकता/सकती हूँ, समझ नहीं आता
      “हमारा bubble दूसरे bubbles से कम खराब है, इसलिए खुश रहें” वाला रवैया त्रासदी है। याद रखना चाहिए कि हम सब एक ही नाव में हैं
    • चूँकि मैं games industry में काम करता/करती हूँ, लक्ष्य 300,000 डॉलर से ज्यादा total compensation पाना नहीं था
      लेकिन games industry में काम करने का मतलब यह भी है कि शुरू से ही “शांत और खुश मन” के विचार को कुछ हद तक छोड़ना पड़ता है

  • पहले मुझे लगता था कि coding interview रोजमर्रा के काम से बिल्कुल असंबंधित कोई initiation ritual है, लेकिन लंबे समय बाद job market में आए senior·staff-level engineer के रूप में अब अनिच्छा से इस ओर झुक रहा/रही हूँ कि शायद यह इतना बुरा भी नहीं है
    लगता है कि पिछले कुछ वर्षों में जमा की गई skills की वजह से मैं pass हो रहा/रही हूँ, और अगर ऐसा है तो coding interview कुछ हद तक signal पकड़ रहा हो सकता है। जितना senior होता/होती जा रहा/रही हूँ, coding interview पूरी तरह meaningless है, इस विचार से उतना दूर होता/होती जा रहा/रही हूँ

    • coding interview भी कई तरह के होते हैं। काम में सीधे लागू होने वाले basic सवाल पूछना, यह जाँचने के लिए basic knowledge filter करना कि candidate ने अपना experience झूठा नहीं बताया, thought process देखना और working code बनता है या नहीं देखना—ये ठीक हैं
      लेकिन रोजमर्रा के काम से कोई संबंध न रखने वाली बेहद कठिन पहेलियाँ सीमित समय में on the spot हल करवाना, और जवाब गलत या optimal न हो तो reject कर देना, यह सस्ते में काम कराने लायक freshers छाँटने की प्रक्रिया के ज्यादा करीब है
    • मेरे हिसाब से programmers दो तरह के होते हैं। वे लोग जो code लिखकर कुछ बना सकते हैं, और वे लोग जो कुछ बना भी सकते हैं और code writing की theory को बातचीत में समझाने जितने fluent भी होते हैं। दूसरा group पहले से 5 गुना ज्यादा उपयोगी है, और coding interview यह test करता है कि कौन किस group में है
      पहला group अक्सर सोचता है कि theoretical fluency महत्वपूर्ण नहीं है, लेकिन जब असली problem solve करनी होती है, तो दूसरा group ही चाहिए होता है। जो team सिर्फ code लिख सकती है लेकिन code के बारे में theorize नहीं कर सकती, वह बाद में किसी और को फिर से बनानी पड़े ऐसी कचरे की ढेरी खड़ी कर देती है
      बेशक कुछ लोग जल्दी theorize नहीं कर पाते, या दूसरों के सामने नहीं कर पाते, या high-pressure interview situation में नहीं कर पाते। ऐसे format वाले issues हल करने चाहिए। उलझे हुए trivia questions भी meaningless हैं
      फिर भी “coding tests रोजमर्रा के काम के लिए जरूरी skills test नहीं करते” वाला basic objection अजीब है। ये हर दिन इस्तेमाल होने वाली skills नहीं हैं, लेकिन जरूरत पड़ने पर निकालनी पड़ती हैं, और यही हर दिन के काम को सहारा देती हैं। जैसे mechanic हर दिन engine theory इस्तेमाल नहीं करता, लेकिन जो mechanic engine के काम करने का सिद्धांत नहीं जानता, उसे लंबे समय तक कार सौंपना नहीं चाहेंगे
    • मैं कभी समझ नहीं पाया/पाई कि लोग coding interview से इतनी नफरत क्यों करते हैं। employer के नजरिए से सिर्फ बातों से बने impression के बजाय actual ability कुछ हद तक verify करना स्वाभाविक है
      candidates से बहुत सारे बेतुके solutions देखे हैं। बहुत simple kata देकर console output बनाने वाला छोटा program ठीक से refactor करने और एक feature add करने को कहते हैं, लेकिन आधे लोग उसे काम करने लायक भी नहीं बना पाते। बहुत से लोग code की cleanliness पर बिल्कुल effort नहीं लगाते। माँग सिर्फ इतनी है कि उसे working बनाओ और अच्छा दिखाओ
    • पिछली बार interview देते हुए जब मैंने कुछ LeetCode problems solve किए, तो अधिकतर iterator implementation, folding operation, और जरूरत होने पर memoization जोड़ने के combination से मामूली तौर पर solve हो गए
      सारे problems ऐसे नहीं हैं, लेकिन easy·medium difficulty के ज्यादातर coding interview problems को ये तीन steps काफी general तरीके से cover करते लगते हैं। जब पहली job ढूँढ़ रहा/रही था/थी, तब मुझे ये चीजें बिल्कुल नहीं पता थीं, इसलिए समय के साथ coding interview problems आसान लगने लगे
      काम में Python ज्यादा इस्तेमाल नहीं किया था, लेकिन yield keyword LeetCode problems में लगभग cheat-code जैसा है
    • व्यक्तिगत रूप से senior·staff roles के coding rounds मेरे लिए आसान हो गए हैं। वही सवाल हो, तब भी interviewer का experience और वे जिस signal की तलाश करते हैं, वह अलग होता है, इसलिए वे problem solving, communication, testing वगैरह देखते हैं
      junior और “SDE II” level के coding rounds में यह toxicity होती है कि अभी-अभी promote हुए SDEs इसे candidate और खुद के बीच competition जैसा बना देते हैं। एक बार मैंने interviewer की सोच से भी simple solution दिया तो वह नाराज हो गया/गई था

  • लेख कुल मिलाकर अच्छा है, लेकिन लेखक मुआवजे के स्तर को बहुत ज़्यादा बढ़ा-चढ़ाकर देखता लगता है। एक जगह वह कहता है कि एक स्थिर, non-tech कंपनी—ट्रैक्टर बनाने वाली—रोज़ 5,000~10,000 डॉलर देती है
    अगर इसमें taxes शामिल मानकर इसे आधा कर दें, और केवल software कर्मचारियों पर ही लागू मानें, तब भी औसत compensation लगभग 10 लाख डॉलर सालाना बैठता है, जो समझ से बाहर है। अमेरिका में software engineer का औसत लगभग 135,000~150,000 डॉलर है, और इस औसत में सबसे ऊंचे compensation bracket वाले FAANG engineers भी शामिल हैं

    • पूरा लेख “interest rates बढ़ने पर venture capital funding घटती है” से बहुत आगे कुछ जोड़ता नहीं; यह काफी हद तक अतिशयोक्ति लगता है। benefits शामिल करने पर भी आंकड़े बहुत ज़्यादा फुलाए हुए हैं
      ऐसे स्तर का compensation पाने वाले लोग जरूर होते हैं, लेकिन जहां तक मैंने पहले सुना था, 10 लाख डॉलर+ annual total compensation Google के शुरुआती unicorn-level engineers को मिलने वाला स्तर था
    • रोज़ 5,000~10,000 डॉलर का मतलब, साल में 250 working days मानें तो 12.5 लाख~25 लाख डॉलर सालाना है। किसी tractor manufacturer में इतना मिलता है—इसका स्रोत क्या है, समझ नहीं आता
      शायद एक zero ज़्यादा लग जाने वाली typo रही होगी। रोज़ 500~1,000 डॉलर हो तो सालाना 125,000~250,000 डॉलर होता है और यह कहीं ज़्यादा believable है
    • शायद वह “पूरे career में actual working days से divide किया गया, stock की exponential growth को भी शामिल करने वाला per-day average compensation” जैसी calculation इस्तेमाल कर रहा है
      मूल लेख में लिखा है कि आधुनिक tech environment में स्थिर “hyperscale hypergrowth” कंपनियां अनुभवी लोगों को हर साल exponentially बढ़ती stock compensation value सहित रोज़ 10,000~50,000 डॉलर के बराबर देती हैं
      अगर salary 250,000 डॉलर है तो वह रोज़ करीब 1,000 डॉलर ही है, लेकिन अगर 40 साल के career में high-growth company stock compensation से 5 करोड़ डॉलर जमा हो सकते हैं, तो average रोज़ 5,000 डॉलर बनता है
      यह calculation कुछ संदिग्ध है और इसे ज्यादा स्पष्ट समझाना चाहिए था; assumptions अब भी काफी ambitious हैं, लेकिन लेख में जगह-जगह जो hints हैं उन्हें देखकर इरादा शायद यही लगता है
    • लेखक के resume में “available for employment” के नीचे Google L10 salary link और Amazon distinguished engineer है। इसलिए लगता है कि software engineer ladder में उसका expected compensation benchmark top 0.01% या उससे भी ऊपर है
    • यह बिल्कुल बेतुका है। market compensation की समझ नहीं है, और अगर expectations इतनी mismatch हैं तो hire न होना चौंकाने वाला नहीं है
      resume से भी दिखता है कि वह FAANG में अपने लिए सही level L10 मानता है। यह बेहद दुर्लभ level है, और उसके अनुभव के साथ उस level पर fit होने की संभावना 0% है
      पूरे लेख को बढ़ी-चढ़ी entitlement भावना के रूप में summarize किया जा सकता है
      https://matt.sh/files/a-resume/resume.html

  • यह लेखक आश्चर्यजनक स्तर की entitlement भावना के लिए जाना जाता है। Redis में कुछ मामूली योगदान करने के बाद उसने hostile takeover की कोशिश की थी
    इसे देखते हुए, अपनी expectations के मुताबिक job ढूंढने में उसका संघर्ष बहुत हैरान करने वाला नहीं है
    https://news.ycombinator.com/item?id=9176800

    • antirez ने कहा था कि “Redis codebase में महत्वपूर्ण योगदान देने वालों को एक हाथ की उंगलियों पर गिनें तो उंगलियां बच जाएंगी, और Matt Stancliff उनमें से एक है,” इसलिए लगता है कि उसने core योगदान जरूर किया था
      हालांकि जिस घटना का हवाला दिया गया है वह काफी पुरानी है और मौजूदा विषय से उसका संबंध कम है। entitlement की भावना ज्यादा होना थोड़ा असहज जरूर है
      https://groups.google.com/g/redis-db/c/PxFeA0fHgO4/m/zD4IWbXlMOgJ
    • लेख लंबा था, शुरुआत में मुझे सहानुभूति हुई, लेकिन कुछ सौ शब्दों के बाद यह “मेरा काम स्पष्ट रूप से पर्याप्त है, फिर इससे hiring क्यों नहीं हो रही?” वाली शिकायत जैसा लगने लगा। यह व्यापक job market के लिए evidence कम, और logical fallacy व थोड़ा बड़ा ego ज्यादा लगता है
    • अब लगता है कि उसमें कुछ self-awareness आ गई है। लेकिन conference में अजीब proposal देने के समय शायद ऐसा नहीं था
      लेख के ऊपर GitHub Sponsors link को देखकर लगता है कि उसे भरोसा है कि कोई न कोई 12,000 डॉलर प्रति माह की sponsorship के लिए sign up करेगा
    • वह योगदान मामूली नहीं था। आप क्या कह रहे हैं, समझ नहीं आता

  • जैसा कि कहते हैं, “अगर कोई चीज़ बेवकूफी भरी दिखे लेकिन काम करे, तो वह बेवकूफी नहीं है”; अगर वह अपनी पिछली नौकरियों की सभी समस्याएं देखने लायक स्मार्ट था और वे कंपनियां फिर भी डूब गईं, तो शायद वह अपने मन में जैसा ideal employee सोचता है, वैसा नहीं था। अगर वह सोचता है कि programming interviews उसके लिए बहुत low-level हैं और सिर्फ inferior लोग ही उन्हें pass करते हैं, लेकिन वह rent नहीं चुका पा रहा, तो शायद वे interviews इतने low-level नहीं हैं
    AWS knowledge से किसी query को 7 सेकंड से 40ms तक, या batch job को 40 घंटे से 20 मिनट तक घटा देना शायद ही किसी कंपनी की success और failure का फर्क बनता है। management dysfunction अक्सर वह फर्क बनाता है, लेकिन अगर वह सिर्फ cynical blog post material के रूप में याद रहे, तो वह hire किए जाने की वजह नहीं देता
    कंपनियां system management बेहतर करें, यह चाहना एक हद तक ठीक है, लेकिन database design और AWS cost cutting पर बहुत ज्यादा focus करने से आप McKinsey वाली दंतकथा के बीच वाले पत्थर तराशने वाले बन जाते हैं

    • क्या आपका मतलब है कि system administrator के रूप में उसे product, sales और marketing की समस्याएं भी solve करनी चाहिए थीं? किसी specific position में आप जो कर सकते हैं उसकी सीमा होती है। लोगों को यह बताने पर भी कि वे महंगी गलतियां कर रहे हैं, उन्हें convince करना सचमुच बहुत मुश्किल हो सकता है
      अगर marketing team काम बिगाड़ रही है, तो आप “marketing खराब है” कह सकते हैं, लेकिन सूचना देने से आगे ज्यादा कुछ करना कठिन है। चाहे कितनी भी diplomatic भाषा में कहें, अगर आप organization hierarchy में पर्याप्त ऊपर नहीं हैं तो engineering side से उसे ठीक करना मुश्किल होता है
      पहले एक बार CEO का दोस्त नए marketing head के रूप में आया था, और मैंने उसके marketing decisions पर शालीनता से चिंता जताई तो CEO ने मुझे डांट दिया। बाद में उस head ने brand खराब कर दिया और customers को confuse कर दिया
    • अगर वह सभी समस्याएं देखने लायक smart था और कंपनी फिर भी डूब गई, तो शायद वह उल्टा ideal employee ही था
      technical हो या non-technical, ज्यादातर roles में hiring managers ऐसे व्यक्ति को पसंद करते हैं जो “कूदो” कहने पर “कितना ऊंचा?” पूछे, न कि “नहीं” या “क्यों?” पूछे
      आपको काम अच्छी तरह करने जितना senior होना चाहिए, लेकिन इतना senior नहीं कि आपका boss खुद को junior महसूस करने लगे
    • यह प्यारी-सी व्याख्या है कि समस्या देखना और उसे हल करने का अधिकार मिलना हमेशा साथ-साथ आते हैं
      शायद आप लेख में बताए गए interviewers या employees में से ही किसी एक जैसे लगते हैं
    • McKinsey वाली दंतकथा क्या है, जानना चाहूंगा
    • उसकी भाषा और यह भाषा एक ही कपड़े से कटी हुई लगती हैं

  • अभी हालात सचमुच बहुत खराब हैं, लेकिन मेरी समझ में नए graduates और juniors सबसे ज्यादा तकलीफ झेल रहे हैं। industry मुनाफे वाली दिख रही थी, इसलिए बहुत लोग software engineering में आ गए, और computer science graduates जरूरत से ज्यादा निकल आए।
    startups को यह मनाना मुश्किल है कि वे बिना अनुभव वाले किसी व्यक्ति पर दांव लगाएँ, और mature companies भी 2 juniors की कीमत देने के बजाय 1.5 लोगों की कीमत पर 1 senior को रखकर उससे लगभग वही काम करवाना चाहती हैं। पहले C-grade companies में भी internship से full-time role तक जाने वाली pipeline होती थी, लेकिन अब यह कहीं ज्यादा दुर्लभ दिखती है।
    ब्याज दरें बढ़ने, investors के सिर्फ अभी trend में चल रही चीजें खोजने, और निकट भविष्य की अनिश्चितता की वजह से नए products/features और उनके लिए जरूरी engineers की growth पर निवेशकों को राजी करना और मुश्किल हो गया लगता है।
    पिछले कुछ सालों में बहुत से talented लोगों की छँटनी हुई है, इसलिए hiring में companies के पास बड़ा advantage है। उनमें से कई लोग बड़ी salary cut भी स्वीकार करने को तैयार हैं, तो average व्यक्ति को चुनने की वजह कम हो जाती है।

    • मेरे मामले में इसका ठीक उलटा था। पिछले 2 साल 2010s की शुरुआत के बाद से tech industry में काम करते हुए मेरे सबसे अच्छे साल रहे।
      2019 के आसपास मैं industry छोड़ने पर गंभीरता से सोच रहा था। पूरी industry LeetCode grind, total compensation chase, और साधारण drones में बदल गई थी। असली problems तो छोड़िए, challenging और interesting problems पर काम करने वाले लोग ढूँढना भी मुश्किल था, और जिन लोगों के साथ मैंने काम किया उन्हें programming या computer science में बिल्कुल दिलचस्पी नहीं थी।
      लेकिन पिछले 2 सालों में मैंने सचमुच शानदार काम करने वाली कई teams के साथ काम किया, और ऐसी teams भी मिलीं जिनमें सिर्फ जिद्दी और smart लोग थे। खासकर AI के आसपास की नई tricks और techniques इस्तेमाल करके projects बनाना शुरू किया।
      अब कठिन problems हल करने वाली बहुत-सी छोटी teams को funding मिल रही है, और interesting, talented और वाकई अजीब programmers फिर से मिलने लगे हैं। चीजें बनाना और problems solve करना पसंद करने वाले लोगों को फिर से काम मिल रहा है।
      महँगाई को ध्यान में रखें तो शायद लंबे समय में सबसे कम पैसा मिल रहा है, लेकिन आखिरकार काम फिर से मजेदार हो गया है। बनाने के जुनून वाले लोगों के साथ hacking कर सकता हूँ।
    • junior talent को hire करने वाली companies के नजरिए से, हाल में फैले 1–2 साल में job switch करने के trend की वजह से value proposition खास आकर्षक नहीं है। अगर training देने के बाद वे चले जाते हैं, या शुरुआत से ही experienced लोगों के स्तर की salary मांगते हैं, तो investment की value घट जाती है।
    • computer science graduates की अधिकता के बारे में नहीं पता, लेकिन कम-से-कम जिस तरह के junior engineer की मैं उम्मीद करता हूँ, उसकी अधिकता बिल्कुल नहीं दिखती।
      मेरे मानक वाला junior engineer वह है जो algorithms और data structures जानता हो, कम-से-कम एक programming language को सच में अच्छी तरह जानता हो, और उस language में छोटे programs जल्दी लिख सकता हो। उसके पास practical experience नहीं हो सकता, शायद उसने 10,000 lines से बड़े project पर काम न किया हो, और उसे CI/CD या Docker न आता हो, लेकिन coding तो आनी चाहिए।
      लेकिन junior interviews देने वाले ज्यादातर लोग coding नहीं कर पाते। जिस language को वे अपनी favorite बताते हैं, उसमें interview के दौरान 5 lines code भी नहीं लिख पाते। यह वैसा ही है जैसे खाना बनाना न जानते हुए junior chef के लिए apply करना, या drive करना न जानते हुए junior taxi driver के लिए apply करना।
      junior का मतलब “ज्ञान बहुत है, अनुभव नहीं है” होना चाहिए, लेकिन IT में अजीब तरह से बहुत लोग इसे “ज्ञान भी नहीं और अनुभव भी नहीं” मानते हैं।
      अगर कोई बताए कि ये जरूरत से ज्यादा निकले junior engineers कहाँ मिलते हैं, तो मैं खुशी से उन्हें hire करूँगा।
    • junior engineers के लिए मुश्किल बढ़ने की एक और वजह यह है कि पहले की तुलना में nearshore और offshore outsourcing बहुत ज्यादा हो गई है। Zoom वगैरह 10 साल पहले से कहीं बेहतर हो गए हैं और सब remote work के आदी हो गए हैं।
      मैंने Latin America और Eastern Europe के बेहतरीन engineers के साथ काम किया है, और आजकल यह US-based engineer के साथ काम करने जैसा ही लगभग है। English अच्छी है, working hours का overlap भी पर्याप्त है, और खासकर Latin America तो 2000s के mid वाले India outsourcing nightmare के बिल्कुल उलट है।
      वैसे भी लोगों के साथ 99% interaction Zoom या Meet पर होता है, इसलिए वे कहाँ हैं इससे बहुत फर्क नहीं पड़ता। इसलिए US junior developer को US salary देना मुश्किल हो जाता है। क्योंकि उसी amount या उससे कम में Latin America या Eastern Europe का बेहतरीन senior developer मिल सकता है।
    • पहले बात “2 juniors के बजाय 1.5 लोगों की कीमत वाला 1 senior” की थी, लेकिन अब यह ज्यादा “job posting ही हटा दो और existing seniors से और ज्यादा काम करवाओ। उन्हें पता है कि seniors के पास भी options नहीं हैं” जैसा है।
      जिन positions के लिए मैंने apply किया या interview दिया, वे कई बार cancel हुईं, और मेरे दो दोस्तों ने भी कहा कि उनकी companies में भी यही हो रहा है। एक मामले में 5 लोगों की team 2 लोगों की team बन गई है और airline की core service चला रही है।
      नए लोगों के लिए यह बुरा है, और शायद जितना लगता है उससे भी ज्यादा बुरा हो सकता है।

  • पिछले 15 सालों से मैं full-time लोगों, मुख्यतः engineers, को hire करने का काम कर रहा हूँ, और modern hiring पर Matt की काफी आलोचनाओं से मैं मजबूती से सहमत हूँ।
    ज्यादातर technical interviews का job performance से उतना ही कम संबंध है जितना baker hire करते समय यह पूछना कि electron orbitals gluten bonds कैसे बनाते हैं, और अगर वह तुरंत valid orbital configuration draw न कर पाए तो उसे reject कर देना।
    Matt की analogy contractor hiring जैसी transactional hiring पर तो अच्छी बैठती है, लेकिन उस स्थिति पर नहीं जहाँ दोनों तरफ यह expectation हो कि अगले कई साल साथ काम किया जाएगा। Engineers hire करने वाली companies को आम तौर पर लोगों से team में bread bake करवाना होता है, और वह team कभी-कभी बहुत बड़ी होती है।
    जब responsibilities धीरे-धीरे ज्यादा specialized हो जाती हैं, तो असल में कम-से-कम एक ऐसा baker चाहिए होता है जो valid orbital configuration draw कर सके। और अगर quantum mechanics में मजबूत baker मिल गया, तो अब यह भी check करना होगा कि वह साथ काम करने के लिए भयानक इंसान तो नहीं है।
    इसलिए referral hiring पहले भी king थी और आज भी है। कोई व्यक्ति काम में अच्छा है या नहीं, यह परखने का सबसे अच्छा test है उसके साथ कुछ साल काम करना।

    • referral hiring असल में लगभग कहीं मौजूद नहीं है।
      मैंने ऐसे लोगों को refer किया जिन्हें मैं सचमुच बेहतरीन software engineer जानता हूँ और जिनके लिए मैं अपनी नौकरी दांव पर लगाकर guarantee दे सकता हूँ, फिर भी उन्हें बाकी candidates से बिल्कुल अलग treat नहीं किया गया।
    • अब यही reality है। Bakers के interviews भी ऐसे ही होते हैं।
    • अगर आप top 1% tech company नहीं हैं, तो यह logic ठीक नहीं बैठता। हर tech company सोचती है कि उन्हें “सबसे अच्छी bread” बनानी है, इसलिए उन्हें सबसे अच्छा baker चाहिए।
      यह realistic नहीं है, लेकिन अगर investors ने millions of dollars खर्च करने के लिए दिए हैं, तो किसी तरह खर्च तो करने ही पड़ते हैं।
    • “orbital configuration draw कर सकने वाला baker चाहिए” जैसी सोच इस toxic hiring market में योगदान देती है।
      पूरी बात बस इतनी है कि applicants बहुत ज्यादा हैं और jobs बहुत कम। inflation, bread baking, interest rates, team building जैसी बातें सब entitlement के symptoms हैं।
      अगर applicants सिर्फ 2 होते, तो आप ऐसा नहीं सोचते।

  • इस लेख की नैपकिन वाली सारी गणनाएँ उलझाने वाली थीं
    “प्रति दिन” वाला आधार कहाँ से आया, समझ नहीं आया। यह executive compensation है या mid/senior engineer compensation, साफ़ नहीं है। रोज़ 5,000–10,000 डॉलर का मतलब सालाना 10 लाख–30 लाख डॉलर है; खासकर जिन सालों में stock बहुत चढ़े हों, तब यह संभव है, लेकिन लेख जैसा कहता है उतना आम नहीं है
    यह मानना भी मुश्किल है कि ऐसे आँकड़े “Google या Apple नहीं, बल्कि कई सालों से लगातार अच्छा प्रदर्शन कर रही किसी tractor company या heavy-industry company” से आते हैं। इन्हें hidden companies कहा गया है, लेकिन क्या कोई उदाहरण है, यह जानना चाहूँगा। आम तौर पर non-tech companies में software engineers cost center होते हैं, इसलिए compensation काफी कम होता है
    “अगर real inflation और cost of living हर साल 7–13% बढ़ता मानें” वाली footnote भी—पिछले 10 सालों में इतनी असाधारण inflation का दावा करना है तो गणना का आधार देना चाहिए

    • लेखक ने कहा है कि उसके पास 20+ साल का experience है, इसलिए लगता है कि वह दरअसल VP-level roles से तुलना कर रहा है। FAANG में मिले 40+ उम्र के कई लोग सच में senior staff या उससे ऊपर, या director और उससे ऊपर थे, इसलिए ये आँकड़े पहली नज़र जितने पागलपन भरे लगते हैं, उतने शायद न हों
      हालांकि उन आँकड़ों तक पहुँचने के लिए stock value appreciation को भी शामिल करना होगा। और मुझे लगता है कि FAANG में VP-level तक पहुँचने वालों की तुलना में पूरी तरह छोड़कर जाने वाले लोग कहीं ज़्यादा होते हैं

  • लेख में दबे हुए कुछ अच्छे points हो सकते हैं, लेकिन पढ़ते समय जो चीज़ महसूस होती है वह बहुत कम self-reflection वाला कड़वापन है। ऐसा व्यक्ति लगता है जिसके साथ काम करना मुश्किल हो और जो इसकी जिम्मेदारी दूसरों पर डाल दे

    • पढ़ना शुरू किया था, लेकिन शुरुआत से ही 1,15,000 शब्दों की शिकायत जैसी कड़वी tone महसूस हुई
      ऐसा लगा जैसे वह यह साबित करने के लिए कि वह exercise करता है, अपनी तस्वीर तक दिखाकर बार-बार बात दोहरा रहा है। हर किसी का अपना तरीका होता है, लेकिन लगा कि interview failures शायद skill issue नहीं, attitude issue भी हो सकते हैं
    • “मैं कभी coding interview पास नहीं कर पाया। coding interviews गलत लोगों को hire करते हैं!” जैसी जगह पर मैंने पढ़ना रोक दिया
    • समझ नहीं आया कि पूरे लेख में compensation ही अकेला consideration क्यों है। पैसा अच्छा है, लेकिन क्या यह भी महत्वपूर्ण नहीं कि आप क्या बना रहे हैं?
    • “Comparison सबसे खराब भावना है और happiness की मौत है। मैं अपनी स्थिति की तुलना उन लोगों से करता हूँ जो 20 साल पहले Apple या Microsoft में गए और कभी नहीं निकले” वाला quote समझ आता है
      लेकिन अगर आप इतने lucky हैं कि ऐसे लोगों को जानते हैं, तो क्या उन connections का इस्तेमाल career को मजबूत करने में नहीं किया जा सकता?
      कुछ लोग सही समय पर सही company में जाकर millions of dollars कमाते हैं, लेकिन अगर मेरी अगली job में मुझे 150,000 डॉलर मिलें, तो location के हिसाब से मैं काफी संतुष्ट रहूँगा। अच्छा होगा अगर remote work अभी भी widely available रहे, ताकि कम cost of living वाली जगह पर रहा जा सके
      हालांकि लेखक शायद 150,000 डॉलर को बड़ी रकम नहीं मानता, और article देखकर लगता है कि उसका experience और seniority मुझसे ज़्यादा है