Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 202 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
202 questions
196
EN + हिं Easy
GB What is a 'code review checklist' and what cognitive bias does it specifically counteract?
IN 'कोड समीक्षा चेकलिस्ट' क्या है और यह किस संज्ञानात्मक पूर्वाग्रह का विशेष रूप से प्रतिकार करती है?
A
A code review checklist is an automated tool that verifies compliance with all coding standards कोड समीक्षा चेकलिस्ट एक स्वचालित उपकरण है जो सभी कोडिंग मानकों के अनुपालन की पुष्टि करता है
B
A code review checklist provides explicit prompts for reviewers to inspect specific defect categories — counteracting confirmation bias (reviewers unconsciously confirming the code does what they expect rather than looking for what it does wrong) एक कोड समीक्षा चेकलिस्ट समीक्षकों को विशिष्ट दोष श्रेणियों का निरीक्षण करने के लिए स्पष्ट संकेत प्रदान करती है - पुष्टिकरण पूर्वाग्रह का प्रतिकार करना (समीक्षक अनजाने में यह पुष्टि करते हैं कि कोड वही करता है जो वे अपेक्षा करते हैं बजाय इसके कि यह क्या गलत करता है)
C
Code review checklists are only used for security reviews and not for general code quality reviews कोड समीक्षा चेकलिस्ट का उपयोग केवल सुरक्षा समीक्षाओं के लिए किया जाता है, सामान्य कोड गुणवत्ता समीक्षाओं के लिए नहीं
D
Checklists reduce code review effectiveness by distracting reviewers from the overall code logic चेकलिस्ट समग्र कोड तर्क से समीक्षकों का ध्यान भटकाकर कोड समीक्षा प्रभावशीलता को कम कर देती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without checklists, reviewers tend to read code as a narrative (is this comprehensible?) rather than systematically hunting defects. Confirmation bias makes reviewers 'see' what code should do rather than what it actually does. Checklists force explicit consideration of error-prone categories: null pointer handling, thread safety, resource cleanup, error message quality — categories experience shows developers consistently overlook.
व्याख्या (हिन्दी) चेकलिस्ट के बिना, समीक्षक व्यवस्थित रूप से दोषों की तलाश करने के बजाय कोड को एक कथा के रूप में पढ़ते हैं (क्या यह समझ में आता है?)। पुष्टिकरण पूर्वाग्रह समीक्षकों को 'यह देखने' पर मजबूर करता है कि कोड वास्तव में क्या करता है इसके बजाय उसे क्या करना चाहिए। चेकलिस्ट त्रुटि-प्रवण श्रेणियों पर स्पष्ट रूप से विचार करने के लिए बाध्य करती हैं: शून्य पॉइंटर हैंडलिंग, थ्रेड सुरक्षा, संसाधन सफाई, त्रुटि संदेश गुणवत्ता - श्रेणियों का अनुभव दिखाता है कि डेवलपर्स लगातार अनदेखी करते हैं।
197
EN + हिं Medium
GB What is the primary purpose of coding standards in a multi-developer project and what happens when inconsistently applied?
IN मल्टी-डेवलपर प्रोजेक्ट में कोडिंग मानकों का प्राथमिक उद्देश्य क्या है और असंगत रूप से लागू होने पर क्या होता है?
A
Reduce compilation time by optimising code structure कोड संरचना को अनुकूलित करके संकलन समय कम करें
B
Ensure code is readable and maintainable by any team member; inconsistent application creates cognitive overhead, introduces subtle bugs in misunderstood conventions, and makes code review ineffective सुनिश्चित करें कि कोड किसी भी टीम सदस्य द्वारा पढ़ने योग्य और रखरखाव योग्य है; असंगत अनुप्रयोग संज्ञानात्मक ओवरहेड बनाता है, गलत समझे गए सम्मेलनों में सूक्ष्म बग पेश करता है, और कोड समीक्षा को अप्रभावी बनाता है
C
Only needed for open-source projects where external contributors work on the code केवल ओपन-सोर्स परियोजनाओं के लिए आवश्यक है जहां बाहरी योगदानकर्ता कोड पर काम करते हैं
D
Automatically enforce themselves through modern IDEs आधुनिक आईडीई के माध्यम से स्वयं को स्वचालित रूप से लागू करें
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Coding standards create a shared vocabulary for the codebase. When inconsistently applied, developers must context-switch between styles. More dangerously, inconsistent conventions can obscure bugs that consistent formatting would make obvious.
व्याख्या (हिन्दी) कोडिंग मानक कोडबेस के लिए एक साझा शब्दावली बनाते हैं। असंगत रूप से लागू होने पर, डेवलपर्स को शैलियों के बीच संदर्भ-स्विच करना होगा। अधिक खतरनाक रूप से, असंगत परंपराएँ उन बगों को अस्पष्ट कर सकती हैं जिन्हें लगातार स्वरूपण स्पष्ट कर देगा।
198
EN + हिं Medium
GB Why is 'premature optimisation' considered a coding standard violation and when is optimisation legitimate?
IN 'समयपूर्व अनुकूलन' को कोडिंग मानक का उल्लंघन क्यों माना जाता है और अनुकूलन कब वैध है?
A
Premature optimisation is when code is optimised before compilation समयपूर्व अनुकूलन तब होता है जब कोड को संकलन से पहले अनुकूलित किया जाता है
B
Premature optimisation prioritises performance over correctness and maintainability without profiling data — Knuth's rule applies; optimisation is legitimate after profiling identifies actual hotspots समयपूर्व अनुकूलन प्रोफाइलिंग डेटा के बिना शुद्धता और रखरखाव पर प्रदर्शन को प्राथमिकता देता है - नथ का नियम लागू होता है; प्रोफाइलिंग से वास्तविक हॉटस्पॉट की पहचान होने के बाद अनुकूलन वैध है
C
All performance optimisation is premature सभी प्रदर्शन अनुकूलन समयपूर्व हैं
D
Premature optimisation only applies to sorting algorithms समयपूर्व अनुकूलन केवल सॉर्टिंग एल्गोरिदम पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Knuth's full quote: 'Premature optimisation is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.' Profiling data identifies which 3% matters. Optimising guessed bottlenecks makes code complex and unmaintainable for no measurable gain.
व्याख्या (हिन्दी) नथ का पूरा उद्धरण: 'समयपूर्व अनुकूलन सभी बुराइयों की जड़ है। फिर भी हमें उस महत्वपूर्ण 3% में अपने अवसर नहीं गंवाने चाहिए।' प्रोफ़ाइलिंग डेटा पहचानता है कि कौन सा 3% मायने रखता है। अनुमानित बाधाओं को अनुकूलित करने से कोड जटिल हो जाता है और बिना किसी मापनीय लाभ के रखरखाव योग्य नहीं रह जाता है।
199
EN + हिं Easy
GB What is a 'code review checklist' and what cognitive bias does it specifically counteract?
IN 'कोड समीक्षा चेकलिस्ट' क्या है और यह किस संज्ञानात्मक पूर्वाग्रह का विशेष रूप से प्रतिकार करती है?
A
A code review checklist is an automated tool that verifies compliance with all coding standards कोड समीक्षा चेकलिस्ट एक स्वचालित उपकरण है जो सभी कोडिंग मानकों के अनुपालन की पुष्टि करता है
B
A code review checklist provides explicit prompts for reviewers to inspect specific defect categories — counteracting confirmation bias (reviewers unconsciously confirming the code does what they expect rather than looking for what it does wrong) एक कोड समीक्षा चेकलिस्ट समीक्षकों को विशिष्ट दोष श्रेणियों का निरीक्षण करने के लिए स्पष्ट संकेत प्रदान करती है - पुष्टिकरण पूर्वाग्रह का प्रतिकार करना (समीक्षक अनजाने में यह पुष्टि करते हैं कि कोड वही करता है जो वे अपेक्षा करते हैं बजाय इसके कि यह क्या गलत करता है)
C
Code review checklists are only used for security reviews and not for general code quality reviews कोड समीक्षा चेकलिस्ट का उपयोग केवल सुरक्षा समीक्षाओं के लिए किया जाता है, सामान्य कोड गुणवत्ता समीक्षाओं के लिए नहीं
D
Checklists reduce code review effectiveness by distracting reviewers from the overall code logic चेकलिस्ट समग्र कोड तर्क से समीक्षकों का ध्यान भटकाकर कोड समीक्षा प्रभावशीलता को कम कर देती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without checklists, reviewers tend to read code as a narrative (is this comprehensible?) rather than systematically hunting defects. Confirmation bias makes reviewers 'see' what code should do rather than what it actually does. Checklists force explicit consideration of error-prone categories: null pointer handling, thread safety, resource cleanup, error message quality — categories experience shows developers consistently overlook.
व्याख्या (हिन्दी) चेकलिस्ट के बिना, समीक्षक व्यवस्थित रूप से दोषों की तलाश करने के बजाय कोड को एक कथा के रूप में पढ़ते हैं (क्या यह समझ में आता है?)। पुष्टिकरण पूर्वाग्रह समीक्षकों को 'यह देखने' पर मजबूर करता है कि कोड वास्तव में क्या करता है इसके बजाय उसे क्या करना चाहिए। चेकलिस्ट त्रुटि-प्रवण श्रेणियों पर स्पष्ट रूप से विचार करने के लिए बाध्य करती हैं: शून्य पॉइंटर हैंडलिंग, थ्रेड सुरक्षा, संसाधन सफाई, त्रुटि संदेश गुणवत्ता - श्रेणियों का अनुभव दिखाता है कि डेवलपर्स लगातार अनदेखी करते हैं।
200
EN + हिं Easy
GB What is 'immutability by default' coding standard and what category of concurrency bugs does it eliminate?
IN 'डिफ़ॉल्ट रूप से अपरिवर्तनीयता' कोडिंग मानक क्या है और यह किस श्रेणी के समवर्ती बग को समाप्त करता है?
A
Immutability by default means variables can never be declared in any programming language डिफ़ॉल्ट रूप से अपरिवर्तनीयता का अर्थ है कि किसी भी प्रोग्रामिंग भाषा में चर कभी भी घोषित नहीं किए जा सकते
B
This standard prefers immutable data structures (final/const/readonly) unless mutation is explicitly required — it eliminates entire categories of concurrency bugs because immutable data can be freely shared across threads without synchronisation (no data races possible if nothing can be written after creation) यह मानक अपरिवर्तनीय डेटा संरचनाओं (अंतिम / स्थिरांक / केवल पढ़ने के लिए) को प्राथमिकता देता है जब तक कि उत्परिवर्तन की स्पष्ट रूप से आवश्यकता न हो - यह समवर्ती बग की पूरी श्रेणियों को समाप्त कर देता है क्योंकि अपरिवर्तनीय डेटा को सिंक्रनाइज़ेशन के बिना थ्रेड्स में स्वतंत्र रूप से साझा किया जा सकता है (यदि निर्माण के बाद कुछ भी नहीं लिखा जा सकता है तो कोई डेटा दौड़ संभव नहीं है)
C
Immutability by default requires rewriting all existing mutable code before any new development can proceed डिफ़ॉल्ट रूप से अपरिवर्तनीयता के लिए किसी भी नए विकास को आगे बढ़ाने से पहले सभी मौजूदा परिवर्तनीय कोड को फिर से लिखना आवश्यक है
D
Immutable data structures always consume more memory than mutable ones with no performance trade-offs ever justified अपरिवर्तनीय डेटा संरचनाएं हमेशा परिवर्तनशील डेटा संरचनाओं की तुलना में अधिक मेमोरी का उपभोग करती हैं, जिसमें कोई प्रदर्शन समझौता कभी भी उचित नहीं होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Data races (the most insidious concurrency bugs) require: shared memory, at least one writer, and lack of synchronisation. Immutable objects eliminate the 'writer' condition entirely — once created, the value never changes, so any number of threads can read it simultaneously with zero risk of race conditions. Functional languages (Clojure, Haskell) and modern practice in Java/C# (records, readonly structs) embrace this as a primary concurrency-safety strategy, trading some flexibility/performance for eliminated bug classes.
व्याख्या (हिन्दी) डेटा रेस (सबसे घातक समवर्ती बग) के लिए आवश्यक है: साझा मेमोरी, कम से कम एक लेखक, और सिंक्रनाइज़ेशन की कमी। अपरिवर्तनीय वस्तुएँ 'लेखक' की स्थिति को पूरी तरह से समाप्त कर देती हैं - एक बार निर्मित होने के बाद, मूल्य कभी नहीं बदलता है, इसलिए किसी भी संख्या में थ्रेड इसे दौड़ की स्थिति के शून्य जोखिम के साथ एक साथ पढ़ सकते हैं। कार्यात्मक भाषाएं (क्लोजर, हास्केल) और जावा/सी# (रिकॉर्ड, रीडओनली स्ट्रक्चर्स) में आधुनिक अभ्यास इसे प्राथमिक संगामिति-सुरक्षा रणनीति के रूप में अपनाते हैं, जो बग वर्गों को खत्म करने के लिए कुछ लचीलेपन/प्रदर्शन का व्यापार करते हैं।
201
EN + हिं Medium
GB What is 'fail-fast principle' in coding standards and how does it differ from graceful degradation?
IN कोडिंग मानकों में 'फेल-फास्ट सिद्धांत' क्या है और यह ग्रेसफुल डिग्रेडेशन से कैसे भिन्न है?
A
Fail-fast and graceful degradation are identical strategies applied at different system layers फेल-फास्ट और ग्रेसफुल डिग्रेडेशन अलग-अलग सिस्टम परतों पर लागू की जाने वाली समान रणनीतियाँ हैं
B
Fail-fast immediately surfaces errors at the point of detection (throw on invalid state rather than continuing with corrupted data) — making bugs visible and traceable to their source; graceful degradation continues operating with reduced functionality when a component fails (show cached data if live data unavailable) — appropriate for user-facing resilience but inappropriate for catching programming errors during development फ़ेल-फ़ास्ट तुरंत पता लगाने के बिंदु पर त्रुटियों को सामने लाता है (दूषित डेटा को जारी रखने के बजाय अमान्य स्थिति पर फेंकें) - बग को दृश्यमान बनाना और उनके स्रोत का पता लगाना; जब कोई घटक विफल हो जाता है तो ग्रेसफुल डिग्रेडेशन कम कार्यक्षमता के साथ काम करना जारी रखता है (यदि लाइव डेटा अनुपलब्ध है तो कैश्ड डेटा दिखाएं) - उपयोगकर्ता-सामना के लचीलेपन के लिए उपयुक्त लेकिन विकास के दौरान प्रोग्रामिंग त्रुटियों को पकड़ने के लिए अनुपयुक्त
C
Fail-fast should never be used in production systems; only graceful degradation is acceptable फेल-फास्ट का उपयोग उत्पादन प्रणालियों में कभी नहीं किया जाना चाहिए; केवल शालीन अवनति ही स्वीकार्य है
D
Graceful degradation always produces worse user experience than fail-fast in all scenarios ग्रेसफुल डिग्रेडेशन हमेशा सभी परिदृश्यों में फेल-फास्ट से भी बदतर उपयोगकर्ता अनुभव उत्पन्न करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) During development, fail-fast (assertions, strict validation) ensures bugs surface immediately with full context rather than silently corrupting data that fails mysteriously much later. In production user-facing systems, graceful degradation (Netflix showing cached recommendations if the live recommendation service is down) prioritises availability over perfect correctness. The art is applying fail-fast to programming errors (which indicate bugs needing fixes) and graceful degradation to operational failures (which indicate infrastructure issues to be tolerated).
व्याख्या (हिन्दी) विकास के दौरान, फेल-फास्ट (दावा, सख्त सत्यापन) यह सुनिश्चित करता है कि बग तुरंत पूरे संदर्भ के साथ सामने आ जाएं न कि चुपचाप डेटा को दूषित कर दें जो बहुत बाद में रहस्यमय तरीके से विफल हो जाता है। उत्पादन उपयोगकर्ता-सामना वाले सिस्टम में, ग्रेसफुल डिग्रेडेशन (लाइव अनुशंसा सेवा बंद होने पर नेटफ्लिक्स कैश्ड अनुशंसाएँ दिखाता है) सही शुद्धता पर उपलब्धता को प्राथमिकता देता है। कला प्रोग्रामिंग त्रुटियों (जो बग को ठीक करने की आवश्यकता को इंगित करती है) और परिचालन विफलताओं (जो सहन किए जाने वाले बुनियादी ढांचे के मुद्दों को इंगित करती है) के लिए शालीन गिरावट को लागू कर रही है।
202
EN + हिं Easy
GB What is 'graceful shutdown' coding standard for distributed services and what data loss risk does ignoring it create?
IN वितरित सेवाओं के लिए 'ग्रेसफुल शटडाउन' कोडिंग मानक क्या है और इसे अनदेखा करने से डेटा हानि का क्या जोखिम पैदा होता है?
A
Graceful shutdown only matters for desktop applications, not server-side distributed services ग्रेसफुल शटडाउन केवल डेस्कटॉप अनुप्रयोगों के लिए मायने रखता है, सर्वर-साइड वितरित सेवाओं के लिए नहीं
B
Graceful shutdown handlers respond to termination signals (SIGTERM) by finishing in-flight requests, closing database connections cleanly, and deregistering from service discovery before exiting — ignoring it (immediate process kill) risks dropping in-progress requests mid-transaction, leaving database connections in inconsistent states, and routing new traffic to a service that's already shutting down ग्रेसफुल शटडाउन हैंडलर इन-फ़्लाइट अनुरोधों को पूरा करके, डेटाबेस कनेक्शन को साफ़-साफ़ बंद करके, और बाहर निकलने से पहले सेवा खोज से अपंजीकृत करके समाप्ति संकेतों (SIGTERM) का जवाब देते हैं - इसे अनदेखा करना (तत्काल प्रक्रिया को समाप्त करना) मध्य-लेन-देन में प्रगति अनुरोधों को छोड़ने का जोखिम, डेटाबेस कनेक्शन को असंगत स्थिति में छोड़ना, और नए ट्रैफ़िक को उस सेवा पर रूट करना जो पहले से ही बंद हो रही है
C
Graceful shutdown is automatically handled by all container orchestration platforms with zero application code required ग्रेसफुल शटडाउन को शून्य एप्लिकेशन कोड की आवश्यकता के साथ सभी कंटेनर ऑर्केस्ट्रेशन प्लेटफार्मों द्वारा स्वचालित रूप से नियंत्रित किया जाता है
D
Implementing graceful shutdown increases application startup time but has no effect on shutdown behaviour ग्रेसफुल शटडाउन लागू करने से एप्लिकेशन स्टार्टअप समय बढ़ जाता है लेकिन शटडाउन व्यवहार पर कोई प्रभाव नहीं पड़ता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Kubernetes sends SIGTERM before forcibly killing a pod (SIGKILL after a grace period). An application without a SIGTERM handler is killed mid-request when scaling down or during rolling deployments — a user's checkout request might be half-processed, charging their card without confirming the order. Proper graceful shutdown: stop accepting new connections, finish processing in-flight requests within the grace period, then exit cleanly — preventing data corruption during routine deployment operations.
व्याख्या (हिन्दी) कुबेरनेट्स एक पॉड को जबरन मारने से पहले SIGTERM भेजता है (एक अनुग्रह अवधि के बाद SIGKILL)। SIGTERM हैंडलर के बिना एक एप्लिकेशन स्केल डाउन करते समय या रोलिंग तैनाती के दौरान अनुरोध के मध्य में बंद हो जाता है - उपयोगकर्ता का चेकआउट अनुरोध आधा संसाधित हो सकता है, जिससे ऑर्डर की पुष्टि किए बिना उनके कार्ड से शुल्क लिया जा सकता है। उचित ग्रेसफुल शटडाउन: नए कनेक्शन स्वीकार करना बंद करें, ग्रेस अवधि के भीतर इन-फ़्लाइट अनुरोधों को संसाधित करना समाप्त करें, फिर सफाई से बाहर निकलें - नियमित तैनाती संचालन के दौरान डेटा भ्रष्टाचार को रोकना।
196–202 of 202