چیزهایی که نباید در مصاحبه فنی بگیم

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

۱. اینجا دقیقا چه کاری انجام میدید؟
نشون میده درباره شرکت، خوب تحقیق نکردیم. مثلا بهتره بگیم «اینجا چطور با نود کار می‌کنید؟».

۲. نمیدونم. تاحالا چنین کاری انجام ندادم.
نشون میده که وقتی با مشکلات جدید مواجه میشیم، بلاک میشیم و نمی‌تونیم حلشون کنیم. بهتره بگیم «نمیدونم ولی امتحانش می‌کنم تا ...».

۳. از اون محل متنفر بودم.
وقتی میپرسن که چرا از کار قبلیمون اومدیم بیرون، بهتره از اونجا (حداقل بطور رسمی) متنفر نباشیم؛ چون ممکنه باعث نشون دادن بدترین وجه خودمون بشه. بهتره روی چیزای مثبت و چیزایی که از اونجا یاد گرفتیم تمرکز کنیم.

۴. هیچ‌کس دیگه از اون استفاده نمی‌کنه.
از عبارات قطعی استفاده نکنیم. چطور می‌تونیم با قاطعیت بگیم فلان چیز توی صنعت به این بزرگی دیگه استفاده نمیشه؟ اگه بگیم «تا جایی که من میدونم ...» بهتره.

۵. توی رزومه‌م گذاشتمش.
توی مصاحبه ممکنه درباره چیزی که چیزایی که توی رزومه‌مون نوشتیم بپرسن. نگیم که توی رزومه‌م هستش. مصاحبه‌کننده تنبل نیست.

۶. نه، هیچ سوالی ندارم.
مصاحبه فقط برای این نیست که اونا ما رو بشناسن. ما هم باید بشناسیمشون. پس سوالات مناسب داشته باشیم.

۷. من یه توسعه‌دهنده Reactم.
با این جمله داریم خودمون رو محدود به React می‌کنیم. ما توسعه‌دهنده هستیم و اصول برنامه‌نویسی رو بلدیم. تکنولوژی‌ها میان و میرن. این نشون میده ما انعطاف‌پذیریم.

۸. لینوکس؟ ازش متنفرم. عاشق ویندوزم.
متنفر بودن از تکنولوژی توی مصاحبه فنی یه چراغ قرمزه. ممکنه با یه چیزی حال نکنیم. ولی ابزار، ابزاره و باید با اونی که برای شرایط فعلیمون مناسبه پیش بریم.

#Skills_of_a_Successful_Software_Engineer

@techstuff100

قبلا بخش زیادی از کار برنامه‌نویسی صرفا این بود که بتونیم چیزی رو بسازیم و به مرحله اجرا برسونیم. الان با کمک AI ساختن نرم‌افزار راحتتر شده و تقریبا هرکسی می‌تونه یه خروجی قابل‌قبول تولید کنه. برای همین چیزی که اهمیت بیشتری پیدا کرده taste یا همون قدرت تشخیص کیفیت و تصمیم‌گیریه؛ اینکه بتونیم بهترین راه‌حل رو انتخاب کنیم و به هر چیزی که صرفا کار کنه راضی نشیم.

نویسنده میگه این مهارت از اشتباه کردن و یاد گرفتن از شکست‌ها بدست میاد. مشکل اینه که AI با حذف سختی‌های مسیر ممکنه فرصت یادگیری از همین اشتباهات رو هم ازمون بگیره.

[مقاله]

#recent_reads

@techstuff100

رویداد آشنایی با skill به همراه ساخت یک Skill شخصی

در زمان کد نویسی با Ai مفاهیمی مثل Skill و تاثیرش در خروجی چی هستش؟ ساختار skill ها به چه صورته؟ چطور میشه یک skill طراحی کرد؟ و از دسته سوالاتی که در زمان انتخاب و استفاده ممکنه براتون پیش بیاد رو توی این رویداد بررسی کردیم.

https://thealibigdeli.ir/r/hodrJn/

@thealibigdeli_channel
#event

توی بحث rate limiting دو تا رویکرد داریم. hard rate limiting و soft rate limiting. توی hard limit وقتی تعداد درخواست‌ها از حد مجاز رد بشه، درخواست‌های اضافه رد میشن و معمولا 429 (Too Many Requests) می‌گیریم یا حتی ممکنه با هدر Retry-After به کلاینت بگیم چه زمانی دوباره درخواست بفرسته. این روش مثلا برای محدود کردن ترافیک کاربران رایگان یا محافظت از اندپوینت‌های پرهزینه جوابه.

توی soft limit حتی بعد از رد شدن از سقف تعیین شده درخواست‌ها همچنان پردازش میشن. ولی در عوض می‌تونیم این رد شدن از محدودیت رو لاگ کنیم، هشدار بدیم یا اطلاعات مربوط به سهمیه مصرف‌شده رو توی response headerها برگردونیم. این روش بیشتر برای پلن‌های پولی و مشتری‌های سازمانی مناسبه که قطع شدن ناگهانی سرویس براشون مشکل‌سازه. البته که اگه همین مصرف اضافی هم درست کنترل نشه می‌تونه هزینه یا فشار زیادی به سیستم وارد کنه.

#system_design

@techstuff100

دو سه سالی میشه چیزایی که می‌خونم/می‌بینم/گوش میدم رو بصورت هفتگی ثبت می‌کنم. این کار باعث میشه که بدونم مثلا نسبت به هفته‌های پیش چطور عمل کردم. همینطور وقتی که این حس «چند وقته هیچ کار خاصی انجام ندادم» اومد سراغم حداقل بدونم که واقعیه یا ساخته ذهنمه. کوشیار عظیمیان هم توی یکی از لایوهاش در موردش صحبت کرده بود.

من توی گوگل داک نوشتمشون ولی احتمالا ابزار بهتری براش وجود داشته باشه.

@techstuff100

مفهومی وجود داره به اسم Chaos Engineering یا مهندسی آشوب. توش سعی می‌کنیم خرابی‌هایی رو که ممکنه توی دنیای واقعی اتفاق بیفتن، به‌صورت کنترل‌شده توی سیستم شبیه‌سازی کنیم. مثلا یکی از سرویس‌ها رو از دسترس خارج کنیم یا تاخیر شبکه رو بالا ببریم و ببینیم بقیه سیستم چه واکنشی نشون میده.

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

اینجا در موردش بیشتر بخونین.

#system_design

@techstuff100

توی backtracking جواب رو مرحله به مرحله می‌سازیم. الگوریتم هر وقت تشخیص بده که اون جواب جزئی نمی‌تونه منجر به یه جواب معتبر بشه، ازش backtrack می‌کنه. باهاش معمولا مسائل ترکیبیاتی مثل جایگشت‌ها (permutation) و ترکیب‌ها و پازل‌هایی مثل سودوکو رو حل می‌کنیم.

مسئله Letter Combinations of a Phone Number لیتکد رو هم می‌تونین برای تمرین backtracking حل کنین.

#algorithm

@techstuff100

اگه یه مهارت باشه که لازمه به خودمون اضافه کنیم تا ریسک شغلی مون کمتر بشه مهارت بررسی و investigate کردن proactive محصول برای بهبودشه. یعنی صبر نکنیم تا یکی بهمون بگه چی بسازیم و خودمون دنبال مشکل ها و فرصت های بهبود محصول بگردیم.

معمولا ما که سابقه کاری مون بیشتر مهندسی نرم افزار و برنامه نویسیه این یه زمین بازی کاملا جدیده و تجربه مون توش کمه.

برای اینکه یاد بگیریم چطور این کارو بکنیم خوندن این مطالب میتونه مفید باشه

1. The Product-Minded Software Engineer - Gergely Orosz
https://blog.pragmaticengineer.com/the-product-minded-engineer/

2. Product Discovery - Marty Cagan
https://www.svpg.com/product-discovery/

3. Continuous Discovery Habits - Teresa Torres
https://www.producttalk.org/continuous-discovery-habits/



@gocasts

حمله Password Spraying

این حمله نوعی از حمله brute force هست که در اون مهاجم یه پسورد یکسان رو روی تعداد زیادی اکانت تست می‌کنه. اثرگذاری این حمله هم به این برمی‌گرده که بعضی از کاربران از پسورد‌های ساده مثل "12345678" و یا "password" استفاده می‌کنن.

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

تفاوتش هم با brute force معمولی اینه که توی brute force معمولا پسورد‌های احتمالی مختلف روی یه اکانت تست میشن؛ ولی توی password spraying تعداد محدودی پسورد رایج و ساده روی تعداد زیادی اکانت تست میشن. برای همینه که وقتی که حمله انجام میشه، کلی کاربر بصورت یکجا هدف قرار می‌گیرن.

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

#cyber_security

@techstuff100

چند روزی هست دارم کتاب Dive Into Design Patterns از Alexander Shvets رو می‌خونم. بعد Grokking Algorithms می‌خواستم یه کتاب دیگه رو شروع کنم؛ ولی چون چند بار توی ایونت‌های مهندس بیگدلی بهش اشاره شده بود گفتم ترتیب مطالعه‌م رو عوض کنم و اول اینو شروع کنم.

#Dive_Into_Design_Patterns

@techstuff100

استراتژی‌های دیپلوی

توی این ویدئو درباره چند روش رایج دیپلوی در نرم‌افزار صحبت کردم؛ اینکه مزایا و معایب هرکدوم چی هست و چطور کار می‌کنن. مواردی که درباره‌شون صحبت کردم:
- دیپلوی Big Bang
- دیپلوی Rolling Update
- دیپلوی Blue-Green
- دیپلوی Canary

ویدئوی یوتوب:
https://www.youtube.com/watch?v=w4ZehzZIDsc&list=PLG_umovC7z2I&index=1&pp=iAQBsAgC

#system_design

@techstuff100

دور زدن فیلترهای SSRF

بعضی سرویس‌ها مثل PDF Generator یه URL از کاربر می‌گیرن و از محتوای اون یه فایل PDF یا اسکرین‌شات تولید می‌کنن. مهاجم ممکنه بجای یه سایت معمولی، آدرس‌های داخلی سرور مثل localhost یا file:/// رو هدف بگیره؛ چونکه درخواست به این URL ورودی رو خود سرور ارسال می‌کنه و نه مرورگر کاربر.

برنامه ممکنه که فقط 127.0.0.1 یا localhost رو فیلتر کرده باشه. برای دور زدن این فیلتر راه‌هایی وجود داره؛ مثل نمایش IP به شکل decimal یا hex:
- decimal: 2130706433
- octal: 0177.0.0.1
- hex: 0x7F000001

و یا استفاده از دامنه‌های شخصی که به 127.0.0.1 اشاره می‌کنن و یا ...

[مقاله]

#cyber_security #recent_reads

@techstuff100