अपनी सैलरी के लायक इंजीनियर का राज़: "अनजान चीज़ (Ambiguity)" को "जो किया जा सके" में बदलने की कला

मुख्य बिंदु:

• Senior और mid-level engineer के बीच का निर्णायक अंतर अनिश्चित और अस्पष्ट समस्याओं को ठोस रूप देने की क्षमता है।
• Senior की असली वैल्यू केवल coding skill में नहीं, बल्कि project risk हटाकर उसे executable plan में बदलने में है।
• मौजूदा hiring practices (जैसे algorithm tests) इस क्षमता का आकलन करने में विफल हैं।
• असली growth की शुरुआत coding से पहले problem को साफ़-साफ़ define करने की practice से होती है.

---

परिचय: Senior engineer की परिभाषा पर फिर से विचार

• आम तौर पर senior engineer को architecture design, communication, leadership जैसी कई skills की सूची से परिभाषित किया जाता है।
• लेकिन title, salary, और अनुभव के वर्षों को हटाकर देखें, तो senior या उससे ऊपर के engineer को अलग करने वाली एक ही मुख्य skill है: 'अस्पष्टता को कम करने की क्षमता'।
• बाकी सारी क्षमताएँ, जैसे technical execution, इसी मुख्य skill पर आधारित नतीजे हैं।

मुख्य चर्चा

1. समस्या हल करने के तरीके का अंतर: स्पष्टता बनाम अस्पष्टता

• Mid-level engineer: जब साफ़ specification और constraints दिए जाएँ, तो बेहतरीन प्रदर्शन करता है। अच्छी तरह परिभाषित समस्याएँ हल करने में दक्ष होता है।
• Senior engineer: "performance improve करनी है", "user complaints बढ़ रही हैं", "scalability पर ध्यान देना है" जैसी धुंधली और abstract requirements मिलने पर अलग दिखता है।
• Senior engineer अस्पष्ट समस्या को सिर्फ़ execute नहीं करता, बल्कि उसका विश्लेषण करके उसे तोड़ता है और ठोस tasks में बदल देता है।

2. Senior की मुख्य भूमिका project risk हटाना है

• Senior engineer बड़े और abstract problem के सामने नीचे दिए गए तरीकों से uncertainty कम करता है:

• ऐसे बुनियादी सवाल पूछना जो दूसरे लोग नहीं पूछते।

• महत्वपूर्ण signals और noise को अलग करना।

• यह तय करना कि क्या तुरंत करना है और क्या बाद के लिए टालना है।

• यह प्रक्रिया project का risk कम करती है (De-risking) और "हमें पता नहीं कि यह क्या है" जैसी स्थिति को "इसे छोटे executable projects और हटाए जाने वाले blockers में बाँटा जा सकता है" जैसी स्थिति में बदल देती है।

• जब senior engineer यह काम अच्छी तरह करता है, तो project बाहर से बहुत smooth और आसान लगता है, लेकिन असल में यह पहले से किए गए बड़े पैमाने के 'अदृश्य काम' का परिणाम होता है।

3. अस्पष्टता दूर करने के लिए ठोस approach

• Senior engineer coding शुरू करने से पहले problem को साफ़ करने के लिए ऐसे सवाल पूछता है:
• समस्या की जड़: जो solution हम चाहते हैं, उसके बजाय वह असली मूल समस्या क्या है जिसे हमें हल करना है?
• User की परिभाषा: हम ठीक किस व्यक्ति की कौन-सी तकलीफ़ हल करना चाहते हैं? ("user" जैसे बहुत व्यापक शब्द से बचें)
• Assumption की जाँच: मौजूदा plan में कौन-सी गलत धारणाएँ छिपी हो सकती हैं?
• Risk assessment: अगर हमारा आकलन गलत निकला, तो सबसे बुरी स्थिति क्या होगी?

4. Hiring system की सीमाएँ और senior selection की समस्या

• ज़्यादातर कंपनियाँ tech stack की सूची या algorithm problem solving (LeetCode) पर ध्यान देकर hiring करती हैं।
• यह तरीका इस बात की जाँच नहीं कर पाता कि कोई engineer अस्पष्ट product requirements को executable plan में बदल सकता है या नहीं।
• नतीजतन ऐसे 'नाम के senior' engineers की भरमार हो जाती है जिनकी coding skill तो मज़बूत होती है, लेकिन अधूरी specifications के सामने वे कुछ नहीं कर पाते।

निष्कर्ष: growth के लिए सुझाव

• Architecture और communication skills महत्वपूर्ण हैं, लेकिन उनकी असली वैल्यू तभी दिखती है जब 'क्या बनाना है' यह पहले से स्पष्ट हो चुका हो।
• अस्पष्टता कम किए बिना technical excellence का मतलब अक्सर सिर्फ़ 'गलत समस्या को बहुत elegantly हल करना' रह जाता है।
• यह तय करने का पैमाना कि आप senior level पर हैं या नहीं, यह है कि abstract task मिलने पर क्या आप किसी और के clarification का इंतज़ार करते हैं, या खुद उसे इतना स्पष्ट बनाते हैं कि टीम execute कर सके।
• यह जन्मजात प्रतिभा नहीं, बल्कि practice का क्षेत्र है। इसलिए जब भी कोई अस्पष्ट ticket (काम) मिले, तो तुरंत coding शुरू करने के बजाय पहले problem को concretize करने की training शुरू करनी चाहिए।

[mhj5730]

सीनियर डेवलपर को "algorithm coding test" से परखने की प्रक्रिया मुझे भी... hiring system की एक सीमा लगती है। मुझे लगता है कि जो लोग किसी समस्या के सार के करीब पहुँच चुके हैं, या पहुँच सकते हैं, वही अपनी salary के मुताबिक़ मूल्य देने वाले senior developer होते हैं।

[elbanic]

इस लेख से पता चलता है कि देखने के नज़रिए के अनुसार बातें अलग-अलग हो सकती हैं। मेरे मानदंड से senior और mid-level engineer के बीच फर्क करने का आधार सिर्फ scope है. Ambiguity को ठोस रूप देना engineer की बुनियादी क्षमता है, और मुझे लगता है कि mid-level engineer से ही यह कर पाना ज़रूरी है ताकि उसे engineer का title देना उचित लगे। इसलिए मेरे लिए यह लेख mid-level engineer और शुरुआती (associate) engineer के बीच फर्क करने का एक मानदंड बन सकता है।

[mbh023]

समस्या को स्पष्ट रूप से परिभाषित किए बिना
तकनीकी उत्कृष्टता सिर्फ़ 'गलत समस्या को खूबसूरती से हल करना' भर है।

वाकई रोंगटे खड़े कर देने वाली पंक्ति

[bichi]

सीनियर डेवलपर टेस्ट में programming test तक तो फिर भी समझ आता है
लेकिन अगर algorithm problems दे दें तो बहुत हैरानी होती है (इतना अजीब लगा कि ठीक से याद भी नहीं है)

[baeba]

1. सवाल पूछने की कला और सामाजिक पूंजी (Social Capital)

• रणनीतिक अज्ञानता: सीनियर के सवाल अज्ञानता से नहीं, बल्कि अनिश्चितता दूर करने की एक जानबूझकर की गई कार्रवाई से पैदा होते हैं। बुनियादी सवाल ("यह acronym क्या है?") बिना झिझक पूछ पाना एक मुख्य क्षमता है।
• सामाजिक पूंजी का उपयोग: जूनियर के विपरीत, सीनियर के पास पहले से 'सामाजिक पूंजी (विश्वास)' बनी होती है, इसलिए "बेवकूफी भरे सवाल" पूछने पर भी उन्हें अयोग्य नहीं माना जाता। इस भरोसे का उपयोग करके मीटिंग की अस्पष्टता हटाना सीनियर की भूमिका है।
• राजनीतिक संदर्भ पर विचार: स्पष्टता से बचने वाले मैनेजरों के लिए सीधा सवाल ख़तरे जैसा लग सकता है। इसलिए ऐसे सवाल चुनने की उच्च स्तर की समझदारी चाहिए जो राजनीतिक रूप से सुरक्षित हों और साथ ही प्रोजेक्ट को आगे बढ़ाएँ।

2. स्वायत्तता और risk management (Autonomy & Risk)

• सुरक्षा-जाल के बिना समस्या-समाधान: बाहरी मदद या स्पष्ट निर्देश के बिना भी अपने दम पर समस्या को पार करना (Plough through) और उसे पूरा करना, सीनियर होने का मानदंड है।
• Chaos पर नियंत्रण: हर हाल में स्पष्टता पाने के बजाय, सीनियर स्थिति के अनुसार 'रुकना' और 'आगे बढ़ना' तय करता है। परफ़ेक्ट spec का इंतज़ार करने के बजाय उपयुक्त assumptions बनाकर execution (Ship) करना, भ्रम कम करता है।
• सोचा-समझा risk लेना: compile न होने वाले code को runtime में ठीक करना या बड़े पैमाने पर refactoring करना जैसी साहसी तकनीकी निर्णय लेना, जो जूनियर नहीं कर सकता, और उसके परिणाम की ज़िम्मेदारी लेना।

3. title inflation और hiring का संरचनात्मक विरोधाभास

• Title Inflation: performance metrics हासिल करने के लिए तैयार न हुए जूनियरों को सीनियर प्रमोट कर देने की प्रथा व्यापक है। इससे title और वास्तविक क्षमता के बीच अंतर पैदा होता है।
• hiring तरीकों की सीमा: कंपनियाँ अस्पष्ट requirements को ठोस बनाने की क्षमता के बजाय सिर्फ algorithm (LeetCode) problem-solving पर फोकस करके hiring करती हैं। नतीजतन, ऐसे 'सीनियर' बढ़ते हैं जो spec न हो तो कुछ भी नहीं कर पाते।
• PM की भूमिका की जगह भरना: सीनियर इंजीनियर को आलसी PM द्वारा फेंकी गई अधपकी planning (Half-baked spec) को ठोस बनाने में समय लगाना पड़ता है। यह इंजीनियर की क्षमता भी है, लेकिन संगठनात्मक अक्षमता का सबूत भी।

4. केवल tenure बनाम जानबूझकर किया गया अभ्यास

• अनुभव की गुणात्मक भिन्नता: "10 साल की growth" और "1 साल के अनुभव को 10 बार दोहराना" — इन दोनों में साफ़ अंतर होना चाहिए। असली सीनियर, परिचित क्षेत्र से बाहर निकलकर किए गए intentional practice और चुनौतियों से बनता है।
• If vs What-if: जूनियर दिए गए conditions (If) को संभालने पर ध्यान देता है, जबकि सीनियर conditions बदल जाएँ तो (What-if) क्या होगा, यह मानकर पहले से तैयारी करता है।
• growth stages की परिभाषा: इंडस्ट्री का सामान्य मानदंड है — 'मार्गदर्शन पाने का चरण (Junior)' → 'स्वतंत्र रूप से काम करने का चरण (Regular)' → 'दूसरों का मार्गदर्शन करने का चरण (Senior)'।

5. सीनियर title पर संदेहपूर्ण नज़रिया

• सिर्फ pay grade: एक निंदक दृष्टिकोण यह है कि सीनियर जैसी उपाधि क्षमता का संकेतक कम, और HR द्वारा salary तय करने के लिए बनाई गई प्रशासनिक श्रेणी ज़्यादा है।
• कंपनियों के बीच अंतर: Big Tech के सीनियर (उच्च अस्पष्टता और बड़े दायरे की समस्याएँ सुलझाने वाले) और सामान्य कंपनियों के सीनियर (सिर्फ लंबे समय से टिके हुए कर्मचारी) के बीच क्षमता और待遇 का अंतर बहुत बड़ा है।