Data Engineer انٹرویو سوالات، راؤنڈ کے مطابق

ہو سکتا ہے آپ اسی طرح تیاری کر رہے ہوں جیسے software engineering لوپ کے لیے کرتے، اور سوچ رہے ہوں فرق کیا ہے۔ یہ سیکشن ان راؤنڈز کا نقشہ بناتا ہے جو یہ انٹرویوز بار بار استعمال کرتے ہیں، تاکہ آپ اپنا وقت ان دو راؤنڈز پر لگا سکیں جو واقعی امیدواروں کو الگ کرتے ہیں۔ ٹیکنیکل فلٹر پر شاذ و نادر ہی آفر ضائع ہوتی ہے۔

• SQL۔ Window functions، deduplication، اور query performance، عموماً لائیو۔
• Data modelling۔ بیان کردہ کاروبار کے لیے ٹیبلز ڈیزائن کرنا، اور منتخب کردہ grain کا دفاع کرنا۔
• Pipeline اور ETL ڈیزائن۔ ایک اوپن اینڈڈ system design راؤنڈ جو ڈیٹا کی نقل و حرکت پر مرکوز ہے۔
• Distributed processing۔ ایک framework آپ کا کام دراصل کیسے چلاتا ہے، اور یہ سست کیوں ہے۔
• Coding۔ Python یا Scala، اکثر software engineering راؤنڈ سے ہلکا۔
• Behavioral۔ On call واقعات، ٹوٹے ہوئے ڈیش بورڈز، اور اسٹیک ہولڈرز جو کل ہی نمبر چاہتے تھے۔

عہدوں کے نام analytics engineering اور platform کرداروں سے کافی حد تک ملتے جلتے ہیں، اس لیے مکسچر بدلتا رہتا ہے۔ متعلقہ کردار بینکس interview questions by role ہب پر موجود ہیں۔

SQL

• ایک ٹیبل کو deduplicate کریں تاکہ ہر key کے لیے صرف تازہ ترین row باقی رہے۔
• ایک query لکھیں جو ہر user کے session کی تعداد 30 منٹ کے inactivity gap کے ساتھ لوٹائے۔
• ایک ہی query میں running total اور مہینہ بہ مہینہ تبدیلی نکالیں۔
• وہ rows تلاش کریں جو کل کے snapshot میں موجود تھیں مگر آج غائب ہیں۔
• QUALIFY کیا کرتا ہے، اور اس کے بغیر آپ کیا لکھیں گے؟
• یہ query ایک ارب rows اسکین کرتی ہے اور بیس منٹ لیتی ہے۔ آپ اس کی تشخیص کیسے کریں گے؟
• Partitioning اور clustering کا فرق بیان کریں، اور ہر ایک کب مدد دیتا ہے۔

Data modelling

• ایک آن لائن مارکیٹ پلیس کی آرڈر ہسٹری کے لیے ٹیبلز ڈیزائن کریں۔ آپ کے fact table کا grain کیا ہے؟
• ایک star schema بیان کریں، اور کب آپ جان بوجھ کر مزید denormalise کریں گے۔
• Slowly changing dimension کیا ہے، اور آپ type two کیسے نافذ کریں گے؟
• ایک اسٹیک ہولڈر چاہتا ہے کہ تاریخی رپورٹنگ گاہک کے موجودہ region کی عکاسی کرے۔ کیا ٹوٹے گا؟
• آپ ایک event stream کو کیسے ماڈل کریں گے جو out of order آتی ہے؟
• آپ normalised ماڈل کی بجائے wide table کب منتخب کریں گے؟

Modelling راؤنڈ ایک grain طے کرنے اور اس کا دفاع کرنے پر انعام دیتا ہے۔ وہ امیدوار جو بغیر منتخب کیے تین ممکنہ ڈیزائن بیان کرتے ہیں، ان امیدواروں سے کم اسکور کرتے ہیں جو ایک معقول ڈیزائن چن کر اس کی کمزوری بتاتے ہیں۔

Pipeline اور ETL ڈیزائن

• ایک pipeline ڈیزائن کریں جو روزانہ transactions کو رپورٹنگ کے لیے warehouse میں لوڈ کرے۔
• upstream ماخذ کل کا ڈیٹا دوبارہ بھیج دیتا ہے۔ آپ کے کام کا کیا ہوگا؟
• آپ ایک pipeline کو idempotent کیسے بناتے ہیں، اور reruns کے لیے یہ کیوں اہم ہے؟
• آپ روزانہ لوڈ میں خلل ڈالے بغیر دو سال کی ہسٹری کیسے backfill کریں گے؟
• Late arriving data partition بند ہونے کے تین دن بعد ظاہر ہوتا ہے۔ آپ کیا کریں گے؟
• آپ کیسے پتا لگائیں گے کہ ایک pipeline کامیاب ہوئی مگر غلط ڈیٹا پیدا کیا؟
• آپ کیا مانیٹر کرتے ہیں، اور رات تین بجے کسی کو کیا page کرتا ہے؟

Distributed processing اور streaming

• Shuffle کس چیز کی وجہ سے ہوتا ہے، اور یہ مہنگا کیوں ہے؟
• آپ کا کام سست ہے اور ایک task باقیوں سے کہیں زیادہ وقت لیتا ہے۔ کیا ہو رہا ہے؟
• Data skew اور اسے سنبھالنے کے دو طریقے بیان کریں۔
• آپ شیڈول شدہ batch job کی بجائے streaming کب منتخب کریں گے؟
• Exactly once processing دراصل کیا ضمانت دیتا ہے، اور کہاں یہ برقرار نہیں رہتا؟
• Watermarks ایک windowed aggregation میں out of order events کو کیسے سنبھالتے ہیں؟

غور کریں کہ ان میں سے کتنے کم سوالات آپ سے کسی ٹول کا نام مانگتے ہیں۔ ایک ٹول کا نام لینا جواب کی شروعات ہے، جواب نہیں۔ اگلا سوال ہمیشہ ہوتا ہے کیوں، اور کیا ٹوٹے گا۔

یہ فہرستیں پڑھنا پہچان پیدا کرتا ہے۔ design راؤنڈز کچھ اور جانچتے ہیں: ایک نظام کو ذہن میں رکھنا جبکہ کوئی آپ کو failure case سے روکتا ہے۔ یہ صلاحیت صرف ڈیزائن بلند آواز میں بیان کرنے سے آتی ہے۔

• پندرہ منٹ میں ایک pipeline بنائیں اور بیان کریں۔ Source، landing، transform، serve، اور ہر مرحلہ کیسے ناکام ہوتا ہے۔
• اپنے ہی ڈیزائن پر حملہ کریں۔ ہر پریکٹس رن کے بعد پوچھیں کہ rerun پر، late data پر، اور schema تبدیلی پر کیا ہوتا ہے۔
• اسکیل کے لیے ایک نمبر تیار رکھیں۔ فی دن rows، سائز، latency بجٹ۔ پہلے اپنا فرض کردہ اسکیل بیان کرنا اسکور کیا جاتا ہے۔
• SQL ہاتھ سے لکھیں۔ لائیو راؤنڈز اکثر ایک سادہ ایڈیٹر استعمال کرتے ہیں جس میں autocomplete اور execution نہیں ہوتا۔
• ایک واقعے کی کہانی اچھی طرح مشق کریں۔ کیا ٹوٹا، آپ نے اسے کیسے دریافت کیا، آپ نے کیا بدلا تاکہ یہ دوبارہ نہ ہو۔

batch pipelines پر چھ سال کے تجربے والی ایک data engineer نے framework کے internals کا جائزہ لے کر تیاری کی، پھر "upstream ماخذ نے کل کی فائل دوبارہ بھیج دی" پر اٹک گئی کیونکہ اس نے یہ کام ہمیشہ ہاتھ سے سنبھالا تھا، کبھی اسے بیان نہیں کیا تھا۔ علم موجود تھا؛ بولا ہوا جواب موجود نہ تھا۔ Follow-up سوالات کے ساتھ design راؤنڈ کی مشق کرنا بالکل وہی ہے جس کے لیے mock interview موڈ بنایا گیا ہے۔