هیچ چیز به اندازه دیدن ویدئو خوب آخر شب حال نمیده :

Software Engineering Mock Interview (Python3)

پ.ن : چیزایی که بنظرم طرف اشتباه می‌کنه رو هم بذارم :
مثلا همین ابتدای دقیقه ۶ باید می‌پرسید آیا یک یوزر می‌تونه چندین

Active book 

داشته باشه ؟ (یک سری سوالات پرسیده نمی‌شه چون مثال kindle زده شده اما اگر طرف با این سرویس آشنایی نداشته باشه می‌تونه اعلام کنه و درخواست اطلاعات بیشتر کنه)
دقیقه ۱۱ این سوال رو می‌پرسه و طرف اعلام می‌کنه بله باید اینطوری باشه (این موضوع دید کلی و همه جانبه داشتن خیلی خیلی مهمه بخصوص اگر برای سطوح بالاتر دارید مصاحبه می‌کنید)

دقیقه ۹: برای page/content ساختمان داده list رو پیشنهاد میده و دلیل میاره که چرا باقی موارد نه؛ اما بنظرم من tuple درست تر بود (چون محتوای یک صفحه از کتاب بعد از انتشار تغییر نمی‌کنه و البته tuple از نظر حافظه بسیار بصرفه تر از list هست)
جلوتر یادش افتاد و اشاره کرد؛ برای راحتی لیست رو انتخاب کرد (بله این هم اتفاق درستی هست توی مصاحبه) شما درست ترین راهکار رو اول ارائه میدی بعد می‌تونه بپرسی آیا اجازه داری که راهکاری که ساده‌تر هست رو استفاده کنی توی پیاده‌سازی یا خیر

دقیقه ۱۲: من بودم بجای گرفتن id برای هر کتاب از isbn استفاده میکردم دلیلش هم این هست که هم روی فیچری برای جستجو کمک می‌کنه و هم unique هست و نیازمندی لازمه برای active books رو هم برطرف می‌کنه؛
پس ی اشتباه دیگه طرف راجب فیچرهایی مثل

Recommendation, Search 

سوالی نکرده و فیلدی هم درنظر نگرفته تا اینجا

دقیقه ۱۵: از اونجایی که توی پایتون ساختار داده dict دیگه بصورت دیفالت order هم داره میشه ازین ساختار هم برای نگهداری صفحات کتاب استفاده کرد (بخصوص اینکه اینجا تعداد سرچ ممکنه زیاد باشه)
هرچند من نیاز ویژه‌ای نمی‌بینم اما گفتن این نکته نشون میده شما به فیچرهای جدید‌تر زبانی که باهاش کد میزنید هم آشنا هستید و تغییراتش رو دنبال می‌کنید (این موضوع رو توی مصاحبه با آمازون داشتم و براش امتیاز قائل بودند)

دقیقه ۱۵ : شروع کرد به کد زدن و با فیلدهای کمینه شروع کرد متاسفانه کیندل تصویر اصلی کتاب رو بصورت thumbnail نمایش میده؛ اسم نویسنده می‌تونست موضوع جذابی برای جستجو باشه؛ میشد به این نکته اشاره کرد که آیا نیاز به جستجو بر اساس متن داخل کتاب داریم ؟ یا اینکه برای ساده‌سازی می‌تونید ازش بگذریم و ....

اضافه کنم این بسیار مهم هست که پروژه رو بیش از حد سخت و سنگین نبینید (خود این هم امتیاز منفی داره) و این موضوعات رو بسیار سریع بهش اشاره کنید و ازش بگذرید مخصوصا تو این مرحله که system desing نیست (هرچند این لول از جزئیات رو من بیشتر با اسم micro-service desing باهاش موافق هستم توی طراحی سیستم هم نباید انقدر درگیر جزئیات بشید و واقعا یک تله هست.)

دقیقه ۱۷:۵۰ : ازش متدی برای ورق زدن کتاب خواسته شد turn_page که خب طرف فراموش کرد برای برگشت به عقب کدی بزنه (یعنی این ویژگی در واقع نیاز به ۲ تا متد داشت با توجه به مدل پیاده سازی این خانوم)

توی دقیقه ۲۰ که داره Library رو میسازه؛ بنظرم ۲ تا سوال رو جا انداخت؛ چرا من زودتر به این اشاره نکردم ؟ چون طرف گفت kindle من رفتم سمت نسخه‌ی‌ قدیمی که میشناختم و همه چیز رو روی دیوایس هر نفر ذخیره میکرد اما این خانم به API هم اشاره کرد پس :
۱- می‌تونست ی نسخه جامع‌تر از Library در نظر بگیره که شامل همه کتابها باشه؛ باز چون گفته شد اطلاعات کتاب بهش داده میشه فرض میکنم اون بخش روی یک سرویس دیگه که اسمش رو بذاریم core پیاده سازی شده
۲- با فرض اینکه مورد قبلی تایید بشه پس نیازی به Authorization توی این سرویس نداریم پس می‌تونه
Add to collection
همینطوری پیاده سازی بشه (هر کاربر یک کپی از کتاب نه مجوزی برای دسترسی به کتاب)
الان دیگه مطمئن شدم که سطح مصاحبه midlevel هست چون طرف تو این دقیقه از مصاحبه نباید دیگه از API حرف میزد (ازون جایی که mock interview ها همیشه یک بکگراند قبلی داره فکر میکردم بسته شده که قرار نیست API یا microservice باشه)
این خیلی مهمه توی مصاحبه هر فرضیه‌ای که تایید نگیرد غلط هست و شما دارید مسیر اشتباه رو میرید؛ برای همین من به همه شاگردام و دوستانی که باهاشون مصاحبه کار میکردم همیشه گفتم یاد بگیرید توی جلسه مصاحبه بلند بلند فکر کنید اهمیت این موضوع 10/10 هست یعنی از خود کدهاتون هم با ارزش تر
چون شاید شما نرسید توی تایم مصاحبه کد رو تکمیل کنید (که خب چیز اشتباهی نیست مگر در شرایط خاص) اما اگر بلند بلند تفکر کرده باشید و مصاحبه کننده بدونه به چی فکر کردید؛ نوع کد زدنتون رو هم که تا اینجا دیده احتمالش بسیار زیاد هست که نمره کامل رو براتون رد کنه و خدا می‌دونه که این امتیاز چقدر مهم و کمک کننده هست.


باقی در کامنت‌ها :