उम्मीदवारों को देने के लिए मेरा पसंदीदा कोडिंग प्रश्न

प्रॉम्प्ट की अस्पष्टता और “चालाकी”

• कई लोगों को “वफादार ग्राहकों” वाली स्पेसिफिकेशन (खासकर “कम-से-कम दो विशिष्ट पेज”) अपर्याप्त रूप से परिभाषित या तार्किक रूप से अस्पष्ट लगती है।
• कुछ लोगों का तर्क है कि यह वास्तविक दुनिया के प्रोडक्ट स्पेक्स जैसा है और अस्पष्टता पहचानने तथा स्पष्टता के लिए प्रश्न पूछने की क्षमता की परीक्षा लेता है।
• दूसरों को यह अनुचित “मन पढ़ना” लगता है, खासकर तनावपूर्ण इंटरव्यू में जहाँ उम्मीदवारों को डर हो सकता है कि सवाल पूछने पर उन्हें नकारात्मक रूप से देखा जाएगा।
• चिंता यह भी है कि इंटरव्यूअर यह मान लेते हैं कि उन्होंने “कृपया सवाल पूछें” बहुत साफ़ तरीके से संकेतित किया है, जबकि ऐसा नहीं होता।

यह प्रश्न वास्तव में क्या जाँच रहा है

• समर्थकों का कहना है कि यह जाँचता है:
  • खराब एसिम्प्टोटिक जटिलता को पहचानना (भोले-भाले O(n²) को अस्वीकार करना)।
  • बुनियादी डेटा स्ट्रक्चर (मैप/सेट) का उपयोग और समय–स्थान ट्रेडऑफ।
  • बड़े डेटा और बाधाओं के बारे में तर्क करने की क्षमता।
• आलोचकों का कहना है कि यह मुख्यतः LeetCode-शैली पैटर्न मैचिंग और Big-O की बातों को पुरस्कृत करता है, न कि आवश्यकताओं को समझने, सिस्टम डिज़ाइन, या हितधारकों के साथ काम करने जैसी वास्तविक दुनिया की क्षमताओं को।
• कुछ लोग यह भी बताते हैं कि सर्वोत्तम इन-मेमोरी समाधान नाज़ुक होते हैं और “ठीक दो दिनों” से कसकर जुड़े होते हैं, जिससे विस्तारशीलता प्रभावित होती है।

वैकल्पिक समाधान शैलियाँ (SQL, शेल, टूल्स)

• कई लोग इसे शेल पाइपलाइन (sort/uniq/grep/awk) या एक छोटे SQLite/DB क्वेरी से हल करेंगे, खासकर एक-बार के बिज़नेस रिपोर्टों के लिए।
• बहस:
  • DB/शेल के पक्ष में: लागू करने में सबसे तेज़, आवश्यकताओं में बदलाव करना आसान, बाहरी sort/indexes के जरिए बड़े डेटा को संभालता है।
  • “20 लाइनों का कोड” के पक्ष में: निर्भरताएँ न्यूनतम रखता है; एल्गोरिद्मिक समझ पर ध्यान देता है।
• कुछ लोग कहते हैं कि समस्या मूलतः एक relational join है; DB execution plans (hash join, merge join) प्रस्तावित CS समाधानों के समान हैं।

प्रदर्शन बनाम व्यावहारिकता

• “कोई भी महान इंजीनियर कभी O(n²) पर नहीं रुकना चाहिए” पर तीखा मतभेद है।
  • एक पक्ष: क्वाड्रेटिक एल्गोरिद्म खतरनाक फंदे हैं; बेहतर तरीके अक्सर उतने ही सरल होते हैं और सहज होने चाहिए।
  • दूसरा पक्ष: एक-बार या छोटे डेटासेट के लिए, डेवलपर का समय और सादगी एसिम्प्टोटिक्स से अधिक महत्वपूर्ण हैं; premature optimization आम है।
• कई लोग बताते हैं कि चतुर माइक्रो-ऑप्टिमाइज़ेशन (सिर्फ 2 पेज स्टोर करना, early exits, आदि) जटिलता बढ़ाते हैं और बदलते मेट्रिक्स के लिए लचीलापन घटाते हैं।

इंटरव्यू डिज़ाइन, पूर्वाग्रह, और उम्मीदवार अनुभव

• कुछ लोग इस प्रश्न की प्रशंसा करते हैं क्योंकि यह सरल, स्पष्ट और सीनियर्स के लिए भी उपयुक्त है; जबकि अन्य लोग एल्गोरिद्मिक लाइव-कोडिंग को उबाऊ, नीरस, या “dehumanizing” बताते हैं।
• चिंता यह है कि यह शैली इन लोगों को चुनती है:
  • जो उच्च दबाव वाले, विरोधी-से-लगने वाले टेस्ट में सहज हों।
  • जिन्होंने खास तौर पर इसी तरह की समस्याओं का अभ्यास किया हो।
• अन्य लोग सहकारी, pair-programming-शैली के अभ्यास या छोटे वास्तविक कार्यों (जैसे CLI apps) की वकालत करते हैं, जिन्हें रोज़मर्रा की प्रभावशीलता और टीमवर्क के बेहतर संकेतक माना जाता है।