Meta میں سسٹم ڈیزائن انٹرویو سوالات

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

• نیوز فیڈ ڈیزائن کریں۔ رینکنگ، fanout on write بمقابلہ fanout on read، اور لاکھوں فالوورز والے اکاؤنٹس کے لیے کیا ہوتا ہے۔
• میسجنگ یا چیٹ سسٹم ڈیزائن کریں۔ ڈیلیوری گارنٹیز، ترتیب، presence، اور ڈیوائسز کے درمیان آف لائن سنک۔
• نوٹیفیکیشن سسٹم ڈیزائن کریں۔ deduplication، batching، فی صارف ریٹ لمٹس، اور push، ای میل، اور in-app کے ذریعے ڈیلیوری۔
• نیئربائی فرینڈز یا لوکیشن فیچر ڈیزائن کریں۔ جیو اسپیشل انڈیکسنگ، اپ ڈیٹ فریکوئنسی، اور پرائیویسی ماڈل۔
• سرچ یا ٹرینڈنگ کمپوننٹ ڈیزائن کریں۔ کوئری لیٹنسی کے مقابلے میں انڈیکس کی تازگی۔

کچھ انٹرویو پراسیس اسے product architecture ورژن میں تقسیم کرتے ہیں جو یوزر فیسنگ رویے کے قریب رہتا ہے۔ اپنے ریکروٹر سے پوچھیں کہ آپ کو کون سا ملے گا، کیونکہ تیاری مختلف ہوتی ہے۔

ناکامی کا انداز دوسرے منٹ میں ہی باکسز بنانا ہے۔ ایک قابل عمل تقسیم: ضروریات اور scope واضح کریں، API اور ڈیٹا ماڈل کا خاکہ بنائیں، ہائی لیول آرکیٹیکچر بنائیں، پھر وہاں گہرائی میں جائیں جہاں انٹرویو لینے والا اشارہ کرے۔

• پہلے ضروریات۔ کون سے صارفین، کون سے پلیٹ فارمز، read-heavy یا write-heavy، اور واضح طور پر آپ کیا نہیں بنا رہے۔
• پھر نمبرز۔ تقریباً یومیہ ایکٹیو صارفین، ریکوئسٹ ریٹس، اور payload سائز، تاکہ بعد کے ٹریڈ آفس کی کوئی بنیاد ہو۔
• ڈایاگرامز سے پہلے ڈیٹا ماڈل۔ entity کیسی نظر آتی ہے اور اس سے کیسے کوئری کی جاتی ہے، عام طور پر آرکیٹیکچر کا فیصلہ کرتا ہے۔
• ایک گہرا جائزہ۔ توقع رکھیں کہ آپ کو ایک ہی کمپوننٹ کی طرف لے جایا جائے گا اور پوچھا جائے گا کہ یہ کیسے ناکام ہوتا ہے۔

اپنے مفروضات بلند آواز میں بیان کریں۔ جو انٹرویو لینے والا کسی مفروضے سے متفق نہ ہو وہ اسے درست کر دے گا، جو مفت معلومات ہے؛ ایک غیر بیان کردہ مفروضہ محض ایک خلا لگتا ہے۔

اوسط جوابات ایک درست آرکیٹیکچر بیان کرتے ہیں۔ مضبوط جوابات اس ٹریڈ آف کا نام لیتے ہیں جسے انہوں نے قبول کیا اور اس ناکامی کا جسے وہ برداشت کرنے کو تیار ہیں۔ یہ کہنا کہ "میں fanout on write چن رہا ہوں کیونکہ یہاں reads کا غلبہ ہے، اور میں سیلیبرٹی اکاؤنٹس کے لیے سست writes قبول کر رہا ہوں، جسے میں الگ pull path سے سنبھالوں گا" ایک بہترین ڈایاگرام سے زیادہ کرتا ہے۔

ایک بیک اینڈ انجینئر کا تصور کریں جو سینیئر رول کے لیے انٹرویو دے رہی ہے۔ اسے نوٹیفیکیشن سسٹم ڈیزائن کرنے کو کہا جاتا ہے اور وہ پہلے چھ منٹ صرف ضروریات پر گزارتی ہے: کیا ایک صارف کو ایک ایونٹ کے لیے دو نوٹیفیکیشنز مل سکتی ہیں، کیا ترتیب اہم ہے، retention window کیا ہے۔ انٹرویو لینے والا بعد میں کہتا ہے کہ deduplication کی بحث راؤنڈ کا فیصلہ کن حصہ تھی، اور وہ کبھی ایک صفحے کے ڈایاگرام سے آگے نہیں بڑھی۔

اس بیانیے کی مشق میز پر اکیلے کرنا مشکل حصہ ہے۔ آپ /mock-interview صفحے پر AI انٹرویو لینے والے کے سامنے ڈیزائن سوالات چلا سکتے ہیں اور سوچتے ہوئے بولنے کے عادی ہو سکتے ہیں۔

بولے جانے والے ویڈیو راؤنڈ میں، SubcueAI انٹرویو لینے والے کے سوال کو ٹرانسکرائب کرتا ہے اور آپ کی طرف ایک تجویز کردہ ساخت دکھاتا ہے، macOS اور Windows پر ڈیسک ٹاپ اوورلے میں یا Chromium براؤزر ایکسٹینشن کے سائیڈ پینل میں۔ کوئی میٹنگ بوٹ کال میں شامل نہیں ہوتا، اور میٹنگ پیج میں کچھ بھی انجیکٹ نہیں کیا جاتا۔ ڈیزائن راؤنڈ کے لیے حقیقی فائدہ ایک چیک لسٹ ہے جسے آپ دباؤ میں مسلسل بھول جاتے ہیں، جیسے capacity estimate یا failure mode، نہ کہ ایک ایسا جواب جسے آپ بلند آواز میں پڑھیں۔

حدود سخت ہیں۔ ڈیزائن راؤنڈز عام طور پر ایک شیئرڈ whiteboard ٹول پر چلتے ہیں جس میں آپ کی اسکرین شیئر ہوتی ہے، اور آپ کی اسکرین پر جو کچھ بھی ہو وہ پینل کو نظر آتا ہے۔ ایک تیار شدہ جواب پڑھنا بھی فوری طور پر ناکام ہو جاتا ہے، کیونکہ انٹرویو لینے والے کا اگلا سوال ہوتا ہے "دوسرا اپروچ کیوں نہیں؟"۔ دوسرے آجرین کے لیے متعلقہ انٹرویو پراسیس company interviews topic میں موجود ہیں۔