مصاحبه System Design اوبر

توی یکی از مقاله‌هایی که اخیرا خوندم، نویسنده تجربه رد شدنش در مصاحبه طراحی سیستم Uber رو توضیح داده بود. مسئله‌ای که بهش داده بودن طراحی یک Real-time Surge Pricing Engine بود؛ سیستمی که باید میلیون‌ها GPS Ping رو پردازش کنه، نسبت عرضه و تقاضا رو برای هر ناحیه محاسبه کنه و هر چند ثانیه ضریب Surge رو به‌روزرسانی کنه. بخش اصلی مصاحبه صرفا طراحی معماری نبود. از همون ابتدا انتظار داشتن قبل از کشیدن هر چیزی، درباره Requirements، SLA، Failure Mode، Latency، Scale و Trade-offها سوال بپرسه.

نکته‌ای که به نظرم جالب بود اینه که مصاحبه‌کننده بیشتر از اینکه دنبال اسم ابزارها یا الگوهای معماری باشه، دنبال منطق پشت تصمیم‌ها بود. سؤال‌هایی مثل «اگر سیستم از کار بیفته چه اتفاقی می‌افته؟»، «دقت مهم‌تره یا سرعت؟»، «چرا این راهکار رو انتخاب کردی؟» و «اولین Bottleneck سیستم کجاست؟» بخش اصلی مصاحبه رو تشکیل می‌دادن. در نهایت هم بازخوردی که نویسنده گرفت این بود که دانش فنی خوبی داشته، اما عمق کافی در تحلیل Edge Caseها و Trade-offها رو نشون نداده بود.

لینک مقاله

@techstuff100