فضای مصاحبه و رفتار مصاحبه‌کننده خوب بود؛ ولی با اینکه سوال رو حل کرده بودم، در پایان مصاحبه حس خوبی نداشتم.

حدود یک ماه از مصاحبه گذشت و خبری از ایمیل پذیرش یا رد شدن نیومد. فکر کردم که رد شدم و تقریبا بی‌خیال قضیه شده بودم که دوباره تماس گرفتن برای هماهنگی مصاحبه دوم (مصاحبه فنی) که اواخر شهریور برگزار شد. این مصاحبه یک ساعته بود و از طریق Skype انجام شد.

برخی از سوال‌هایی که پرسیده شد:
۱. مفهوم event loop
۲. اسکوپ‌ها (scope) و TDZ
۳. خروجی کد (پست بعدی)
۴. روش‌های ذخیره‌سازی داده در مرورگر و تفاوت‌هاشون
۵. هدر set-cookie
۶. مفهوم event bubbling
۷. استفاده از preventDefault برای تگ‌های a
۸. مفاهیم debounce و throttle
۹. پوزیشن‌های CSS
۱۰. قوانین هوک‌ها
۱۱. توضیح useEffect و useLayoutEffect و تفاوت‌هاشون
۱۲. توضیح توابع cleanup در useEffect
۱۳. توضیح event batching
۱۴. مفاهیم LCP، CLS و Performance وب
۱۵. مفاهیم و جزئیات memo و useMemo
و ۳-۴ تا سوال دیگه که دقیق یادم نیست.

فرایند مصاحبه بیشتر شبیه به یک گفت‌وگوی فنی بود و در فضایی صمیمی پیش رفت. مصاحبه‌کننده هم بسیار حرفه‌ای و خوش‌برخورد بودن.

نتیجه‌ی مصاحبه حدود یک هفته بعد از طریق ایمیل اعلام شد. این مصاحبه برام تجربه خیلی خوبی بود و چیزهای زیادی یاد گرفتم.

@techstuff100

سوال ۳

@techstuff100

فایل .gitattributes در گیت

ممکنه پیش بیاد یه پروژه رو کلون کنیم، بعد ببینیم یه سری فایل EOL (End Of Line) عجیب‌غریب باز می‌شن یا وقتی diff می‌گیریم پر از تغییرات بی‌ربطه. توی این موقعیت فایل .gitattributes می‌تونه کمک‌مون کنه.

فرض کنید توی یه تیمی کار می‌کنیم که اعضاش رو ویندوز، مک و لینوکس هستن. هر کی با ادیتور و تنظیمات خودش. حالا یه نفر یه فایل .bat می‌نویسه که رو ویندوز باید با CRLF باشه، ولی یکی دیگه با LF کامیتش می‌کنه، و اسکریپت دیگه اجرا نمی‌شه. یا مثلا یه فایل go رو که باید با LF باشه، یکی دیگه با CRLF ذخیره کرده. با .gitattributes می‌تونیم از این ناهماهنگی‌ها جلوگیری کنیم و یه سری قانون برای Git تعریف کنیم که همه اعضای تیم رعایتش کنن.

توی این مثال تعریف کردم که:
- فایل‌های .bat باید همیشه با CRLF باشن.
- فایل‌های go فقط با LF ذخیره بشن.
- فایل‌های .png و .noscript هم باینری در نظر گرفته بشن تا Git نخواد روشون diff بگیره.

@techstuff100

از Accessibility Tree View تو DevTools کروم می‌تونیم برای بررسی دسترسی‌پذیری سایت‌مون استفاده کنیم. این ابزار نشون می‌ده یه المنت چجوری توسط screen reader خونده میشه؛ مثل role، name و ARIA attributes.
از DevTools پنل Elements و دکمه accessibility می‌تونیم فعالش کنیم.

@techstuff100

قفل خوش‌بینانه و بدبینانه (Pessimistic / Optimistic Locking)

گاهی وقتا نیاز داریم مطمئن باشیم داده‌ای که داریم تغییرش می‌دیم، وسط کار توسط کس دیگه‌ای دستکاری نشده. چنین مواقعی قفل‌گذاری (Locking) می‌تونه کمکمون کنه.۲ تا از انواع قفل، قفل خوش‌بینانه (Optimistic) و بدبینانه (Pessimistic) هستن.

قفل بدبینانه از همون اول همه‌چی رو قفل میکنه تا مشکلی پیش نیاد. برای کارهای حساس مثل تراکنش مالی مناسبه یا وقتایی که رقابت روی آپدیت داده‌ها زیاده. ولی در عوض ممکنه سرعت سیستم بیاد پایین و کاربرای دیگه پشت صف بمونن. قفل خوش‌بینانه اما فرض می‌کنه که معمولا مشکلی پیش نمیاد، پس به همه اجازه می‌ده داده رو بخونن و تغییر بدن، و آخر سر بررسی می‌کنه که کسی وسطش تغییری نداده باشه. این روش تو جاهایی که بیشتر عملیات خوندنیه خیلی خوب جواب می‌ده.

لینک مقاله:
https://newsletter.systemdesigncodex.com/p/pessimistic-vs-optimistic-locking

@techstuff100

برای ساخت این پست از این مقاله و این ویدئو کمک گرفته شده.

@techstuff100