सॉफ़्टवेयर इंजीनियर इंटरव्यू के सवाल और जवाब (हिंदी में)

Array में elements लगातार memory में रहते हैं, इसलिए index i पढ़ना O(1) है और cache-friendly होने से iteration असल में तेज़ चलता है। बीच में insert या delete करना O(n) है, क्योंकि बाकी elements खिसकाने पड़ते हैं। Linked list में nodes pointers से जुड़े होते हैं, इसलिए जिस node का reference पहले से हो वहां insert या delete O(1) है, पर i-th element तक पहुंचना O(n) है। ज़्यादातर मामलों में मैं resizable array (जैसे ArrayList) चुनता हूं; linked list तब, जब बीच में बार-बार जोड़ना-हटाना हो, जैसे LRU cache में।

Hash map key को hash function से एक integer में बदलता है, फिर buckets की संख्या से modulo लेकर bucket चुनता है। औसतन lookup, insert और delete O(1) होते हैं। Collision तब होता है जब दो keys एक ही bucket में पहुंचें। आम हल chaining है, यानी bucket में एक list, या open addressing, यानी अगली ख़ाली जगह ढूंढना। जब load factor एक सीमा से ऊपर जाता है, map बड़ी table बनाकर सारी keys दोबारा hash करता है। ख़राब hash function से सब एक bucket में जाएं तो worst case O(n) हो जाता है।

Binary search O(log n) time और iterative रूप में O(1) space लेता है, क्योंकि हर कदम पर search range आधी हो जाती है। इसके लिए sorted array चाहिए, या मोटे तौर पर एक monotonic condition, जहां किसी बिंदु तक जवाब false हो और उसके बाद true। इसका मतलब है कि binary search सिर्फ़ array में खोजने के लिए नहीं है। जैसे "कम से कम कितनी speed से सारे काम समय पर पूरे होंगे" जैसे सवाल में मैं answer पर binary search करता हूं। Mid निकालते समय overflow से बचने के लिए low + (high - low) / 2 लिखता हूं।

पहले requirements कन्फ़र्म करूंगा: short link बनाना, तेज़ redirect, optional expiry, और रोज़ कितने नए links और redirects होंगे। यह system बहुत read-heavy है। Key के लिए distributed ID generator से unique counter लेकर उसे base62 में बदलूंगा, जिससे collision नहीं होगा और key छोटी रहेगी। Mapping एक key-value store में रखूंगा, जिसे key से shard किया जा सके। Redirect के लिए लोकप्रिय links Redis cache में रखूंगा। Analytics को redirect के रास्ते से हटाकर queue में भेजूंगा, ताकि redirect धीमा न हो।

सबसे पहले देखता हूं कि change वही करता है जो ticket में लिखा है और edge cases संभालता है: ख़ाली input, null, बाहरी calls का fail होना और concurrency। फिर readability, नाम, क्या function एक ही काम करता है, और क्या tests नया behaviour कवर करते हैं। Formatting जैसी चीज़ें linter पर छोड़ता हूं। Comments में साफ़ लिखता हूं कि कौन सी बात ज़रूरी है और कौन सा सिर्फ़ सुझाव, और "यह गलत है" की जगह वजह के साथ सवाल पूछता हूं। कोशिश करता हूं कि review एक working day के अंदर हो जाए।

Process की अपनी अलग memory होती है, इसलिए processes एक-दूसरे से अलग रहते हैं और pipes, sockets या files से बात करते हैं। Threads एक ही process के अंदर रहते हैं और उसकी memory share करते हैं, इसलिए हल्के होते हैं पर एक-दूसरे के काम में दख़ल दे सकते हैं। Race condition तब होती है जब नतीजा इस पर निर्भर करे कि threads किस क्रम में चले, जैसे दो threads एक साथ counter पढ़कर बढ़ाएं और एक update खो जाए। इससे बचने के लिए lock, atomic operations या immutable data इस्तेमाल करता हूं।

एक senior engineer ने कहा कि मैं एक सीधे loop की जगह generic rules engine बनाऊं, ताकि आगे नए discount types जुड़ सकें। मुझे लगा कि यह उस ज़रूरत के लिए जटिलता है जो अभी है ही नहीं। मैंने review में लिखा कि अभी दो ही discount types हैं, और दिखाया कि तीसरा आने पर refactor करने में करीब एक दिन लगेगा। फिर पांच मिनट की call पर बात की। हमने सीधा code रखने और एक ticket बनाने पर सहमति बनाई। अगर वे नहीं मानते, तो मैं उनका फ़ैसला मानकर काम करता।

एक sale के दौरान हमारी order API की latency अचानक बढ़ी और errors आने लगे। मैं on-call था। Dashboards देखे तो database connections भरे हुए थे। नुकसान रोकने के लिए मैंने उसी सुबह की release rollback की, जिसमें primary database पर एक report query जुड़ी थी। Rollback के बाद सब सामान्य हुआ। Incident channel में हर पंद्रह मिनट update दिया। बाद में blameless postmortem में तय हुआ कि reports read replica पर चलेंगी और slow queries पर alert लगेगा, जिसे मैंने अगले sprint में पूरा किया।

Internship में मैं एक ऐसी टीम में गया जिसका Java codebase लाखों lines का था। मैंने पहले उसे locally चलाया और debugger से एक request, order status update, को controller से database तक follow किया। जो समझा उसके notes बनाए और टीम के wiki में जोड़े। सवाल इकट्ठा करके दिन में एक बार अपने mentor से पूछता था, ताकि बार-बार उन्हें न रोकूं। पहले हफ़्ते छोटे bugs लिए जिनके tests थे। तीसरे हफ़्ते तक मैं एक छोटा feature अकेले ship कर रहा था।

मेरी current CTC में ज़्यादातर हिस्सा fixed है और बाकी performance bonus, और मैं salary slip दिखा सकता हूं। यह role senior engineer level का है, जिसमें system design की ज़िम्मेदारी और on-call भी है, जो मेरे अभी के काम से एक कदम ऊपर है। इसी को और recruiters से हुई बातचीत को देखते हुए मैं fixed हिस्से में साफ़ बढ़ोतरी की उम्मीद रखता हूं। मैं पूरा break-up देखकर बात करना चाहूंगा, क्योंकि मेरे लिए fixed pay, stock से ज़्यादा मायने रखती है।

जी हां, मैं हैदराबाद relocate करने को तैयार हूं। अभी मैं इंदौर में हूं और मेरी ऐसी कोई पारिवारिक मजबूरी नहीं है जो joining के एक महीने के अंदर शिफ़्ट होने से रोके। सच कहूं तो इस समय मुझे पूरी तरह remote से ज़्यादा hybrid पसंद है, क्योंकि नए engineer के तौर पर मैं सीनियर लोगों के पास बैठकर, उनके review और discussion सुनकर ज़्यादा तेज़ी से सीखता हूं। बस relocation support की जानकारी चाहूंगा।

मैंने चार साल एक services company में बिताए हैं और delivery और clients के साथ काम करना अच्छे से सीखा है। लेकिन मेरे ज़्यादातर projects handover पर ख़त्म हो जाते हैं, इसलिए मैं कम ही देख पाता हूं कि कोई system सालों तक बड़े scale पर कैसे चलता है, या उसकी architecture ख़ुद संभाल पाता हूं। मैं एक product टीम में जाना चाहता हूं जहां मैं अपने बनाए system को production में लंबे समय तक own करूं। आपका यह role ठीक यही देता है।