कई कठिन LeetCode समस्याएँ दरअसल आसान constraint problems हैं

 (buttondown.com)
6 पॉइंट द्वारा GN⁺ 2025-09-13 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • LeetCode की कठिन समस्याएँ भी constraint solver का उपयोग करने पर काफ़ी आसानी से हल की जा सकती हैं
  • जटिल dynamic programming या अपने खुद के algorithm की जगह MiniZinc जैसे constraint solver का उपयोग करके mathematical optimization problems को सरलता से हल किया जा सकता है
  • पारंपरिक programming languages में ऐसे mathematical optimization problems को व्यक्त करना कठिन होता है, इसलिए constraint-based approach की अपनी मज़बूती है
  • exception cases या अतिरिक्त constraints आने पर भी constraint solver में model बदलना न्यूनतम रहता है
  • runtime complexity सीधे लिखे गए optimized algorithm की तुलना में धीमी हो सकती है, लेकिन flexibility और development productivity के लिहाज़ से इसके कई फ़ायदे हैं

constraint solver से हल की जाने वाली LeetCode समस्याएँ

सही tool का चयन

  • लेखक को कॉलेज से स्नातक होने के बाद अपने पहले इंटरव्यू में 'coin change problem' दी गई थी

    • जब coin denominations दी जाएँ, तो किसी निश्चित राशि को चुकाने के लिए ज़रूरी coins की न्यूनतम संख्या निकालने की समस्या
    • उन्होंने एक साधारण greedy algorithm का उपयोग किया, लेकिन वह हर मामले में optimal solution की गारंटी नहीं दे सका
    • dynamic programming सही उत्तर था, लेकिन उसे implement न कर पाने के कारण इंटरव्यू असफल रहा

  • लेकिन अगर algorithm को खुद implement करने की बजाय MiniZinc जैसे constraint solver का उपयोग किया जाए, तो इसे बहुत आसानी से हल किया जा सकता है

    • उदाहरण कोड:

      int: total;
array[int] of int: values = [10, 9, 1];
array[index_set(values)] of var 0..: coins;

constraint sum (c in index_set(coins)) (coins[c] * values[c]) == total;
solve minimize sum(coins);

    • ऑनलाइन सीधे MiniZinc उदाहरण चलाकर देखा जा सकता है

    • solver धीरे-धीरे optimal solution खोज देता है

विभिन्न optimization/satisfaction problems

  • LeetCode आदि में अक्सर आने वाली mathematical optimization problems (objective function को maximize/minimize करना और कई constraints शामिल होना)
    programming language में हल करते समय low-level implementation की वजह से कठिन लगती हैं, लेकिन constraint solver के लिए उपयुक्त होती हैं
  • उदाहरण के लिए, नीचे दिए गए स्वभाव की कई समस्याएँ इसमें आती हैं

उदाहरण 1: अधिकतम stock profit समस्या

  • 'सूची के रूप में दिए गए stock price data में, एक बार खरीदकर उसके बाद बेचने पर मिलने वाला अधिकतम लाभ निकालो'
    • पारंपरिक रूप से O(n²) brute force या O(n) optimal algorithm की आवश्यकता होती है
    • MiniZinc में इसे नीचे की तरह एक सरल constraint problem के रूप में परिभाषित किया जा सकता है 
      array[int] of int: prices = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8];
var int: buy;
var int: sell;
var int: profit = prices[sell] - prices[buy];

constraint sell > buy;
constraint profit > 0;
solve maximize profit;

उदाहरण 2: कुछ संख्याओं को जोड़/घटा कर 0 बनाना (satisfaction problem)

  • 'क्या सूची में से तीन संख्याओं को जोड़कर या घटाकर 0 बनाया जा सकता है?'
    • यहाँ optimal value नहीं, सिर्फ़ satisfiable solution चाहिए
    • constraint solver में इसे इस तरह व्यक्त किया जा सकता है 
      include "globals.mzn";
array[int] of int: numbers = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8];
array[index_set(numbers)] of var {0, -1, 1}: choices;

constraint sum(n in index_set(numbers)) (numbers[n] * choices[n]) = 0;
constraint count(choices, -1) + count(choices, 1) = 3;
solve satisfy;

उदाहरण 3: histogram में सबसे बड़ा rectangle area

  • 'हर bar की height दी गई histogram में, बनाए जा सकने वाले सबसे बड़े rectangle का area निकालो'
    • पारंपरिक रूप से जटिल algorithm और कई states को manage करना पड़ता है
    • सिर्फ़ constraints के साथ समाधान को संक्षेप में लिखा जा सकता है 
      array[int] of int: numbers = [2,1,5,6,2,3];

var 1..length(numbers): x; 
var 1..length(numbers): dx;
var 1..: y;

constraint x + dx <= length(numbers);
constraint forall (i in x..(x+dx)) (y <= numbers[i]);

var int: area = (dx+1)*y;
solve maximize area;

output ["(\(x)->\(x+dx))*\(y) = \(area)"]

क्या constraint solver approach बेहतर है?

  • इंटरव्यू जैसी स्थिति में time complexity वगैरह के सवालों के सामने इसकी कमज़ोरी होती है

    • constraint solver का execution time अनुमान लगाना कठिन होता है, और यह आम तौर पर custom optimized algorithm से धीमा होता है
    • लेकिन गलत तरीके से लिखे गए निम्न-गुणवत्ता वाले algorithm से यह बेहतर है, और ज़्यादातर programmers के लिए हर बार optimal solution खुद लिखना आसान नहीं होता

  • वास्तविक ताकत नए constraints जोड़ने में लचीलापन है

    • उदाहरण के लिए, stock वाले उदाहरण में यदि एक बार की जगह कई बार खरीदने-बेचने की शर्त जोड़ दी जाए, तो algorithm की जटिलता तेज़ी से बढ़ जाती है
    • MiniZinc के constraint model में बहुत छोटे code बदलाव के साथ कहीं अधिक जटिल requirements को संभाला जा सकता है 
      include "globals.mzn";
int: max_sales = 3;
int: max_hold = 2;
array[int] of int: prices = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8];
array [1..max_sales] of var int: buy;
array [1..max_sales] of var int: sell;
array [index_set(prices)] of var 0..max_hold: stocks_held;
var int: profit = sum(s in 1..max_sales) (prices[sell[s]] - prices[buy[s]]);

constraint forall (s in 1..max_sales) (sell[s] > buy[s]);
constraint profit > 0;

constraint forall(i in index_set(prices)) (stocks_held[i] = (count(s in 1..max_sales) (buy[s] <= i) - count(s in 1..max_sales) (sell[s] <= i)));
constraint alldifferent(buy ++ sell);
solve maximize profit;

output ["buy at \(buy)\n", "sell at \(sell)\n", "for \(profit)"];

  • ऑनलाइन constraint problem के उदाहरण अक्सर Sudoku जैसे puzzles पर केंद्रित होते हैं, लेकिन वास्तव में इन्हें business logic या optimization requirements वाली समस्याओं में अधिक रोचक और व्यावहारिक रूप से इस्तेमाल किया जा सकता है

    • उदाहरण के लिए, symmetry breaking जैसी उन्नत optimization techniques लागू करने की संभावना भी अधिक होती है

समापन और संदर्भ

  • यह लेख लेखक के साप्ताहिक newsletter से लिया गया है, जो software history, formal methods, नई technologies, software engineering theory को कवर करता है
  • रुचि हो तो subscribe करें या लेखक की main website देखें
  • लेखक की नई पुस्तक "Logic for Programmers" भी प्रकाशित हो रही है

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

2 टिप्पणियां

 
kohs100 2025-09-15

आम तौर पर algorithm problems में time/space complexity की शर्तें नहीं होतीं क्या? अगर constraint solver से हल किया जा सकता है, तो असल में इससे सिर्फ़ समस्या को constraints में बदलने की क्षमता ही दिखाई जा सकती है... लेकिन यह वाकई practical work में ज़रूरी skill है या नहीं, इस बारे में मुझे ज़्यादा यक़ीन नहीं है...
 
GN⁺ 2025-09-13
Hacker News राय

  • Leetcode-टाइप इंटरव्यू सवालों की सबसे बड़ी समस्या यह है कि आप अतिरिक्त स्पष्टीकरण नहीं मांग सकते। मेरी सोचने की शैली आम तौर पर लोगों से अलग है, इसलिए Leetcode मुझे ज़्यादा सही जवाब याद करने पर निर्भर लगता है। जिन समस्याओं में पर्याप्त संदर्भ होता है, उन्हें मैं व्यावहारिक समझ के साथ ठीक से संभाल सकता हूँ, लेकिन ज़्यादातर में व्याख्या की कमी होती है, इसलिए समस्या को ठीक से समझ ही नहीं पाता। इसी वजह से आजकल मैं Leetcode या AI-ऑटोमेटेड इंटरव्यू चरणों को सीधे मना कर देता हूँ। असाइनमेंट, 1:1, या स्क्रीन-शेयर इंटरव्यू ठीक हैं। अगर Leetcode साइट पर अच्छे एक्सप्लेनेशन और सही उत्तर होते, तो self-study भी बहुत आसान होती, लेकिन हकीकत में यह बहुत मुश्किल है। यह सिर्फ़ कौशल का मामला नहीं है; मेरी सोचने की शैली और समस्या के प्रकार का मेल नहीं बैठता। बिना सवाल पूछे लगातार multiple-choice जैसे सवाल हल करना मुझे ऐसे सिस्टम जैसा लगता है जिसे असफल होने के लिए बनाया गया हो। मैं खास तौर पर pre-interview AI/Leetcode-टाइप समस्याओं की बात कर रहा हूँ; जहाँ वास्तविक इंसान के साथ सवाल-जवाब हो सकते हैं, ऐसे इंटरव्यू मुझे काफ़ी अच्छे लगते हैं.

    • LC(Leetcode) इंटरव्यू कुछ वैसे हैं जैसे प्रशिक्षित 100m दौड़ने की स्पीड को टेस्ट करना, जबकि असली काम कई बार रुक-रुक कर चलने वाली लंबी मैराथन जैसा होता है। फिर भी आजकल SMEGMA जैसी बड़ी कंपनियों में ऊँची सैलरी चाहिए तो यह खेल खेलना पड़ता है। उदाहरण के लिए, मैंने अपना 2D गेम इंजन खुद बनाया है, लेकिन ऐसा LC इंटरव्यू जिसमें कई hard समस्याएँ बैकफ्लिप मारते हुए हल करनी हों, शायद मैं पास न कर पाऊँ। मैंने यह बात मान ली है। मेरे बनाए इंजन

    • बात सिर्फ़ solutions रट लेने की नहीं है; रट लेने पर भी follow-up सवालों में अटक सकते हैं। लेकिन अगर आपने याद भी किया है और follow-up भी अच्छे से हल कर लेते हैं, तो मुझे लगता है कि Leetcode-स्टाइल समस्याओं में कोई दिक्कत नहीं है। Problem-solving आखिर pattern matching की क्षमता ही है, और जितने ज़्यादा patterns पता हों, उतनी बेहतर आपकी समस्या-समाधान क्षमता होती है। अब GPT समस्याएँ भी हल कर देता है और एक्सप्लेनेशन भी दे देता है, इसलिए यह कौशल पहले से ज़्यादा आसानी से सीखा जा सकता है। अभी से सीखना बेहतर है।

    • पूरी तरह सहमत हूँ। हाल के एक इंटरव्यू में मेरे असाइनमेंट को सबसे ऊँचे अंक मिले, इंजीनियरों और CEO ने भी अच्छा माना, लेकिन CTO ने अचानक live coding इंटरव्यू ले लिया और आखिर में मैं reject हो गया। 11 हफ़्तों का इंटरव्यू प्रोसेस बेकार चला गया। यह बेवकूफ़ाना प्रक्रिया अभी भी चल रही है, यह बहुत निराशाजनक है। मैंने जो demo/assignment किया था, वह यहाँ monumental लिंक और परिणाम पर है, और GitHub कोड यहाँ है।

    • क्या यही असल में जाँची जाने वाली क्षमता नहीं है कि आप स्पष्ट सवाल नहीं पूछ सकते? यानी उम्मीदवार समस्या हल करते समय किस तरह approach करता है, यह देखना। अगर लोगों को सिर्फ़ assertive ढंग से आगे बढ़ने पर मजबूर किया जाए, तो सारा software और भी ज़्यादा जटिल और अव्यवस्थित हो जाएगा। सच में मुश्किल चीज़ कोड की लाइनें लिखना नहीं, बल्कि समस्या सुलझाने की प्रक्रिया है।

    • जहाँ मैंने इंटरव्यू दिए, वहाँ एक-दो LC सवाल देने पर भी अगर आप स्पष्टीकरण माँगते, तो वे तुरंत real-time बातचीत और coding मोड में आ जाते थे। ऐसा करने का एक नुकसान यह है कि live coding का मानसिक दबाव बहुत बढ़ जाता है।

  • ऐसे इंटरव्यू सवाल मिलने पर मुझे अक्सर लगता है कि वे constraint solver को "इस्तेमाल" करने के बजाय, सीमित समस्या के लिए constraint solver को "खुद लिखने" की उम्मीद कर रहे हैं।

    • सही है। इसी वजह से मुझे लगता है कि इंटरव्यू का यह तरीका बुनियादी रूप से अटपटा है। असली engineering हालात में आप कॉफ़ी पी सकते हैं, papers पढ़ सकते हैं, लाइब्रेरी देख सकते हैं, टहलते हुए सोच सकते हैं, और मौजूदा tools (constraint solver या LLM) का सहारा लेकर समस्या को 100% हल कर सकते हैं। लेकिन इंटरव्यू जैसी स्थिति में शायद 0% भी हल न कर पाएँ। मैंने तो कभी सोचा भी नहीं कि ऐसे इंटरव्यू लेने वाली जगह join करूँ।

    • बिल्कुल। ज़्यादातर NP समस्याएँ constraint problem में बदली जा सकती हैं। व्यवहार में constraint solver सही उत्तर है या नहीं, यह application domain पर बहुत निर्भर करता है। और इंटरव्यू स्थिति में तो यह लगभग कभी सही उत्तर नहीं होता। ऐसे solvers कई बार साधारण dynamic programming से बहुत धीमे होते हैं।

    • कुछ कंपनी इंटरव्यू में यह बात सही हो सकती है, लेकिन हर जगह नहीं। आम तौर पर इंटरव्यू में LC का इस्तेमाल अक्सर सिर्फ़ एक ही कारण से होता है: अक्षम hiring process। इसमें शामिल लोग भी जानते हैं कि सिस्टम बदलना चाहिए, लेकिन उनके पास शक्ति नहीं होती या वे इतने बिखरे होते हैं कि बदलाव नहीं कर पाते। बड़ी कंपनियों में HR "standardization" के लिए एक ही सवाल अलग-अलग teams में घुमा देता है, और छोटी कंपनियों के पास अपने सवाल तैयार करने का समय नहीं होता, तो वे इंटरनेट से उठा लाती हैं। ऐसे में technical interviewer भी LC इंटरव्यू के आलोचक हो सकते हैं और वास्तव में standout उम्मीदवारों को पहचानने की कोशिश करते हैं। ऐसे माहौल में अगर आप constraint solver में रुचि या जानकारी दिखा दें, तो भी काफ़ी अच्छे अंक मिल सकते हैं।

    • अगर कोई LC hard समस्या को constraint solver से हल कर दे और फिर भी उसे hire न किया जाए, तो interviewer ही मूर्ख है। Constraint solver क्या होता है, और समस्या को formalize करके उसका उपयोग करना जानने वाले लोग बहुत कम होते हैं। मैंने भी इसे तीसरे वर्ष में इस्तेमाल किया था, और constraints लिखना ही इतना जटिल था कि दिमाग़ चकरा जाए।

    • यह बात कुछ हद तक सही भी है और गलत भी। मैंने इंटरव्यू में ऐसे सवाल पूछे हैं, और अगर उम्मीदवार constraint solver के बारे में सोचता था, तो मैं उसे अच्छे अंक देता था। असली engineering में constraint solvers कम आंके जाते हैं, जबकि वे यह दिखाने का अच्छा संकेत हैं कि कोई व्यक्ति जल्दी सही दिशा पकड़ सकता है। हाँ, बाद में मैं असली coding क्षमता समझने के लिए follow-up whiteboard सवाल भी पूछता। लेकिन उत्तर के रूप में constraint solver पेश करना अपने-आप में बुरा नहीं है।

  • बढ़िया insight है, लेकिन मुझे नहीं लगता कि यह वास्तविक इंटरव्यू में बहुत फिट बैठती है। ऐसे सवालों का मूल उद्देश्य उम्मीदवार की "दिमाग़ लगाने" की क्षमता जाँचना होता है। सिर्फ़ constraints बनाकर हल करना अनुभव और ज्ञान का स्तर तो दिखाता है, लेकिन यह नहीं दिखाता कि आपने वास्तव में कितना "सोचा"।

    • Interviewers अक्सर Leetcode "Top Interview 150" के "Array String" सवाल पूछते हैं। मेरे जैसे backend Python developer के नज़रिए से ये समस्याएँ रोज़मर्रा के काम से काफ़ी दूर लगती हैं। इनमें ज़्यादातर in-place array manipulation algorithms माँगे जाते हैं, जो आम तौर पर सिर्फ़ C या Rust जैसी performance-केंद्रित भाषाओं में ज़रूरी होते हैं। इसके विपरीत, "Hashmap"-टाइप समस्याएँ भाषा के अनुरूप tools के उपयोग को दिखाने में ज़्यादा उपयोगी हैं। साथ ही, कई सवालों में difficulty control भी ठीक नहीं है; "Easy" रेटिंग वाले सवाल (जैसे Majority Element) भी व्यवहार में historical algorithm (Boyer–Moore) की माँग करते हैं, इसलिए उन्हें सचमुच आसान कहना मुश्किल है।

    • हाल में Meta में देखा गया आख़िरी राउंड सिर्फ़ यह जाँचने की प्रक्रिया लगा कि उन्होंने जो खास समस्याएँ चुनी हैं, उन्हें आपने कितनी बार दोहराकर याद किया है। इसलिए अगर आप textbook answer से अलग जवाब दें, तो वे खुद असहज हो जाते हैं। ऐसा लगता है कि "चतुराई" अपने-आप में बहुत महत्वपूर्ण नहीं है।

    • bottom-up DP algorithms में कुछ हद तक दिमाग़ लगता है, लेकिन ज़्यादातर समस्याएँ top-down तरीके (recursion + memoization) से हल की जा सकती हैं। उदाहरण के लिए, coin change समस्या A* search से और बेहतर हल हो सकती है। लेकिन वास्तविक दुनिया में ज़्यादातर programmers को ऐसे algorithms शायद ही कभी सच में इस्तेमाल करने पड़ते हैं। असली महत्वपूर्ण बात यह पहचानना है कि आपने गलती से O(n^2) time complexity वाला code लिख दिया है। accidentallyquadratic.tumblr.com देखने पर पता चलता है कि मशहूर projects के काबिल लोग भी ऐसी गलतियाँ बार-बार करते हैं। इसलिए टेस्ट में algorithm बनाना और काम करते समय algorithmic mistakes पकड़ना, ये दोनों अलग क्षमताएँ हैं।

    • मैं इंटरव्यू में problem-solving क्षमता जाँचते समय thought process, communication style, और problem decomposition को महत्व देता हूँ। Difficulty को adjust करने वाले सवाल तैयार करना, ताकि हर उम्मीदवार को अपनी क्षमता दिखाने का मौका मिले, यह कहीं ज़्यादा महत्वपूर्ण है। कोई उम्मीदवार अचानक जवाब बोल दे या लंबे समय तक अटक जाए, इन दोनों स्थितियों से interviewer को वास्तव में बहुत कम उपयोगी जानकारी मिलती है। इसलिए problem-solving इंटरव्यू सवाल बहुत उपयोगी हो सकते हैं, लेकिन अफ़सोस कि व्यवहार में उनका इस्तेमाल अच्छे से नहीं होता।

    • ये समस्याएँ सच में "चतुराई" नहीं, बल्कि लगभग 12 तयशुदा patterns में से कितने आपने रटे हैं, यही जाँचती हैं। लगभग सभी उम्मीदवारों का चयन उनकी रचनात्मक problem-solving से नहीं, बल्कि तैयारी में की गई memorization पर निर्भर करता है। LeetCode सवाल इतने gamified हो चुके हैं कि अब वे सिर्फ़ यह जाँचने का माध्यम लगते हैं कि आपने तैयारी में कितना समय लगाया।

  • ज़्यादातर इंटरव्यू ऐसे लगते हैं जैसे वे यह मानकर चलते हों कि "अगर diabetes वाला मरीज घर पर खुद insulin synthesize नहीं कर सकता, तो वह life game में cheating कर रहा है"। जैसे मेरी पत्नी का blood sugar बढ़े तो वह insulin लेती है, वैसे ही अगर कोई constraint समस्या है तो solver इस्तेमाल करना ही सही बात है। जब तक कंपनी constraint solver software खुद नहीं बनाती, तब तक यह मानकर क्यों चला जाए कि "ऐसा software मौजूद ही नहीं है" और सब कुछ फिर से शुरुआत से बनवाया जाए?

    • असल बात संकट की घड़ी में insulin synthesize करने की क्षमता जाँचना नहीं, बल्कि यह देखना है कि क्या आप एक हफ़्ते में पाठ्यसामग्री रटकर phone interview में उसे ठीक से दोहरा सकते हैं। यह एक pre-screening aptitude test है।

    • अगर आप constraint solver से समस्या को प्रभावी ढंग से हल करने का तरीका ढूँढ सकते हैं, तो दो for loops और एक helper recursive function लिखकर खिलौना-जैसी समस्याएँ भी आसानी से हल कर सकते हैं।

    • (कोई सार्थक सामग्री नहीं)

    • coding tests के पक्ष में इतना कहूँगा कि ज़्यादातर लोग जो साधारण DP समस्याएँ भी हल नहीं कर पाते, वे वास्तविक काम में भी अक्सर कमज़ोर साबित होते हैं। बेशक अपवाद हो सकते हैं, लेकिन मेरा अनुभव यही रहा है।

  • जब भी constraint programming languages की बात आती है, Håkan Kjellerstrand का ज़िक्र ज़रूर होना चाहिए। वह MiniZinc सहित ढेरों उदाहरणों और समस्याओं वाला एक शानदार साइट चलाते हैं। hakank minizinc

    • और उन्होंने सिर्फ़ अच्छा वेबसाइट ही नहीं बनाया, वे व्यक्तिगत रूप से भी बहुत दयालु इंसान हैं।

  • बहुत पहले, जब मैं कॉलेज के computer engineering कोर्स में constraint solver नहीं सीख पाया था और बिल्कुल नया था, तब एक दोस्त ने मुझसे sports club scheduling app बनाने को कहा और इसी तरह की समस्या से सामना हुआ। शुरुआत में यह आसान लगी, लेकिन जब सच में कोशिश की तो मुझे समझ ही नहीं आया कि मैं कितनी बड़ी समस्या में फँस चुका हूँ। बाद में यह मेरी अहंकार-भरी सोच के लिए बहुत अच्छा सबक साबित हुआ, और उसी अनुभव ने बाद में schedules, deadlines, और expectations पर बात करने में बहुत मदद की।

    • यह शायद शुरुआती सवाल हो, लेकिन क्या constraint solver की जगह "linear optimization" से इसे और आसानी से हल नहीं किया जा सकता? अपने अनुभव से कहूँ तो linear optimization का फ़ायदा यह है कि नियमों के बीच के टकराव को weights के रूप में संभाला जा सकता है, ताकि न्यूनतम "side effects" के साथ समाधान निकाला जा सके।

    • 25 साल पहले, हाई स्कूल के दिनों में, जब मैं अभी TI-Basic और VB6 सीखना शुरू ही कर रहा था, मैं एक burger shop में part-time काम करता था। मैनेजर हर हफ़्ते स्टाफ़ schedule बनाना कितना मुश्किल है, यह कहकर परेशान होता था, तो मैंने कहा, "मुझे कंप्यूटर आते हैं, मैं आपके लिए scheduling program बना देता हूँ!" बहुत जल्दी समझ आ गया कि scheduler बनाना कितना कठिन है, और मैंने तुरंत हार मान ली।

  • "अगर यह समस्या इंटरव्यू में दी जाए, तो interviewer के पास तब कोई जवाब नहीं बचेगा जब उम्मीदवार पूछे: 'इस algorithm की runtime complexity क्या है?'" यानी लेखक का तर्क यह है कि अगर constraint solver पर्याप्त तेज़ी से समस्या हल नहीं कर पाता, तो वह Leetcode hard समस्या का उत्तर नहीं माना जाएगा। यदि runtime requirement ढीली हो तो आसान तरीका भी चल सकता है, लेकिन efficient solution ढूँढना ही पूरे challenge का बड़ा हिस्सा है।

    • वास्तविक काम में हमेशा "सबसे efficient solution" से ज़्यादा ज़रूरत इस बात की होती है कि आप नए requirements के लिए जल्दी solution design कर सकें। इसलिए वास्तविकता से कटी हुई efficiency-केंद्रित इंटरव्यू कसौटियों का कितना मतलब है, इस पर सवाल उठता है (हालाँकि यह role पर निर्भर कर सकता है)। मैं लेखक के इस नज़रिए से सहमत हूँ कि सबसे efficient solution हमेशा वास्तविक नौकरी की क्षमता को नहीं दर्शाता। Leetcode की आलोचना का एक संदर्भ यही भी है। उसी समस्या को इस दृष्टि से देखना कि "नए requirements के साथ आप कितने लचीले हैं", कहीं अधिक वस्तुनिष्ठ हो सकता है।

  • constraint solver? अच्छा विचार है, और इसके बारे में सुना भी है। लेकिन इंटरव्यू में आम तौर पर वे बस यह देखना चाहते हैं कि आप Python में खुद implement करते हुए कैसे सोचते हैं। (मुझे लगता है कि इंटरव्यू में constraint solver इस्तेमाल करने के लिए उन्हें मनाना लगभग असंभव होगा।)

    • क्या आपने सच में interviewer से यह बात कही है, या यह सिर्फ़ आपका अनुमान है?

    • import z3

  • अगर आप पहले DP (dynamic programming) से हल करें और फिर कहें, "अब मैं इसे constraint solver से भी करके दिखाता हूँ," तो सीधे hire.

    • +1

  • constraint solvers की असली ताकत यह है कि वे "नए requirements" के अनुसार कितनी आसानी से ढल सकते हैं। मैंने भी Google में data center optimization पर काम करते हुए ऐसे generalized solvers का यह फ़ायदा बहुत गहराई से महसूस किया है कि वे requirements बदलने पर भी लचीले ढंग से काम करते हैं।