Panic Dev (@panicdev)の最新投稿

Panic Dev のテレグラム投稿

Panic Dev
Panic Dev; your Panic's solution 🔥

🍿 Telegram
🔰 t.me/PanicDev

🍿 Laravel Community
🔰 t.me/LaravelGroups

😇 Contact Me
🔰 t.me/MentionHex

Thanks for sharing us 💛
1,206 人の購読者
61 枚の写真
24 本の動画
最終更新日 25.02.2025 04:08

類似チャンネル

کانال دورکاری
24,483 人の購読者

Panic Dev によってTelegramで共有された最新のコンテンツ


چطور سوالات انتخاب می‌شوند

داوطلب‌ها معمولاً از ما می‌پرسند که "سوالات مصاحبه اخیر" در یک شرکت خاص چی هستن. همین که این سوال رو می‌پرسید، نشون می‌ده که درک درستی از این که سوالات از کجا می‌آن ندارید.

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

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

سوالاتی که امسال توی گوگل پرسیده می‌شن، خیلی با سوالاتی که سه سال پیش پرسیده می‌شد، فرق ندارن. در واقع، سوالاتی که توی گوگل پرسیده می‌شن، معمولاً با سوالات شرکت‌های مشابه مثل آمازون یا فیسبوک فرق چندانی ندارن.

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

اما این روش برای همه افراد، همه شرکت‌ها یا همه موقعیت‌ها مناسب نیست.

بخش‌های بالا به این هدف نوشته شده‌اند که شما رو با تفکر و روند تصمیم‌گیری شرکت آشنا کنن.

نظر شخصی من؟ در شرایط درست، وقتی که به‌خوبی اجرا بشه، این روش می‌تونه قضاوت مناسبی از مهارت‌های حل مسئله فرد باشه، چون افرادی که خوب عمل می‌کنن معمولاً افراد باهوشی هستند.

اما معمولاً این فرآیند به‌خوبی اجرا نمی‌شه. ممکنه مصاحبه‌کننده‌های بدی داشته باشین یا افرادی که فقط سوالات بدی می‌پرسن.

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

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

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

در نهایت، باید بگم: این همینه که هست، پس بهترین کاری که می‌تونیم بکنیم رو انجام بدیم.

تخته‌های وایت‌بورد به شما کمک می‌کنند روی چیزهای مهم تمرکز کنید.

درسته که نوشتن کد کاملاً بی‌نقص روی تخته وایت‌بورد کار سختیه. اما خوشبختانه، انتظار مصاحبه‌کننده هم این نیست. تقریباً همه ممکنه چندتا باگ یا خطاهای جزئی نحوی داشته باشن.

چیزی که در مورد تخته وایت‌بورد جالبه اینه که شما می‌تونید روی تصویر کلی تمرکز کنید. نیازی به کامپایل کردن کدتون ندارید چون کامپایلری در کار نیست. نیازی نیست کل تعریف کلاس یا کدهای اضافی رو بنویسید. می‌تونید روی قسمت‌های اصلی و جذاب کد تمرکز کنید، یعنی همون تابعی که سؤال واقعاً در موردشه.

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

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

دانش پایه در مورد ساختار داده‌ها و الگوریتم‌ها مفید است.

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

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

برخی مصاحبه‌کنندگان، استفاده از ساختار داده‌ها و الگوریتم‌ها را با این توجیه منطقی می‌دانند که این یک "معیار جایگزین" خوب است. حتی اگر این مهارت‌ها به‌تنهایی سخت نباشند، آن‌ها می‌گویند که دانستن این مفاهیم به‌طور معقولی با توانایی توسعه‌دهنده بودن همبستگی دارد. این بدان معنی که یا شما از یک برنامه علوم کامپیوتر عبور کرده‌اید (که در این صورت مجموعه‌ای نسبتاً گسترده از دانش فنی را یاد گرفته و حفظ کرده‌اید)، یا این مطالب را به‌صورت خودآموز یاد گرفته‌اید. در هر صورت، این نشانه مثبتی است.

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

پذیرش منفی‌های کاذب قابل قبول است.

(به این اشاره داره که در بعضی مواقع تصمیم میگیرن کاندیدی که واقعا خوب هست و رد کنند )

این واقعیت تلخی است (و برای داوطلبان ناامیدکننده)، اما درست است.

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

آن‌ها نگرانی بسیار بیشتری درباره مثبت‌های کاذب دارند: افرادی که در مصاحبه عملکرد خوبی دارند، اما در واقع چندان توانمند نیستند.

این یکی از رایج‌ترین سؤالاتی است که داوطلبان هنگام شروع این فرآیند مطرح می‌کنند:

چرا به این روش عمل میکنند؟

1. بسیاری از داوطلبان عالی در این نوع مصاحبه‌ها خوب عمل نمی‌کنند.
2. اگر این سؤال‌ها واقعاً مطرح می‌شدند تو دنیای واقعی ، شما می‌توانستید پاسخ آن‌ها را جستجو کنید.
3. شما به ندرت مجبور به استفاده از ساختارهای داده‌ای مانند درخت‌های جستجوی دودویی در دنیای واقعی هستید. اگر نیاز پیدا می‌کردید، قطعاً می‌توانستید آن‌ها را یاد بگیرید.
4. کدنویسی روی تخته وایت‌بورد یک محیط مصنوعی است. واضح است که شما هرگز در دنیای واقعی روی تخته وایت‌بورد کدنویسی نمی‌کنید.

این انتقادات بی‌اساس نیستند. در واقع، حداقل تا حدی با همه آن‌ها موافقم.
در عین حال، برای برخی - نه همه - موقعیت‌ها، دلایلی وجود دارد که به این روش عمل می‌شود. مهم نیست که با این منطق موافق باشید یا نه، اما ایده خوبی است که بفهمید چرا این سؤالات مطرح می‌شوند. این می‌تواند کمی بینش درباره ذهنیت مصاحبه‌کننده ارائه دهد.

بعد از هر مصاحبه ،‌ مصاحبه‌کننده عملکرد شما را معمولاً بر اساس موارد زیر ارزیابی می‌کند:

مهارت‌های تحلیلی: آیا برای حل مسئله به کمک زیادی نیاز داشتید؟ راه‌حل شما چقدر بهینه بود؟ چه مدت طول کشید تا به یک راه‌حل برسید؟ اگر نیاز بود یک راه‌حل جدید طراحی یا معماری کنید، آیا مسئله را به‌خوبی ساختاربندی کردید و مزایا و معایب تصمیم‌های مختلف را بررسی کردید؟

مهارت‌های کدنویسی: آیا توانستید الگوریتم خود را با موفقیت به کدی معقول تبدیل کنید؟ آیا کد شما تمیز و به‌خوبی سازمان‌دهی شده بود؟ آیا به خطاهای احتمالی فکر کردید؟ آیا از سبک مناسبی استفاده کردید؟

دانش فنی/ مبانی علوم کامپیوتر: آیا پایه‌ای قوی در علوم کامپیوتر و فناوری‌های مرتبط دارید؟

تجربه: آیا در گذشته تصمیم‌های فنی خوبی گرفته‌اید؟ آیا پروژه‌های جالب و چالش‌برانگیزی ساخته‌اید؟ آیا انگیزه، ابتکار عمل و سایر عوامل مهم را نشان داده‌اید؟

تناسب فرهنگی/ مهارت‌های ارتباطی: آیا شخصیت و ارزش‌های شما با شرکت و تیم همخوانی دارند؟ آیا با مصاحبه‌کننده خود ارتباط خوبی برقرار کردید؟

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

امروز یک مطلب در مورد مصاحبه ها خوندم که برای خودم جالب بود و برای خیلی از سوال هام جواب گرفتم ،‌ بنظرم اشتراک گذاری مطلب خالی از لطف نیست ،‌

و موقع مصاحبه دقت بیشتری خرج میدید ،‌ ولی خیلی از مواردی که براتون مسخره و غیر منطقی هست . براتون منطقی تر بنظر برسه و بتونید بهتر عمل کنید .

⭐️ استاریفای یه پلتفرم کاربر محوره که به شما این امکان رو میده برای ریپازیتوری هاتون استار بگیرید و برای پروفایل گیت هابتون فالوور بگیرید.

💸 کاملا رایگانه و بر اساس میزان تعاملون و تاثیر پذیریتون توی کامیونیتی بهتون اعتبار میده که اون اعتبار رو میتونید برای گرفتن استار یا فالوور واقعی گیت‌هاب استفاده کنید.

🔥 این پروژه نیمه دوم ماه آینده لانچ میشه و در دسترس میشه و فقط 5000 کاربر میگیره.

ضمنا 10 تا استار فوری هم بهتون توی اولین ورود میده که میتونید روی هر کدوم از ریپازیتوری هاتون که دوست دارید اعمالش کنید 🤩

🔗 https://starify.app

🌟 احتمالا همه‌تون دیگه الان باید با CursorAI آشنا باشید!

یکی از قابلیت‌های جذاب Cursor چیزی هست به اسم Rules for AI که از مسیر زیر در دسترسه:
Cursor Settings > General > Rules for AI

در این بخش، شما می‌تونید Custom Instructions (دستورالعمل‌های شخصی‌سازی‌شده) به Cursor بدید. این دستورالعمل‌ها در پروسه Fine-Tune شدن Prompt شما اعمال می‌شن و باعث می‌شن که خروجی دقیقاً همونی بشه که می‌خواید. 💡

🎯 مثلا چی می‌تونید بنویسید؟
- سبک کدنویسی خاصی که دوست دارید AI رعایت کنه
- نکاتی مثل:
- "توی فرانت‌اند از margin استفاده نکن!"
- "همیشه از flex، grid، و gap استفاده کن!"

اما یه مشکل کوچیک اینجا پیش میاد:
اگه شما از تنظیمات Cursor یه Rule تعریف کنید، این فقط توی محیط کاربری خودتون اعمال می‌شه. 😕
اگه تیمی کار می‌کنید، هر نفر باید جداگانه این موارد رو تنظیم کنه.

🤔 راه‌حل چیه؟
از فایل `.cursorrules` استفاده کنید!
با ایجاد این فایل توی root پروژه:
- می‌تونید قوانین موردنظرتون رو به‌صورت مشترک بین اعضای تیم استفاده کنید.
- این فایل رو توی Git ذخیره کنید تا همه بهش دسترسی داشته باشن. 🚀

📚 اطلاعات بیشتر درباره‌ی cursor rules
🔗 https://docs.cursor.com/context/rules-for-ai


💻 همچنین، یک ریپازیتوری هست که Ruleهای آماده و استاندارد برای Use Case‌های مختلف رو ارائه می‌کنه:
🔗 https://github.com/PatrickJS/awesome-cursorrules