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

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

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

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

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

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

डेटा इंजीनियर इंटरव्यू प्रोसेस कैसा दिखता है?

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

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

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

डेटा इंजीनियर इंटरव्यू में पाइपलाइन डिज़ाइन के कौन से सवाल आते हैं?

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

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

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

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

बैच या स्ट्रीमिंग: आर्किटेक्चर वाले सवाल का जवाब कैसे दें?

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

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

इवेंट टाइम और प्रोसेसिंग टाइम में क्या फर्क है? यह क्या टटोलता है: स्ट्रीमिंग की बुनियाद। इवेंट टाइम वह है जब घटना हुई; प्रोसेसिंग टाइम वह है जब आपके सिस्टम ने उसे देखा। प्रोसेसिंग टाइम पर विंडो किए गए एग्रीगेट खिसक जाते हैं और चुपचाप सोर्स ऑफ ट्रुथ से अलग नतीजे देने लगते हैं।

किसी स्ट्रीमिंग पाइपलाइन में exactly-once सिमैंटिक्स आप कैसे लाएंगे? यह क्या टटोलता है: क्या आप मार्केटिंग दोहरा रहे हैं या मैकेनिक्स समझा रहे हैं। शुरू से आखिर तक आप at-least-once डिलीवरी के साथ idempotent राइट्स बनाते हैं, एक डिटरमिनिस्टिक की का इस्तेमाल करके, ताकि रीप्ले डुप्लिकेट बनाने के बजाय ओवरराइट करे। ट्रांज़ैक्शनल सिंक और राइट के साथ कमिट होने वाले ऑफसेट इसे असल में मुमकिन बनाते हैं।

डेटा मॉडलिंग के कौन से सवाल आपको उम्मीद करने चाहिए?

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

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

स्लोली चेंजिंग डाइमेंशन को आप कैसे मॉडल करते हैं? यह क्या टटोलता है: हिस्ट्री। टाइप 1 ऊपर से लिख देता है और अतीत खो देता है; टाइप 2 हर वर्ज़न के लिए एक रो जोड़ता है, वैलिडिटी डेट और एक करंट फ्लैग के साथ, और यही ज़्यादातर एनालिटिक्स टीमों को पॉइंट-इन-टाइम रिपोर्टिंग के लिए चाहिए।

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

डेटा इंजीनियर के लिए SQL राउंड कितना गहरा जाता है?

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

हर ग्रुप में दूसरी सबसे बड़ी वैल्यू निकालिए, जैसे हर डिपार्टमेंट में दूसरा सबसे ज़्यादा सैलरी पाने वाला व्यक्ति। यह क्या टटोलता है: विंडो फंक्शन पर पकड़। किसी सबक्वेरी में DENSE_RANK या ROW_NUMBER उठाइए और रैंक पर बाहर फिल्टर लगाइए, फिर बताइए कि आपने कौन सा चुना और क्यों, क्योंकि टाई दोनों में अलग तरह से बर्ताव करते हैं।

किसी टेबल को इस तरह डिडुप्लिकेट कीजिए कि हर की के लिए सिर्फ सबसे नई रो बचे। यह क्या टटोलता है: नौकरी का सबसे आम असली काम। की से पार्टिशन किया गया ROW_NUMBER, टाइमस्टैम्प के घटते क्रम में, और 1 पर फिल्टर। फिर पूछिए कि दो रो का टाइमस्टैम्प एक ही हो तो टाई कैसे टूटेगा, क्योंकि असली डेटा में ऐसा होगा ही।

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

इंटरव्यूअर ऑर्केस्ट्रेशन के कौन से सवाल पूछते हैं?

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

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

अलग-अलग टीमों की पाइपलाइनों के बीच डिपेंडेंसी आप कैसे संभालते हैं? यह क्या टटोलता है: क्या आपने किसी असली संगठन में काम किया है। उम्मीद पर टिके शेड्यूल ऑफसेट के बजाय कोई साफ सिग्नल चुनिए (डेटासेट पर पूरा होने का निशान, कोई इवेंट, या टाइमआउट वाला सेंसर)।

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

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

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

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

कोई अपस्ट्रीम सोर्स बिना बताए किसी कॉलम का टाइप बदल देता है। आप क्या करेंगे? यह क्या टटोलता है: अपने काबू से बाहर की चीज़ों से निपटना। चुपचाप टाइप बदलने के बजाय इनजेशन पर ही स्कीमा चेक से तुरंत फेल कीजिए, खराब बैच को अलग रखिए, फिर रीप्ले के साथ आगे बढ़कर ठीक कीजिए।

डेटा इंजीनियर से कौन से बिहेवियरल सवाल पूछे जाते हैं?

डेटा रोल्स के बिहेवियरल राउंड भरोसे और स्टेकहोल्डर पर टिके होते हैं। ऐसे किसी हादसे का सवाल उम्मीद कीजिए जहां आपका डेटा गलत था, और एक ऐसी मांग का जिसे आपने ठुकराया। कसे हुए ढांचे में जवाब दीजिए: हालात, आपने क्या तय किया, कौन सा ट्रेडऑफ स्वीकार किया, और उसके बाद कौन सा टिकाऊ बदलाव आया।

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

मुझे ऐसी कोई मांग बताइए जो आपने ठुकराई, या घटाकर मानी। यह क्या टटोलता है: क्या आप सौ छोटे-छोटे अनुरोधों से प्लेटफॉर्म बचा सकते हैं। दिखाइए कि आपने असली जरूरत समझी, उस तक पहुंचने का सस्ता रास्ता दिया, और मूल मांग की कीमत सामने रखी, बजाय इसके कि सीधे मना करके वह टीम बन जाएं जिसे सब बायपास करने लगते हैं।

डेटा इंजीनियर कैंडिडेट किन गलतियों से डूबते हैं?

ज़्यादातर जानकारी की कमी से नहीं, समझ की चूक से। पैनल किसी खास टूल की जानकारी न होने पर कम ही रिजेक्ट करते हैं; वे उन लोगों को रिजेक्ट करते हैं जो पूछे बिना डिज़ाइन कर देते हैं, जो अपनी ही पाइपलाइन दोबारा नहीं चला सकते, या जो गलत आंकड़े को किसी और की समस्या मानते हैं। ये वे पैटर्न हैं जो राउंड खत्म कर देते हैं।

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

डेटा इंजीनियर इंटरव्यू की तैयारी कैसे करें?

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

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

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

डेटा इंजीनियर इंटरव्यू FAQ

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

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

किस राउंड का वज़न सबसे ज़्यादा है? मिड और सीनियर कैंडिडेट के लिए पाइपलाइन डिज़ाइन, क्योंकि यह एक साथ समझ, संवाद और गहराई परखता है। जूनियर रोल्स के लिए असली गेट SQL स्क्रीन है, और ज़्यादातर रिजेक्शन वहीं होते हैं।

जिस टूल का वे ज़िक्र करें, अगर मैंने उसे इस्तेमाल नहीं किया तो क्या मान लेना चाहिए? हां। “मैंने इसे प्रोडक्शन में नहीं चलाया है, पर मैं इस पर कैसे सोचूंगा और सबसे पहले क्या जांचूंगा, वह बता सकता हूं” बहाने से कहीं बेहतर है, और डेटा इंटरव्यूअर गोलमोल बातें पकड़ने में असामान्य रूप से माहिर होते हैं क्योंकि उनका पूरा दिन गलत चीज़ें ढूंढने में ही बीतता है।