پی‌نوشت:
همونطور که احتمالا متوجه شدید archium یه پکیج لاراولیه که شما با نصب کردنش توی پروژه تون دسترسی به یک روت خواهید داشت به این صورت
/archium
این روت یه پنل رو به شما نشون میده که از طریق این پنل میتونید بررسی کنید که ایا پکیج
nwidart/laravel-modules
توی پروژه نصب هست یا خیر - درصورتی که نصب نبود از طریق یک Quick Action و تایید مودال میتونید پکیج رو به پروژه اضافه کنید.

توی قدم دوم برای پابلیش فایل کانفیگ شما میتونید از طریق یک Quick Action دیگه اقدام کنید اما این فایل کانفیگ از کجا میاد؟

از این مسیر:
https://github.com/PanicDevs/ArchiumSettings/blob/main/nwidart-laravel-modules-config-file.php

فایل همیشه از اینجا گرفته میشه و دفعات بعدی که شما پنل رو باز کنید درصورتی که اپدیتی روی این فایل توی گیت هاب اعمال شده باشه شما کارت uppdate کانفیگ رو به صورت خودکار میبینید. (اسکرین شاتش رو توی کامنت ها میزارم)

بعد از اون میتونید وارد تب modules بشید و اینجا این پکیج لیست ماژول هارو از یک فایل دیگه که توی گیت هست میخونه:
https://github.com/PanicDevs/ArchiumSettings/blob/main/modules.archium

ماژول هارو برای شما لیست میکنه و شما میتونید به راحتی نصبشون کنید.

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

ورژن چک انجام میشه با نسخه ای که روی گیت هست و درصورتی که اپدیتی وجود داشته باشه از شما سوال پرسیده میشه که اپدیت انجام بشه یا اسکیپ بشه.

در تمام مراحل شرایط مختلف درنظر گرفته شده - دیپندسی های ماژول ها اگه از قبل نصب باشن از شما درمورد نصب مجدد و یا اسکیپ کردن اون مرحله سوال پرسیده میشه و ...

من متاسفانه بیشتر از این فرصت نکردم که روی این پروژه زمان بزارم اما حتما در آینده برمیگردم سراغش و بیشتر تکمیلش میکنم.


⚠️ روی این پروژه PR نمیپذیریم حتی اگه جایی رو ai به وضوح اشتباه کرده باشه اما میتونید issue باز کنید و بهم اعلام کنید تا مجددا با cursor حلش کنیم و گیت رو اپدیت کنیم.

با عرض درود و احترام فراوان

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

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

📦 RealMrHex/Negar
📦 RealMrHex/Webpack-Course
📦 RealMrHex/Modular-Structure

و همینطور ارگانیزیشن های زیر از دسترس خارج خواهند شد:
🏡 Livewire-Master
🏡 PanicDevs

و پکیج های زیر تا اطلاع ثانوی توسعه داده نخواهند شد و پشتیبانی نمیشوند:
📦 RealMrHex/Filament-Modular
📦 RealMrHex/Filament-Modular-V3

میتونید از هر یک از ریپازیتوری هایی که بهشون نیاز دارید یک فورک تهیه کنید و برای آینده به اون رفرنس کنید.

اینجانب در طول این مدت نامشخص - تا اطلاع بعدی به هیچ عنوان برای هرگونه همکاری - مشاوره - پرسش و پاسخ و یا مکالمات غیر ضروری در دسترس نخواهم بود و برای موارد ضروری فقط و فقط از طریق پیام تلگرام در دسترس هستم و در اولین فرصتی که پیامتون رو ببینم سعی میکنم بهتون جواب بدم 🙏

ممنون از همراهی و حمایت‌های همیشگی‌تون ♥️

🌟 احتمالا همه‌تون دیگه الان باید با 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

همه‌چیز نسبی است

اگر هیچ سیستم ارزیابی وجود نداشته باشه، پس چطور ارزیابی می‌شید؟ چطور یه مصاحبه‌کننده می‌دونه باید از شما چی انتظار داشته باشه؟

سوال خوبی هست. پاسخ در واقع وقتی که متوجه بشید، کاملاً منطقی به نظر میاد.

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

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

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

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

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

سوالات متداول

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

(به جز شرکت های ایرانی ، در شرکت های ایرانی و حتی شرکت های ایرانی-خارجی کاملا برعکس این موضوع :) )

اگر بعد از ۳ تا ۵ روز کاری از شرکت جوابی نگرفتید، با دقت (و مودبانه) با استخدام‌کننده‌تون تماس بگیرید.

آیا می‌توانم بعد از رد شدن دوباره برای یک شرکت درخواست بدم؟
تقریباً همیشه بله، اما معمولاً باید مدتی صبر کنید (۶ ماه تا ۱ سال). مصاحبه اول که بد باشه معمولاً تاثیر زیادی در مصاحبه بعدی نداره. خیلی از افراد از گوگل یا مایکروسافت رد می‌شن و بعداً از همون‌ها پیشنهاد شغلی می‌گیرن.

بنظرتون تو earbuds ها به این کوچیکی چند تا تکنولوژی استفاده شده ؟