असली engineer नहीं: ‘Not a real engineer’ (2019)

 (twitchard.github.io)
1 पॉइंट द्वारा GN⁺ 2023-12-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह छोटी गद्य-कविता “You are not a real engineer” की घोषणा से शुरू होती है और इंटरव्यू में अस्वीकृति की सूचना तथा पौराणिक राक्षस जैसी छवियों को एक ही संदर्भ में रखती है
  • विषय को इंसानी कद, शेर का सिर, सोलह पंख, सैकड़ों आंखें और सांप के आकार की कमरबंद वाले एक अतिंद्रिय अस्तित्व के रूप में चित्रित किया गया है
  • तूफानी बादलों जैसी सांस, हवा की गर्जना जैसी आवाज़, और घास को मुरझा देने वाले कदम उस अस्तित्व की भारी शक्ति को लगातार बढ़ाते हैं
  • अंत में “हम इस समय यह भूमिका ऑफर नहीं करेंगे” जैसी भर्ती-अस्वीकृति पंक्ति आती है, जिसके साथ “हम किसी अधिक तकनीकी व्यक्ति की तलाश में हैं” जैसा कारण जुड़ता है
  • एक विनाशकारी सत्ता तक को सिर्फ इसलिए ठुकरा दिया जाता है कि वह और अधिक तकनीकी व्यक्ति नहीं है, और यहीं “असली engineer” के मानदंड की बेतुकापन सामने आता है

पौराणिक अस्तित्व तक फैलता हुआ वर्णन

  • शुरुआती वाक्य “You are not a real engineer” है, जो सामने वाले से सीधे कहता है कि वह असली engineer नहीं है
  • इसके बाद वह पात्र इंसानी शरीर और शेर के सिर वाले अस्तित्व के रूप में फैलता है, जिसमें सोलह सफेद पंख और मशाल जैसी सैकड़ों आंखें हैं
  • उसकी कमर की पेटी सांप है, उसकी सांस तूफानी बादलों का जमाव है, और उसकी आवाज़ हवा की गर्जना के करीब है
  • उसके कदमों के आगे घास मुरझा जाती है, और अथाह गर्त जितनी काली जीभ जिस भी चीज़ को छूती है, उसे प्रलय दे जाती है

भर्ती-अस्वीकृति की पंक्ति से बनता उलटाव

  • समापन भारी-भरकम वर्णन से अचानक भर्ती प्रक्रिया की एक विनम्र अस्वीकृति पंक्ति में बदल जाता है
  • “हम इस समय यह भूमिका ऑफर नहीं करेंगे” के बाद “हम किसी अधिक तकनीकी व्यक्ति की तलाश में हैं” जैसा कारण आता है
  • पहले की पौराणिक छवियों और अंत की साधारण भर्ती-अस्वीकृति पंक्ति के टकराव से “असली engineer” जैसे वाक्यांश की खोखलापन उजागर होता है

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

1 टिप्पणियां

 
GN⁺ 2023-12-04
Hacker News की राय

  • इन दिनों मैंने यह सोचना छोड़ दिया है कि ऐसे पदों के लिए जीनियस-स्तर के इंजीनियर भर्ती किए जाएँ, जहाँ काम के समय का 80% CRUD applications बनाने में जाता है
    यह पैसे की बर्बादी है, talent pool की बर्बादी है, उम्मीदवार के लिए भी अच्छा नहीं है, और कंपनी के लिए लंबी अवधि का जोखिम भी बनता है। ऐसे लोग आखिरकार बोर हो जाते हैं और दिमाग चलाने के लिए चीज़ों को ज़रूरत से ज़्यादा design करना शुरू कर देते हैं
    ज़्यादातर engineers के लिए इतना काफ़ी है कि वे database और API स्तर पर create/update/delete/read operations ठीक से लिख सकें, frontend से API call कर सकें, और उचित error handling तथा ठीक-ठाक debugging approach रख सकें

    • मैं कई teams में hiring manager रह चुका हूँ, लेकिन बात इतनी सरल नहीं थी। यह सही है कि non-John Carmack स्तर के technical task के लिए John Carmack की ज़रूरत नहीं होती
      लेकिन मैंने ऐसे भी “ठीक-ठाक” programmers देखे हैं जो बस “चलता है” नतीजे देते हैं, और ऐसे बेहतर programmers भी देखे हैं जो 5 गुना तेज़ काम करते हैं बिना 5 गुना ज़्यादा देर तक काम किए, लगभग खुद को manage कर लेते हैं, QA को बार-बार यह देखने की ज़रूरत नहीं पड़ती कि बंद किया गया ticket सच में पूरा हुआ या नहीं, और समस्या आने पर Git repository सुलझाने के लिए किसी और पर निर्भर होने के बजाय रचनात्मक तरीके से हल निकाल लेते हैं
      बहुत बिखरे हुए दिमाग की ज़रूरत नहीं होती, लेकिन अच्छे/बेहतरीन programmers तकनीकी रूप से साधारण दिखने वाले projects में भी बड़ा फ़र्क पैदा करते हैं
    • आज की SPA और microservices वाली दुनिया में, आपने अभी जिस व्यक्ति का वर्णन किया, वह practically जीनियस-स्तर के engineer जैसा ही लगता है

  • हाल ही में मैं Steve Howe को बहुत सुन रहा हूँ, और मैंने देखा कि अब तक के महान guitarists में गिने जाने वाले उन्होंने कुछ ऐसा कहा था कि guitarists को player बनने पर ध्यान देना चाहिए। coder और engineer के बीच का फ़र्क भी कुछ ऐसा ही है
    मैंने अपने से तकनीकी रूप से ज़्यादा सक्षम programmers बहुत देखे हैं, लेकिन वे ज़रूरी नहीं कि बेहतर engineers भी हों। इसमें इस बात का बड़ा असर है कि मैं founder हूँ और मेरा कुछ marketing background भी है
    बहुत-सी कंपनियाँ उन non-coding skills को कम आँकती हैं जो वास्तव में किसी को engineer बनाती हैं। यह ऐसा है जैसे chef की जगह butcher रख लो और फिर हैरान हो कि खाना स्वादिष्ट क्यों नहीं है

    • बात कुछ हद तक सही है, लेकिन आम तौर पर engineering में आने वाले standard temperament से थोड़ी अलग भी है
      technical field में bachelor’s degree लेना, Ingersoll Rand या Boeing जैसी जगह पर engineer #52354 के रूप में काम करना, और 30 साल बाद एक जटिल लेकिन सीमित domain के expert के रूप में retire होना भी एक बेहतरीन career है। वह भी “engineer” की एक valid परिभाषा है, और ऐसे लोग भले उबाऊ लगें, वे व्यक्तिगत रूप से बहुत संतुष्ट जीवन जी सकते हैं
      मैं हाल में इस बारे में बहुत सोच रहा था कि management के लिए standard engineer को cost के नज़रिए से देखना आसान होता है, जबकि मुख्य लेख में वर्णित व्यक्ति की value engineering से आगे बढ़कर revenue पैदा करने वाले दूसरे departments तक भी जाती है, इसलिए वह ऐसी आलोचना से बच सकता है
      मैं खुद भी शायद उसी तरह का engineer हूँ, लेकिन उस stereotype के प्रति अपने तिरस्कार को ज़्यादा collaborative रवैये में बदलने की कोशिश कर रहा हूँ
    • लेकिन बाज़ार ऐसा ही है। 99% employers engineers नहीं चाहते, वे सस्ते modern framework coders चाहते हैं
      असली बाज़ार hardware संभालने वाले C++ engineers की तुलना में Spring Java coders को ज़्यादा महत्व देता है
    • ऐसे कौन-से उदाहरण हैं जहाँ non-coding skills किसी को बेहतर engineer बनाती हैं?
    • एक छोटा-सा जोड़: Howe बेहतरीन हैं और सर्वश्रेष्ठ में से एक ज़रूर हैं, लेकिन Paco De Lucia उनसे काफ़ी ऊपर हैं

  • मैंने दोनों तरफ़ का अनुभव किया है। नौकरी खोजने की प्रक्रिया में अस्पष्ट मनमौजीपन और हल्का-सा अपमान झेला है, और दूसरी तरफ़ ऐसे अनुभवी उम्मीदवारों का interview लेकर reject भी किया है जो बात तो बड़ी बनाते थे, लेकिन किसी भी language में FizzBuzz स्तर की समस्या भी code करके नहीं दिखा सके
    यह “technical interviews बेकार हैं” और “job market में अयोग्य उम्मीदवार बहुत हैं” में से किसी एक को चुनने वाली बात नहीं है। दोनों बातें एक साथ सच हो सकती हैं, और मुझे लगता है कि वे lemon market की तरह आपस में जुड़ी हुई भी हैं

    • मैंने सीखा है कि interview, और व्यापक रूप से job search, कोई objective और fair process नहीं है, और इसके नतीजे भी न निर्णायक होते हैं न reproducible
      objectively बेहतर व्यक्ति होते हुए भी आप hire हो सकते हैं, और ideal candidate होते हुए भी phone screening में तुरंत बाहर हो सकते हैं। अंततः यह काफ़ी हद तक luck जैसा है, और जो लोग इससे इनकार करते हैं उनमें survivor bias भी होता है और process की ख़ामियों को मानने की अनिच्छा भी
      यह फ़ैसला कि कोई अनुभवी उम्मीदवार FizzBuzz स्तर भी हल नहीं कर पाया, मेरे हिसाब से hiring को परेशान करने वाली cargo cult thinking को भी दर्शाता है। मैं ऐसे FANG engineers को जानता हूँ जो पहला interview पार करने के लिए coding golf, algorithm और data structure quizzes पर हफ़्तों अभ्यास करते हैं, जबकि उनका वास्तविक software engineering से बहुत कम संबंध होता है
      मैं तो यहाँ तक कहूँगा कि ऐसे सवाल technical evaluation से ज़्यादा ladder खींच लेने जैसे हैं। एक बार मुझे desktop app बनाने वाली C++ position में सिर्फ़ इसलिए automatic reject कर दिया गया क्योंकि मुझे placement new नहीं पता था, और backend position के लिए apply करने वाले मेरे एक दोस्त ने शुरू से Spring service बनाई, सारे integration tests pass किए, फिर भी सिर्फ़ controller में comments न होने के कारण reject कर दिया गया। कुछ interviewers ऐसे भी होते हैं जो PR पर एक लाइन की comment से ठीक हो जाने वाली चीज़ को बहुत बड़ा technical assignment बना देते हैं और उसी पर reject कर देते हैं

  • hiring करने वाले लोग भी ग़लती करते हैं। लोगों को सफलतापूर्वक hire करना सच में बहुत मुश्किल काम है
    कभी-कभी यह आपको ऐसी जगह काम करने से बचा भी लेता है जहाँ आप वैसे भी खुश नहीं रहते। वे यह समझाने में भी बहुत अच्छे नहीं होते कि उन्होंने hire क्यों नहीं किया, और इसका बड़ा हिस्सा luck होता है
    उदाहरण के लिए, शायद उन्हें लगा हो कि “यह Trump supporter नहीं लगता”, इसलिए वे उसके साथ सहज नहीं रह पाते। अगर आप सच में उनके तरह के लोग नहीं हैं, तो क्या आप सच में वहाँ काम करना चाहेंगे?
    job search हमेशा मुझे उदास कर देती है, और मुझे इसका कोई हल नहीं पता सिवाय इसके कि किसी ख़ास नौकरी से बहुत ज़्यादा उम्मीद नहीं बाँधनी चाहिए। साथ ही जो मौक़े बहुत खास नहीं लगते उन्हें भी बहुत आसानी से नज़रअंदाज़ नहीं करना चाहिए
    मेरी मौजूदा नौकरी में मेरा पहला boss बहुत ख़राब था और अच्छे लोग भी ज़्यादा नहीं थे, लेकिन वे लोग कंपनी छोड़ गए और मेरा promotion हो गया। ऐसी चीज़ों का पहले से अंदाज़ा कैसे लगाया जा सकता है? hiring manager भी आपको पहले से नहीं समझ सकता, और पूरी प्रक्रिया काफ़ी random और असहज होती है
    जब मैं interviewer की भूमिका में होता हूँ, तो मेरी प्राथमिकताएँ होती हैं। पहली, मेरे boss ने मुझे छोटी-सी सलाह दी थी: “अच्छे लोगों को hire करने की कोशिश करो।” मैं ऐसे अच्छे developer के साथ काम करना पसंद करूँगा जो दयालु हो, सहयोगी हो और साथ निभाकर चले, बजाय उस व्यक्ति के जो हमेशा अपनी ही चलाना चाहता हो और मानता हो कि वह अति-उत्पादक जीनियस है, इसलिए उसे पूरी power मिलनी चाहिए
    दूसरी, मैं देखता हूँ कि उम्मीदवार को software या कम-से-कम किसी चीज़ में दिलचस्पी है या नहीं। अगर software, tech, या काम से जुड़ी किसी चीज़ के लिए उसमें ज़रा-सी भी लगन नहीं है, तो वह resume में न लिखी ज़रूरी चीज़ें कैसे सीखेगा? यह मानकर चलना चाहिए कि लोग “finished product” बनकर नहीं आते, उन्हें सीखना पड़ता है

    • अगर आप सच में उनके तरह के लोग नहीं हैं, तो वहाँ काम क्यों करना चाहेंगे? क्योंकि किराया देना होता है। और कभी-कभी ऐश के तौर पर खाना भी खाना होता है

  • मुझे लगता है कि अच्छी interview process भी व्यवहार में कुछ ऐसे candidates को ज़रूर बाहर कर देगी जो असल काम में बहुत अच्छे साबित होते
    यह सही तरह से समझने के लिए कि कोई व्यक्ति उस काम के लिए उपयुक्त है या नहीं, interview process में employer और candidate दोनों का बहुत ज़्यादा समय लग जाता है। employer के नज़रिए से भी यह resources का खराब allocation है, और candidate के लिए भी इसे स्वीकार करना आसान नहीं है
    आदर्श रूप से अच्छा होता कि candidate office आए और एक दिन अकेले बैठकर छोटा coding project पूरा करे, लेकिन हक़ीक़त में यह practical नहीं है