Python डेवलपर इंटरव्यू के सवाल और जवाब: 2026 गाइड

Python में इंटरव्यू फेल होने का एक खास तरीका है: भाषा इतनी आसान है कि आप उसके अंदरूनी कामकाज को जाने बिना भी काम निकाल लेते हैं, इसलिए पैनल ने अपने सवाल ठीक उसी खाई को ढूंढने के लिए बनाए हैं। उम्मीद रखिए कि पूछा जाएगा कि dictionary लुकअप तेज़ क्यों है, generator मेमोरी में क्या रखता है, और इंटरप्रेटर लॉक असल में किसे रोकता है। यहां वे सवाल हैं जो बार-बार आते हैं, हर सवाल क्या टटोल रहा है, और मजबूत जवाब कैसे बनता है।

ये पैटर्न पूरे रोल के लिए हैं; अगर आपको किसी एक इंटरव्यू की शॉर्टलिस्ट चाहिए, तो असली जॉब पोस्टिंग फ्री Question Predictor और उस खास लूप में सबसे ज़्यादा संभावना वाले बीस सवाल पाइए।

Python डेवलपर इंटरव्यू असल में क्या परखते हैं?

यह कि आपकी समझ सिंटैक्स से आगे जाती है या नहीं। व्यवहार में इसका मतलब पांच झुंड हैं: डेटा स्ट्रक्चर और उनकी कीमत, आलस (generators और iterators), इंटरप्रेटर लॉक समेत कंकरेंसी की पूरी कहानी, टाइपिंग का अनुशासन, और टेस्टिंग। इन सबके इर्द-गिर्द कोड क्वालिटी लिपटी है, क्योंकि Python आपको ऐसा कुछ लिखने देता है जो चलता तो है पर संभालने लायक नहीं होता, और पैनल उसी जोखिम के खिलाफ हायर करते हैं।

सीनियॉरिटी सवाल उतने नहीं बदलती जितना आप सोचते हैं; वह फॉलो-अप की गहराई बदलती है। जूनियर से पूछा जाता है कि generator क्या है; सीनियर से पूछा जाता है कि वे दस हज़ार generators में मेमोरी कैसे सीमित रखेंगे। हाल में दो चीज़ें बदली हैं: प्रोफेशनल कोड में अब टाइप हिंट सजावट नहीं, उम्मीद मानी जाती है, और इंटरप्रेटर लॉक का जो जवाब लोगों ने रट रखा है वह अब अधूरा है।

Python इंटरव्यू प्रोसेस कैसा होता है?

चार से छह चरण, आम तौर पर दो हफ्तों में: एक रिक्रूटर स्क्रीन, एक कोडिंग स्क्रीन, एक लंबा प्रैक्टिकल राउंड, एक डिज़ाइन या कोड रिव्यू राउंड, और एक बिहेवियरल बातचीत। डोमेन लूप की शक्ल तय करता है, इसलिए वेब टीमें API और डेटाबेस के सवाल जोड़ती हैं, डेटा प्लेटफॉर्म टीमें पाइपलाइन और SQL के सवाल, और मशीन लर्निंग टीमें ऊपर से न्यूमेरिकल काम।

1. रिक्रूटर स्क्रीन (20 से 30 मिनट)। स्टैक, डोमेन, वर्ज़न, सैलरी बैंड। आपने जो सबसे दिलचस्प टेक्निकल चीज़ शिप की है, उसका दो वाक्यों वाला ब्योरा तैयार रखिए।
2. कोडिंग स्क्रीन (45 से 60 मिनट)। शेयर्ड एडिटर पर एक एक्सरसाइज़, आम तौर पर पार्सिंग या ट्रांसफॉर्मेशन, साथ में डेटा स्ट्रक्चर और उनकी कीमत पर तेज़ फंडामेंटल्स।
3. प्रैक्टिकल राउंड (60 से 90 मिनट)। किसी छोटे कोडबेस को आगे बढ़ाना, या एक टेक-होम और फिर उस पर बातचीत। टेस्ट अक्सर गिने जाते हैं, चाहे ब्रीफ में लिखा हो या नहीं।
4. डिज़ाइन या कोड रिव्यू राउंड। या तो कोई सर्विस डिज़ाइन कीजिए, या जानबूझकर खराब लिखे गए मॉड्यूल की समीक्षा करके बताइए कि आप क्या बदलेंगे। रिव्यू फॉर्मेट इसलिए लोकप्रिय है क्योंकि उसकी तैयारी करना मुश्किल है।
5. हायरिंग मैनेजर या बिहेवियरल। ओनरशिप, साथ काम करने का तरीका, और क्या आपके बताए लेवल का दावा टिकता है।

अगर आपको पता है कि आप किस कंपनी में इंटरव्यू दे रहे हैं, तो कंपनी सवाल बैंक फोरम खंगालने से कहीं तेज़ी से कंपनी का तौर-तरीका बता देते हैं।

Python में डेटा स्ट्रक्चर के कौन से सवाल आते हैं?

उम्मीद रखिए कि आपको list, dict, set और tuple में से चुनाव का कारण बताना होगा, और अभी-अभी लिखे गए ऑपरेशन की कीमत भी। पैनल देख रहा है कि आपको पता है या नहीं कि list पर मेंबरशिप टेस्ट लीनियर है और set पर कॉन्स्टेंट, और असल दुनिया में धीमे Python का बड़ा हिस्सा इसी के पीछे है। चुनते वक्त कॉम्प्लेक्सिटी बोलकर बताइए।

dict अंदर से कैसे बना है, और उससे क्या नतीजे निकलते हैं? यह क्या टटोलता है: भाषा का सबसे तेज़ स्ट्रक्चर आपके लिए ब्लैक बॉक्स तो नहीं। कवर कीजिए: की को हैश करके स्लॉट ढूंढना, टकराव सुलझाने के लिए open addressing, टेबल भरने पर रीसाइज़, और औसतन कॉन्स्टेंट-टाइम लुकअप जो खराब हैश के साथ बिगड़ जाते हैं। फिर नतीजे: की हैशेबल होनी चाहिए और इम्यूटेबल होनी बेहतर है, और 3.7 से इंसर्शन ऑर्डर की गारंटी है।

आप list के बजाय set कब चुनते हैं, और उसकी कीमत क्या है? यह क्या टटोलता है: कॉम्प्लेक्सिटी की समझ। set कॉन्स्टेंट-टाइम मेंबरशिप और मुफ्त डुप्लिकेट हटाना देते हैं, बदले में क्रम चला जाता है और एलिमेंट का हैशेबल होना ज़रूरी हो जाता है। मेंबरशिप टेस्ट वाले लूप से पहले list को set में बदल देना एक क्वाड्रैटिक लूप को लीनियर बना देता है।

generators और iterators पर इंटरव्यूअर क्या पूछते हैं?

generator वाले सवाल यह परखते हैं कि आप ऐसे डेटा के साथ काम कर सकते हैं या नहीं जो मेमोरी में नहीं समाता। उम्मीद रखिए कि iterable, iterator और generator का फर्क बताना होगा, फिर किसी eager कोड को lazy में बदलना होगा। नीचे का असली संकेत यह है कि आप मेमोरी के बारे में सोचते भी हैं या नहीं, क्योंकि list बनाते जाने वाली डिफॉल्ट Python शैली तब तक ठीक चलती है जब तक इनपुट बढ़ न जाए।

iterable, iterator और generator में क्या फर्क है? यह क्या टटोलता है: ऐसी चीज़ पर सटीकता जिसे ज़्यादातर लोग रोज़ इस्तेमाल करते हैं पर नाम नहीं जानते। iterable एक iterator बना सकता है; iterator अपनी जगह याद रखता है और अगला आइटम देता है जब तक StopIteration न उठे; generator वह iterator है जो yield वाले फंक्शन या generator expression से बनता है।

ऐसा फंक्शन दोबारा लिखिए जो 50GB की लॉग फाइल को list में पढ़ता है, ताकि वह गिरे नहीं। यह क्या टटोलता है: व्यवहार में आलस। फाइल ऑब्जेक्ट को लाइन दर लाइन घुमाइए (वह पहले से lazy है), एक generator फंक्शन से पार्स किए गए रिकॉर्ड yield कीजिए, और मेमोरी में सिर्फ जोड़-घटाव वाले नतीजे रखिए।

list comprehension और generator expression में क्या फर्क है? यह क्या टटोलता है: फर्क समझा गया है या सिर्फ सिंटैक्स रटा गया है। comprehension पूरी list तुरंत बना देता है; generator expression मांग पर आइटम बनाता है और एक बार में एक ही रखता है।

GIL वाला सवाल असल में क्या परख रहा है?

यह कि आप किसी वर्कलोड के लिए सही कंकरेंसी टूल चुन सकते हैं या नहीं। लॉक का मतलब है कि स्टैंडर्ड बिल्ड में एक बार में सिर्फ एक थ्रेड Python बायटकोड चलाता है, इसलिए थ्रेड से CPU का समानांतर काम नहीं मिलता, हालांकि जब थ्रेड IO का इंतज़ार करते हैं तब भी वे काम आते हैं। जाल वह कैंडिडेट है जिसने रट लिया है कि लॉक Python को धीमा बनाता है और वहीं रुक जाता है।

इंटरप्रेटर लॉक क्या है और यह आपके कोड पर कैसे असर डालता है? यह क्या टटोलता है: सटीकता। साफ बोलिए: यह इंटरप्रेटर की स्थिति को बचाता है, IO के दौरान और ऐसे एक्सटेंशन कोड के अंदर छोड़ दिया जाता है जो उसे रिलीज़ करता है (इसीलिए न्यूमेरिकल लाइब्रेरी कई कोर इस्तेमाल कर पाती हैं), और यह थ्रेड को CPU-बाउंड समानांतर काम के लिए बेकार बना देता है जबकि कंकरेंट IO के लिए वे काम के बने रहते हैं। free-threaded बिल्ड अब एक विकल्प के तौर पर मौजूद हैं, जिससे जवाब का भविष्य बदलता है, पर आज ज़्यादातर डिप्लॉयमेंट नहीं।

एक CPU-बाउंड जॉब में 20 मिनट लगते हैं। आप उसे तेज़ कैसे करेंगे? यह क्या टटोलता है: क्या आप पिछले जवाब पर अमल कर सकते हैं। पहले प्रोफाइल कीजिए ताकि पता चले समय असल में कहां जा रहा है, फिर बेहतर एल्गोरिदम सोचिए, फिर ऐसी लाइब्रेरी से वेक्टराइज़ कीजिए जो लॉक छोड़ती है, फिर कई कोर इस्तेमाल करने के लिए कई प्रोसेस, यह मानते हुए कि सीरियलाइज़ेशन और मेमोरी की कीमत चुकानी होगी।

थ्रेड, प्रोसेस या asyncio: आप कैसे चुनते हैं? यह क्या टटोलता है: एक साफ मानसिक मॉडल। बहुत ऊंची कंकरेंसी वाले IO के लिए asyncio, जहां कॉल का रास्ता आपके काबू में हो और लाइब्रेरी async हों। IO-बाउंड काम के लिए थ्रेड, जहां लाइब्रेरी ब्लॉक करती हों और कंकरेंसी मध्यम हो। CPU-बाउंड काम के लिए प्रोसेस।

Python इंटरव्यू में async के कौन से सवाल आते हैं?

async राउंड यह परखते हैं कि आप को-ऑपरेटिव शेड्यूलिंग समझते हैं या नहीं। इवेंट लूप एक टास्क तब तक चलाता है जब तक वह await न करे, फिर आगे बढ़ जाता है, इसलिए जो चीज़ बिना await किए ब्लॉक करती है वह सब कुछ रोक देती है। उम्मीद रखिए कि उसी खराबी पर सवाल आएंगे, कई टास्क एक साथ चलाने पर, और कैंसलेशन व एरर हैंडलिंग पर, जहां असल async बग सबसे ज़्यादा रहते हैं।

अगर आप coroutine के अंदर कोई ब्लॉकिंग फंक्शन कॉल कर दें तो क्या होता है? यह क्या टटोलता है: async का सबसे अहम कॉन्सेप्ट। उतनी देर इवेंट लूप रुक जाता है, इसलिए बाकी हर टास्क इंतज़ार करता है और आपकी ऊंची कंकरेंसी वाली सर्विस सीरियल हो जाती है। इलाज बताइए: async क्लाइंट इस्तेमाल कीजिए, या उस ब्लॉकिंग कॉल को थ्रेड एग्ज़ीक्यूटर पर भेजिए।

आप सौ रिक्वेस्ट एक साथ कैसे चलाएंगे और एक के फेल होने पर क्या करेंगे? यह क्या टटोलता है: टास्क का प्रबंधन। टास्क को gather करने पर वे एक साथ चलते हैं, और डिफॉल्ट में पहला एक्सेप्शन ऊपर चला जाता है जबकि बाकी बिना await हुए चलते रहते हैं, जब तक आप एक्सेप्शन लौटाने को न कहें। task group बेहतर है, ताकि फेल होने पर बाकी टास्क तय तरीके से कैंसल हों और कुछ अनाथ न छूटे।

दस हज़ार रिक्वेस्ट भेजते वक्त आप कंकरेंसी कैसे सीमित करेंगे? यह क्या टटोलता है: क्या आपने यह प्रोडक्शन में चलाया है। एक साथ दस हज़ार टास्क सॉकेट खत्म कर देते हैं, टारगेट को डुबो देते हैं, और टाइमआउट की ऐसी बौछार पैदा करते हैं जो आपके ही कोड की बग जैसी दिखती है। semaphore या क्यू से खाने वाला वर्कर पूल इस्तेमाल कीजिए, हर रिक्वेस्ट पर टाइमआउट रखिए, और बैकऑफ के साथ रिट्राई जोड़िए।

Python इंटरव्यूअर टाइपिंग पर क्या पूछते हैं?

टाइपिंग के सवाल ट्रिविया नहीं, अनुशासन परखते हैं। हिंट रनटाइम पर लागू नहीं होते; उन्हें आपकी पाइपलाइन में एक अलग टूल जांचता है और आपका एडिटर व आपके साथी पढ़ते हैं। पैनल सुनना चाहते हैं कि आप continuous integration में टाइप चेकर चलाते हैं और सबसे पहले फंक्शन की सीमाओं को टाइप करते हैं।

टाइप हिंट रनटाइम पर असल में करते क्या हैं? यह क्या टटोलता है: क्या आपको सीमा पता है। लगभग कुछ नहीं; वे मेटाडेटा के तौर पर रखे जाते हैं और इंटरप्रेटर उन्हें नज़रअंदाज़ कर देता है, इसीलिए इंटीजर लौटाने के लिए एनोटेट किया गया फंक्शन आराम से स्ट्रिंग लौटा देगा। फायदा स्टैटिक चेकर से और पढ़ने में आसानी से आता है।

Protocol क्या है और आप बेस क्लास की जगह उसे कब इस्तेमाल करेंगे? यह क्या टटोलता है: स्ट्रक्चरल टाइपिंग की समझ। Protocol बताता है कि किसी चीज़ की शक्ल कैसी होनी चाहिए, बिना इनहेरिटेंस मांगे, इसलिए वह डक टाइपिंग को ढंग से टाइप करता है और उन क्लास के साथ भी काम करता है जो आपकी नहीं हैं। इसकी तुलना abstract base class से कीजिए, जो इम्प्लीमेंट करने वाले से इनहेरिट करवाती है।

Python इंटरव्यू में टेस्टिंग के कौन से सवाल आते हैं?

टेस्टिंग के सवाल अक्सर टेक-होम की स्कोरिंग तय करते हैं, इसलिए उन्हें पहले दर्जे का मानिए। पैनल चाहते हैं तेज़ और अलग-थलग टेस्ट, कॉपी-पेस्ट के बजाय सेटअप के लिए fixtures, डुप्लिकेट फंक्शन के बजाय parametrised केस, और यह साफ समझ कि mock कब मदद कर रहा है और कब चुपचाप यह साबित कर रहा है कि आपका अपना mock काम करता है।

आप fixtures के साथ टेस्ट सूट कैसे बनाते हैं? यह क्या टटोलता है: आपके टेस्ट संभालने लायक हैं या नहीं। सही स्कोप पर सेटअप और टियरडाउन के लिए fixtures इस्तेमाल कीजिए, साझा वाले conftest फाइल में रखिए, और जो केस सिर्फ इनपुट से अलग हैं उन्हें parametrise कीजिए।

mocking कब सही फैसला है, और कब यह खराब संकेत है? यह क्या टटोलता है: टेस्टिंग की समझ। उस सीमा पर mock कीजिए जो आपकी नहीं है (कोई थर्ड-पार्टी API, घड़ी, कोई पेमेंट प्रोवाइडर) और patch वहां कीजिए जहां ऑब्जेक्ट इस्तेमाल होता है, वहां नहीं जहां वह डिफाइन हुआ है, जो सबसे आम गलती है।

जो कोड डेटाबेस से बात करता है उसे आप कैसे टेस्ट करते हैं? यह क्या टटोलता है: इंटीग्रेशन को लेकर व्यावहारिकता। इन-मेमोरी विकल्प के बजाय एक डिस्पोज़ेबल कंटेनर में असली डेटाबेस बेहतर है, क्योंकि इंजन बदल देने का मतलब है कि आप वे क्वेरी कभी टेस्ट नहीं करते जो असल में शिप होती हैं। हर टेस्ट को ऐसे ट्रांज़ैक्शन में लपेटिए जो रोलबैक हो जाए, और सूट का बड़ा हिस्सा शुद्ध यूनिट टेस्ट रखिए।

अंदरूनी कामकाज और पेच वाले कौन से सवाल अब भी पूछे जाते हैं?

कैलिब्रेशन के तौर पर कुछ क्लासिक सवाल आते हैं: म्यूटेबल डिफॉल्ट आर्गुमेंट, डेकोरेटर, और मेमोरी कैसे संभाली जाती है। ये जल्दी निपटते हैं, और पैनल असल में यह देख रहा है कि इनसे कभी आपका पाला पड़ा है या नहीं, इसलिए ट्यूटोरियल का नियम सुनाने के बजाय हर जवाब के साथ एक असली नतीजा जोड़िए।

म्यूटेबल डिफॉल्ट आर्गुमेंट खतरनाक क्यों है? यह क्या टटोलता है: डिफॉल्ट कब बनते हैं, यह समझ। डिफॉल्ट फंक्शन डिफाइन होते वक्त एक बार बनता है, हर कॉल पर नहीं, इसलिए list वाला डिफॉल्ट हर कॉल में साझा रहता है और उसमें चीज़ें जमा होती जाती हैं।

डेकोरेटर समझाइए, फिर एक ऐसा डेकोरेटर लिखिए जो फंक्शन को दोबारा चलाए। यह क्या टटोलता है: हायर-ऑर्डर फंक्शन के साथ आपकी सहजता। डेकोरेटर एक फंक्शन है जो फंक्शन लेता है और एक रैपर लौटाता है। functools.wraps से मेटाडेटा बचाइए और आर्गुमेंट को सामान्य तरीके से संभालिए। रिट्राई के लिए attempts और backoff को पैरामीटर बनाइए, सिर्फ उन्हीं एक्सेप्शन को पकड़िए जिन्हें दोबारा आज़माना ठीक है, और आखिरी कोशिश के बाद उसे दोबारा उठा दीजिए।

Python मेमोरी कैसे संभालता है? यह क्या टटोलता है: "गार्बेज कलेक्टर है" से आगे की समझ। रेफरेंस काउंटिंग आखिरी रेफरेंस जाते ही ऑब्जेक्ट को तुरंत मुक्त कर देती है, और एक साइकल कलेक्टर उन रेफरेंस साइकल को संभालता है जिन्हें अकेली काउंटिंग नहीं संभाल सकती।

Python कैंडिडेट्स कहां डूबते हैं?

सिंटैक्स पर कम ही। कैंडिडेट Python राउंड इसलिए गंवाते हैं कि वे ऐसा कोड लिखते हैं जो चलता है पर उसकी कीमत कभी नहीं बताते, टेस्ट छोड़ देते हैं, या सोचते वक्त चुप हो जाते हैं। पैनल आपके फंक्शन के साथ-साथ आपकी सोच भी खरीद रहा है, इसलिए ट्रेडऑफ और एज केस बोलते रहिए।

• चलता हुआ कोड, पर कीमत बताए बिना। सही जवाब जिसमें समय या मेमोरी का ज़िक्र न हो, ऐसा लगता है जैसे इस इंसान ने सिर्फ छोटे इनपुट पर काम किया है।
• इंटरप्रेटर लॉक वाला जवाब आधा सही देना। "Python कंकरेंसी कर ही नहीं सकता" गलत है, और फॉलो-अप इसीलिए बनाया गया है कि रटे हुए जवाब को समझे हुए जवाब से अलग किया जा सके।
• टेक-होम में टेस्ट छोड़ देना। अगर ब्रीफ खुला हुआ है, तो बिना टेस्ट वाला कोड आम तौर पर अधूरा गिना जाता है, चाहे वह कितना भी सुंदर हो।
• टाइप को पूरी तरह नज़रअंदाज़ करना। 2026 में बिना टाइप वाली फंक्शन सीमाएं बताती हैं कि इस इंसान ने किसी साझा कोडबेस में काम नहीं किया।

Python इंटरव्यू की तैयारी कैसे करें?

कुछ सेशन बिना किसी असिस्टेंट के सादे एडिटर में कोड लिखिए, क्योंकि स्क्रीन पर असिस्टेंट नहीं होगा और रवानी तेज़ी से घटती है। लगभग हर लूप में आने वाली चार चीज़ों की ड्रिल कीजिए: आपके चुने डेटा स्ट्रक्चर की कॉम्प्लेक्सिटी, eager कोड को lazy में बदलना, कंकरेंसी मॉडल चुनना, और जो लिखा उसे टेस्ट करना। फिर दो कहानियां तैयार कीजिए, एक परफॉर्मेंस की समस्या पर और एक कोड क्वालिटी पर हुए मतभेद पर।

लूप शुरू होने से पहले, असली जॉब पोस्टिंग फ्री Question Predictor में डालिए और उस खास रोल के लिए निकले बीस सवालों पर काम कीजिए, क्योंकि एक Django टीम, एक डेटा प्लेटफॉर्म टीम और एक मशीन लर्निंग टीम एक ही जॉब टाइटल के नीचे बिल्कुल अलग इंटरव्यू चलाती हैं।

लाइव राउंड के लिए GhostPilot एक रियल-टाइम इंटरव्यू कोपायलट है: एक Chrome एक्सटेंशन साइड पैनल और एक वैकल्पिक Windows डेस्कटॉप ऐप, जो कॉल को ट्रांसक्राइब करते हैं, सवाल आते ही उसे पकड़ते हैं, और करीब दो सेकंड बाद एक स्ट्रक्चर्ड जवाब तैयार रखते हैं। यह उन सवालों पर सबसे ज़्यादा काम आता है जिनमें कोई पेच छिपा हो, जैसे कंकरेंसी वाला सवाल। यह स्क्रिप्ट नहीं, एक इशारा है, और बारीकी अब भी आपके अपने काम से ही आती है। फ्री टियर आपको हफ्ते में 10 मिनट का लाइव इंटरव्यू टाइम देता है, कार्ड की ज़रूरत नहीं।

Python इंटरव्यू FAQ

Python डेवलपर इंटरव्यू की तैयारी कितने दिन करनी चाहिए? अगर आप रोज़ Python लिखते हैं तो दो से तीन हफ्ते: एक हफ्ता फंडामेंटल्स और डेटा स्ट्रक्चर पर, एक हफ्ता कंकरेंसी, टाइपिंग और टेस्टिंग पर, कुछ दिन कहानियों पर। अगर आपके कोड का कभी रिव्यू नहीं हुआ तो और ज़्यादा, क्योंकि रिव्यू राउंड में यही सामने आता है।

क्या Python इंटरव्यू में अब भी एल्गोरिदम के सवाल आते हैं? बड़ी कंपनियां अक्सर एक एल्गोरिदम राउंड रखती हैं, आम तौर पर आसान से मध्यम। छोटी टीमें काफी हद तक प्रैक्टिकल एक्सरसाइज़ और कोड रिव्यू पर आ गई हैं। दोनों ही हाल में, जिन बिल्ट-इन ऑपरेशन पर आप टिके हैं उनकी कॉम्प्लेक्सिटी पता होनी चाहिए।

क्या किसी खास फ्रेमवर्क का आना ज़रूरी है? अगर जॉब डिस्क्रिप्शन में किसी का नाम है, तो उसे पहले दर्जे का टॉपिक मानिए और रिक्वेस्ट लाइफसाइकल, ORM और टेस्टिंग पर सवालों की उम्मीद रखिए। वरना फंडामेंटल्स और एक ऐसा फ्रेमवर्क जिस पर आप गहराई में बात कर सकें, काफी है; पांच फ्रेमवर्क की सतही लिस्ट किसी को प्रभावित नहीं करती।

जो नहीं आता, क्या वह मान लेना चाहिए? हां। "मैंने वह प्रोडक्शन में इस्तेमाल नहीं किया, लेकिन मैं इसे ऐसे देखूंगा और सबसे पहले यह जांचूंगा" किसी आत्मविश्वास से दिए गलत जवाब से बेहतर है। Python पैनल फॉलो-अप में दो-तीन स्तर गहरे जाते हैं, इसलिए बहाना जल्दी ढह जाता है।