اولا که سعی کنید پست کدینگ چلنج crypto و student app و لایو منو ببینید حتما چون توش خیلی نکات زیادی گفته شده.
تجربه شخصی خودم از روند مصاحبه و نصیحت هایی که به مانی 3 ماه پیش میکردم 😁
اولین و مهم ترین چیز همینه. این تجربم برمیگرده به مصاحبه اولم. لایو کدینگی که یک ساعت بود ولی 2 ساعت و نیم طول کشید 😂😂. آخر لایو کدینگ هم که 95درصد کدو نوشته بودم منو متوقف کرد و گفت کافیه. به من یک کدی نشون داد که همون کاری که من میخواستم بکنم رو تو 15 خط کد پایتون میکرد. من گفتم ریجکت شدم تموم شد رفت. پس فرداش آفر کاریش اومد و الان تو همون شرکت کار میکنم. گفت اگه رو پروداکشن اینطوری overengineer کنی دارت میزنم :)). شما با overengineer کردن تو لایو کد چلنج یا assigement مهارتتون رو show off میکنید و طبیعتا اجازه میده بهتون که نسبت به بقیه کاندید ها که تلاش داشتن KIS رو رعایت کنند جلو بیفتین و اون طرف متوجه شه که شما از کجا میاین (ترجمه I see where you're coming from😁) ریپوش اینجاست. اینکه چرا انتخاب شدم هم خوش یک سکشن جداست.
2. Try new technologies, don't be afraid of rejection
اینکه قبلا جنگو کار کردین ولی برای fast اقدام نمیکنید اشتباهه بنظرم. اگه اشتیاق کار کردن با اون استکو دارین حتما اپلای کنید. ملاک استخدام فقط بلد بودن و تسلط رو اون تکنولوژی نیست خیلی وقتا شانس اینو دارین رو تکنولوژی آفر بگیرین که شاید خیلی روش مسلط نیستین و صرفا آشنا هستین در صورتی که تو job requirement نوشته مسلط. مثال بارزش دوباره از خودم میزنم. من همیشه rest کار کردم. کل بک شرکتی که داشتم براش اپلای میکردم graphql بود و خیلی تاکید داشت روی تجربه با graphql. تو مصاحبه اول اصلا اشاره نکردم به اینکه هیچی از graphql بارم نیست. تو مرحله assignment یک هفته داکشو خوندم. شاید باورتون نشه ولی جاب آفر از اون پوزیشنم گرفتم :)) . پس دلیل نمیشه شما یک چیزی رو بلد نیستین تو آگهی بهش اشاره شده اپلای نکنید. تهش اینه که با اون تکنولوژی آشنا میشین.
3. THINK, THEN CODE
این از همه مهم تره. مهم ترین چیز critical thinking هست براشون. اینکه شما صرفا هدفتون انجام اون تسک نباشه. هدفتون هدف اون تسک باشه. حتی نیازی نیست از راهی که اشاره شده تو داکیومنت assignment برین. مثلا برای همین graphql پجینشن میخواست که من از راه حلی که خودش معرفی کرده بود نرفتم چون بنظره من اورلود نتورک داشت. راه حلشو تغییر دادم و یکی از دلایل اصلی قبول شدنم همین بود. یا اینکه مثلا درخواست رو نگفته بود async بزن ولی من درخواست اول رو sync میزدم که ببینم چند تا آیتم داریم بگیریم بعد به تعداد درخواست ها همرو تو سری دوم باهم async میزدم (که network efficient هم باشه و الکی اسپم نکنه). سورس کد ریپو. همه اینا نشون داد که به صورت مسئله حسابی فکر کردم. تو پوینت اولم فقط OVER-ENGINEER نکردم به صورت مسئله هم حسابی فکر کردم. سعی کردم تا جایی که میشه efficient باشه حتی شده با نقض داکیومنت assignment. هیچ شرکتی دنبال کسی نیست که فقط کپی پیست کنه یا فقط کاری که بهش میگن رو انجام بده و تک بعدی باشه, کد نویس ایده آل کسیه که خیلی فکر میکنه و میتونه راهکار نو و بهتر از راهکار قدیمی بده. با وجود اینکه من سابقه کار fastapi به صورت حرفه ای نداشتم یا graphql بلد نبودم چون صرفا thinker بودنمو خوب نشون دادم تونستم به این موفقیت برسم. از نمونه ریجکتیم هم بخوام بگم باید بگم یک assignment ام ریجکت شد و حتی فیدبک هم نگرفت چون خوب روش فکر نکرده بودم و صرفا کاری که بهم گفته بودن رو به ساده ترین شکل ممکن پیاده سازی کردم (انگار که رفع تکلیف باشه).
The most damaging phrease in the language is 'its always been done this way' - Grace Hopper
یک اصلاحیه هم بکنم، تو over engineering همیشه باید در راستا بهتر شدن کد باشه، یعنی مثلا پروتکل بنویسید برای هر کلس template ای که دارین مینویسید، حتی اگه یک بار ازش استفاده میکنید.
از داک استرینگ و دیتا کلس استفاده کنید جای نوشتن query خام مثلا از orm استفاده کنید (تسکه کلا دو query داشت)
دیزاین داشته باشه کدتون، حتی اگه دیزاین داشتن نیاز نبوده و واسه دیزاین داشتن کد خیلی کم بوده (مگه کد ۱۵ خطی رو دیزاین میدن بهش؟ بله، تو روند استخدام باید بدید که نشون بدید مهارت کافی دارین برای نوشتن کد production quality)
ولی اینکه بخواین الکی کد عجیبی به پروژتون اضافه کنید که به هیچ دردی نمیخوره و فقط complicate ترش میکنه اونوقت اصلا اونکارو نکنید. Over engineer باید در جهت بالا رفتن کیفیت کد باشه