امکان نداره شما پروژه پایتونی رو کد بزنید و اطلاعات درست پروژه رو ندید

Readme.md

حداقل باید شامل ۳ مورد باشه :
۱- سیستم عاملی که روش کد زدید یا تست گرفتید :
OS: Ubuntu 20.04
۲- ورژن پایتونی که دارید استفاده می‌کنید:
Python: CPython 3.10.12
پایتون نسخه‌های مختلفی داره اگر از نسخه سایت python.org استفاده می‌کنید به اسم CPython شناخته می‌شه (توی شرکت‌هایی که از نسخه‌های دیگه مثل IronPython - Pypy - IntelPython استفاده می‌کنند رعایت این نکته بسیار مهم هست)

۳- دستور اصلی به جهت اجرای پروژه :
$ python main.py —help


فقط تحت ۱ شرابط حق دارید ۲ مورد اول رو جایی گزارش نکنید و کسی هم بهتون سخت نگیره (هرچند بازم خوب نیست ولی خب) :
Docker

اگر Dockerfile یا docker image استفاده می‌کنید توی پروژه می‌تونید به ترتیب هر ۳ مورد یا ۲ مورد اول رو توی گزارش ننویسید.

فایل بعدی که باید داشته باشید
requirements.txt
نبودش توی تیم ما خطای بزرگی هست :
۱- دیلی شرکت نکردن بدون اطلاع قبلی؛ دستمزد اون روز رو حذف می‌کنه
۲- پروژه تحویل دادن بدون
requirements.txt
درست بین ۲ تا ۷ روز کسر از دستمزد داره (اهمیت رو ببینید)

اما توی تیم من حداقل ۳ نکته هم باید رعایت بشه :
۱- بجای یک فایل باید ۳ تا فایل برای requirements داشته باشید
base.txt- local.txt - product.txt
یک پوشه به این اسم میسازید و این ۳ فایل داخلش قرار میگیره
تصویر بالا برای فایل
base.txt
هست؛ این فایل شامل پکیج‌هایی میشه که چه توی محیط توسعه چه توی پروداکشن باید وجود داشته باشه
local.txt
برای محیط توسعه هست خط اول این فایل همیشه باید
-r base.txt
باشه که بصورت اتومات پکیج‌های داخل base رو هم شامل بشه موقع نصب و باقی خط‌های فایل شامل پکیج‌هایی میشه که فقط توی محیط توسعه لازم هست :
black, isort, flake8, pre-commit, ...
و در نهایت
prod.txt
مواردی که فقط روی پروداکشن لازم هست بازم خط اول باید
-r base.txt
باشه حتما و قطعا چیزی که توی local هست نباید اینجا باشه.

۲- تمامی پکیج‌ها باید ورژن داشته باشند اما استفاده از
==
برای ورژن زدن پکیج‌ها ریکامند نمی‌شه بجاش از
~=
استفاده می‌کنیم دلیلش هم این هست که آپدیت‌های پچ رو بتونیم دانلود و نصب کنیم (چه امنیتی باشه چه رفع باگ‌های ساده) بدون اینکه نیازی به تغییر حتی ۱ خط کد باشه

۳- تا جایی که امکان داره موارد رو بصورت دستی بنویسید و از pip freeze دوری کنید؛ که فقط پکیج‌های اصلی ذکر بشه و فایل تمیزتری برای بررسی وجود داشته باشه.

این مواردی هست که توی تیم بنده رعایت می‌شه و تجربه بهم نشون داده کار خوبی هست (جاهای دیگه هم دیدم این مورد رو)
برخی از toml , ... استفاده می‌کنند که من برای پروژه تیمی تایید نمی‌کنم چون هرکسی ممکن ازین ابزارها استفاده نکنه ولی اگر کل تیم شما با اون فرمول پیش میره شما هم همون کار رو بکنید.

بازم میگم ما ترجیح میدیم راجب انتخاب ابزار هیچ فشاری روی باقی تیم نداشته باشیم.

.editorconfig

من بیشتره استفاده ازین فایل و استاندارد رو زمانی داشتم که از vscode روی چندین زبان برنامه نویسی استفاده میکردم که هرکدوم استانداردهای خودش رو داشت

javascript, python, rust 

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


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

مهمترین option ها اینجا هست؛ فقط توجه کنید همه‌ی IDE ها و ... معروف ازین مورد پشتیبانی می‌کنند فقط شاید لازم باشه تیک فعال سازیش رو بزنید
vscode :
settings > search for : EditorConfig > Use Editor Config

برای توضیحات بیشتر :
https://editorconfig.org/

خیلی حق بود ...

.flake8

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

برای مثال من روی پروژه‌های django بعد از پایتون ورژن ۳.۴ بصورت تصویر بالا تنظیمش می‌کنم؛ خطوطی که کامنت کردم تنظیمات مهمی هست که بنظرم لازم بود بدونید.

البته که وقتی از pre-commit استفاده می‌کنیم به این فایل نیازی نداریم؛ توی پست‌های بعدی می‌گم چرا

.pre-commit-config.yaml
من نمونه تنظیمات خودم رو گذاشتم که هرکسی دوست داشت استفاده کنه

pre-commit
س سری تنظیمات میگیره (به اسم هوک) و قبل از کامیت کدها اون‌هارو اجرا می‌کنه برای مثال توی تصویر بالا من :

flake8, black, isort, mypy 

و یکسری از extension های معروف flake8 که خودم باهاشون کار می‌کنم رو گذاشتم.

نکات مهم :
۱- من از poetry استفاده نمی‌کنم برای همین تنظیمات مورد نیازم رو توی همین فایل مینویسم.
۲- نیازی ندارید پکیج‌های بالا

flake8, black, isort, mypy 

رو توی requirements/local.txt که قبلتر توضیح دادم قرار بدید؛ فقط
pre-commit
رو به فایل local.txt اضافه و نصب می‌کنید خود این ابزار با شعور هست و پکیج‌های مربوط به هر هوک رو دانلود و نصب می‌کنه.

فقط توجه کنید هربار که یک repo جدید اضافه می‌کنید یا تغییرات اساسی روی این فایل دارید ۲ تا دستور رو بزنید :
pre-commit uninstall
pre-commit install

این دستورات چیزی رو حذف نمی‌کنه فقط pre-commit متوجه می‌شه چه مواردی رو باید دنبال کنه (یادتون نره قبلش git رو داشته باشید)

تصویر: نمونه خروجی pre-commit

در نهایت برای بررسی ارورها (
isort, black, mypy
بصورت اتوماتیک بعد از اینکه ارور رو نشون دادند فایل‌ها رو تغییر میدند و درست می‌کنند) دستور زیر رو اجرا می‌کنید
pre-commit run --all-files
البته
--all-files
رو اگر نزنید pre-commit بصورت خودکار فقط روی فایل‌هایی اعمال میشه که گیت اعلام کنه تغییرات داشتند ولی خب برای پروژه‌های کوچیک اجراش ضرری نداره.

الان دوستان اشاره کردند، فونت ترمینالم هم از همون قانون فونت vscode پیروی می‌کنه ؟

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

#موقت

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

پ.ن : روی موضوعی که حال نمی‌کنید
Reaction
نداشته باشید یا حتی
dislike
بدید (به این موارد هم توجه دارم)

آخرین موردی که راجبش صحبت می‌کنیم

Makefile

هست؛ ی ابزار روی لینوکس داریم به اسم
make
که خودش ی دوره (حداقل ۴ ساعته لازم داره تا درست متوجه بشید) مثالی که توی تصویر بالا زدم ساده ترین حالت استفاده از make هست و برای توسعه دهنده پایتون کافی.
اگر C - Rust , ... کد میزنید بهتره کامل یادبگیرید خیلی کمک می‌کنه واقعا

Documentation

فقط ی توضیح کوتاه بدم؛ تعریفش این هست.
make command compiles different program pieces and builds a final executable.

توی فایل بالا و روی 20:

.PHONY:
توی دنیای پایتون همیشه این رو قبل از دستوری که میخواید بنویسید بذارید؛ اگر این رو نذارید make ابتدا دنبال فایلی با اسم دستوری که گذاشتید می‌گرده و اگر توی پروژه فایلی به این اسم وجود داشته باشه که به تازگی هم آپدیت شده دستور رو اجرا نمی‌کنه؛ در صورت نبود اون فایل یا تغییر زمانی دستور شما رو بصورت کامند اجرا می‌کنه و timestamp فایل رو تغییر میده
خلاصه که ی خط در میون ممکنه ببینید دستور شما اجرا نمیشه.

دو خط بعدی میگه که make در صورت دیدن این دستور باید چی رو اجرا کنه
برای اجرا میزنید :
make migrate
برای مثال بالا.

برای خط ۳۸-۳۹ تصویر بالا؛ اگر خواستید چندتا دستور رو پشت هم اجرا کنید باید همرو توی یک خط بنویسید.
make
متوجه هست که ابتدا باید

make prodsetup 

و بعد

make migrate

رو اجرا کنه تا make produpdate به درستی انجام بشه.

نکته دیگه اینکه ممکنه یک سری علامت توی
Makefile
هایی که از جایی میگیرید ببینید؛ توی پایتون من ندیدم و بیشتر توی C- Rust دیدم این موارد رو مثل :
$<, @, %, $^
هر کدوم ازین‌ها یک معنای خاص دارند که من چون توی پایتون کاربرد نداره توضیح نمیدم ولی برای ساده سازی
Makefile
ازش استفاده می‌شه و بهشون
Automatic Variables
گفته میشه برای آشنایی بیشتر :
Automatic Variables documentation

به یک باگ (باگ هم نمیشه گفت البته، بیشتر سر نبود داکیومنت هست شاید) بر خوردم بعد فهمیدم این آهنگ چقدر به موقعیت میاد

خشم و خستگیم به لبخند تبدیل شد :

https://t.iss.one/PytensMusic/145


پ.ن : مخاطب آهنگ‌های شما هم هستم،
کسی موسیقی خوب داشت حتماً برای منم بفرسته 🌹

خیلی دوست دارم این کتاب رو بخونم، چند بخشش رو برای دمو گذاشتند که بنظرم این مباحث رو خیلی خوب توضیح داده بود (نمی‌دونم باقی موارد هم همینطور هست یا خیر)

برای خرید فقط نسخه
Epub
رو می‌تونم بخرم (که اصلاً طرفدارش نیستم)

نسخه pdf رو چندتا سایت ایرانی برای فروش گذاشتند، که خب پیگیر شدم بدون مجوز نویسنده هست و ایشون هیچ درآمدی ازش نداره.

Amazon Link

اگر کسی این کتاب رو خونده، یک پیام بهم بده حتماً. (می‌خوام نسبت به کتاب قبلی مقایسه کنیم)

#django_roadmap #roadmap

امروز یک دوستی، گفت بهش یک roadmap برای شروع جنگو بدم با این بکگراند :
۱- پایتون رو تا سطح خوبی بلد هست
۲- ساختمان داده و الگوریتم رو می‌شناسه
۳- لینوکس، گیت و داکر رو هم بلده

یک بخش دیگه که باعث میشه این Roadmap رو بنویسم، همین موضوع هست که خیلی از بچه‌ها بهم گفتند چطوری تونستی بعد از ۲ هفته یادگیری جنگو شروع به کار کنی ؟

اول باید بگم که من ۲ هفته‌ای فهمیدن جنگو رو مدیون زحماتی هستم که روی پایتون کشیدم، بر عکس خیلی‌ها که شروع می‌کنند فریمورک یادگرفتن من فارغ از فریمورک توسعه وب رو یاد گرفتم و بعد اومدم سراغ جنگو (هرچند توی جنگو خیلی جا برای پیشرفت دارم و باید زحمتش رو بکشم هنوز)
برای همین هست که وقتی کسی بهم میگه roadmap بده میگم ۳-۶ ماه اول فقط پایتون، من به خیلی‌ها گفتم کتاب
Fluent Python
رو جلوت بذار و سرفصل‌هاش رو بخون، اگر مفهومی رو بلد نیستی یعنی هنوز آماده نیستی که بری سراغ فریمورک (حالا اینکه این موضوع برای نسل آینده برنامه‌نویسی توسعه میشه، خودش یک داستان هست. یعنی این نسخه رو نمیشه برای همه پیچید ولی قطعاً این بهترین راه هست)

تکنیکی که شخصاً باهاش فریمورک و ... رو یاد میگیرم، مختص خودم هست و اسمش رو منبع سوزی میذارم، چطوری هست ؟

۱- اول مطمئن میشم با اون فریمورک ارتباط برقرار می‌کنم و جوگیر شدن و ... درکار نیست

برای مثال روی همین جنگو :

اول رفتم سراغ این پلی لیست :
Youtube Playlist

دفعه‌ی اول با سرعت 3x نگاهش کردم کامل که تقریباً ۱ روز جمعه‌ام رو گرفت، بعد یک سری تحقیق کردم و مطمئن شدم ازین فریمورک خوشم اومده

دفعه‌‌ی دوم همین پلی لیست رو با دقت بیشتر و روی سرعت 1.5x نگاه کردم.

توی این تکنیک برای قدم اول هیچ نیازی به کد زدن نیست، شما تکیه میدی و از دیدن فیلم لذت میبری، توی دفعه‌ی دوم دیدن ویدئو منابع مهم رو روی یک مرورگر دیگه باز می‌کنید مثلاً: من متوجه شدم چیزهایی به اسم :
Redis, Celery, Flower, django rest framework, ...
وجود داره و همینجا متوجه شدم نیاز من یادگیری با جزئیات
DRF
هست و نه Django forms یا template نویسی پس این دو مورد رو خیلی کم روش وقت گذاشتم.

2- یادگیری از یک منبع مناسب، من کتاب‌های زیادی رو خوندم چون منبع جامع و مناسبی پیدا نکردم برای
DRF
ولی دیروز شروع کردم به خوندن یک کتابی که سرفصل‌های جالبی داشت و ۳ فصل اول رو خوندم و تموم شد که بنظرم منبع خیلی خوبی اومد نسبت به کتاب‌های دیگری که خوندم :

Becoming an Enterprise Django Developer
By Michael Dinder (Packt pub)

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

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

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

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

1- YouTube PlayList
نسخه DRF هم هست (اگر دوست داشتید توی همون کانال ببینید)
2- Becoming an Enterprise Django Developer By Michael Dinder (Packt pub)

3- Django documentation
4- Django Rest Framework

هیچ چیز به اندازه دیدن ویدئو خوب آخر شب حال نمیده :

Software Engineering Mock Interview (Python3)

پ.ن : چیزایی که بنظرم طرف اشتباه می‌کنه رو هم بذارم :
مثلا همین ابتدای دقیقه ۶ باید می‌پرسید آیا یک یوزر می‌تونه چندین

Active book 

داشته باشه ؟ (یک سری سوالات پرسیده نمی‌شه چون مثال kindle زده شده اما اگر طرف با این سرویس آشنایی نداشته باشه می‌تونه اعلام کنه و درخواست اطلاعات بیشتر کنه)
دقیقه ۱۱ این سوال رو می‌پرسه و طرف اعلام می‌کنه بله باید اینطوری باشه (این موضوع دید کلی و همه جانبه داشتن خیلی خیلی مهمه بخصوص اگر برای سطوح بالاتر دارید مصاحبه می‌کنید)

دقیقه ۹: برای page/content ساختمان داده list رو پیشنهاد میده و دلیل میاره که چرا باقی موارد نه؛ اما بنظرم من tuple درست تر بود (چون محتوای یک صفحه از کتاب بعد از انتشار تغییر نمی‌کنه و البته tuple از نظر حافظه بسیار بصرفه تر از list هست)
جلوتر یادش افتاد و اشاره کرد؛ برای راحتی لیست رو انتخاب کرد (بله این هم اتفاق درستی هست توی مصاحبه) شما درست ترین راهکار رو اول ارائه میدی بعد می‌تونه بپرسی آیا اجازه داری که راهکاری که ساده‌تر هست رو استفاده کنی توی پیاده‌سازی یا خیر

دقیقه ۱۲: من بودم بجای گرفتن id برای هر کتاب از isbn استفاده میکردم دلیلش هم این هست که هم روی فیچری برای جستجو کمک می‌کنه و هم unique هست و نیازمندی لازمه برای active books رو هم برطرف می‌کنه؛
پس ی اشتباه دیگه طرف راجب فیچرهایی مثل

Recommendation, Search 

سوالی نکرده و فیلدی هم درنظر نگرفته تا اینجا

دقیقه ۱۵: از اونجایی که توی پایتون ساختار داده dict دیگه بصورت دیفالت order هم داره میشه ازین ساختار هم برای نگهداری صفحات کتاب استفاده کرد (بخصوص اینکه اینجا تعداد سرچ ممکنه زیاد باشه)
هرچند من نیاز ویژه‌ای نمی‌بینم اما گفتن این نکته نشون میده شما به فیچرهای جدید‌تر زبانی که باهاش کد میزنید هم آشنا هستید و تغییراتش رو دنبال می‌کنید (این موضوع رو توی مصاحبه با آمازون داشتم و براش امتیاز قائل بودند)

دقیقه ۱۵ : شروع کرد به کد زدن و با فیلدهای کمینه شروع کرد متاسفانه کیندل تصویر اصلی کتاب رو بصورت thumbnail نمایش میده؛ اسم نویسنده می‌تونست موضوع جذابی برای جستجو باشه؛ میشد به این نکته اشاره کرد که آیا نیاز به جستجو بر اساس متن داخل کتاب داریم ؟ یا اینکه برای ساده‌سازی می‌تونید ازش بگذریم و ....

اضافه کنم این بسیار مهم هست که پروژه رو بیش از حد سخت و سنگین نبینید (خود این هم امتیاز منفی داره) و این موضوعات رو بسیار سریع بهش اشاره کنید و ازش بگذرید مخصوصا تو این مرحله که system desing نیست (هرچند این لول از جزئیات رو من بیشتر با اسم micro-service desing باهاش موافق هستم توی طراحی سیستم هم نباید انقدر درگیر جزئیات بشید و واقعا یک تله هست.)

دقیقه ۱۷:۵۰ : ازش متدی برای ورق زدن کتاب خواسته شد turn_page که خب طرف فراموش کرد برای برگشت به عقب کدی بزنه (یعنی این ویژگی در واقع نیاز به ۲ تا متد داشت با توجه به مدل پیاده سازی این خانوم)

توی دقیقه ۲۰ که داره Library رو میسازه؛ بنظرم ۲ تا سوال رو جا انداخت؛ چرا من زودتر به این اشاره نکردم ؟ چون طرف گفت kindle من رفتم سمت نسخه‌ی‌ قدیمی که میشناختم و همه چیز رو روی دیوایس هر نفر ذخیره میکرد اما این خانم به API هم اشاره کرد پس :
۱- می‌تونست ی نسخه جامع‌تر از Library در نظر بگیره که شامل همه کتابها باشه؛ باز چون گفته شد اطلاعات کتاب بهش داده میشه فرض میکنم اون بخش روی یک سرویس دیگه که اسمش رو بذاریم core پیاده سازی شده
۲- با فرض اینکه مورد قبلی تایید بشه پس نیازی به Authorization توی این سرویس نداریم پس می‌تونه
Add to collection
همینطوری پیاده سازی بشه (هر کاربر یک کپی از کتاب نه مجوزی برای دسترسی به کتاب)
الان دیگه مطمئن شدم که سطح مصاحبه midlevel هست چون طرف تو این دقیقه از مصاحبه نباید دیگه از API حرف میزد (ازون جایی که mock interview ها همیشه یک بکگراند قبلی داره فکر میکردم بسته شده که قرار نیست API یا microservice باشه)
این خیلی مهمه توی مصاحبه هر فرضیه‌ای که تایید نگیرد غلط هست و شما دارید مسیر اشتباه رو میرید؛ برای همین من به همه شاگردام و دوستانی که باهاشون مصاحبه کار میکردم همیشه گفتم یاد بگیرید توی جلسه مصاحبه بلند بلند فکر کنید اهمیت این موضوع 10/10 هست یعنی از خود کدهاتون هم با ارزش تر
چون شاید شما نرسید توی تایم مصاحبه کد رو تکمیل کنید (که خب چیز اشتباهی نیست مگر در شرایط خاص) اما اگر بلند بلند تفکر کرده باشید و مصاحبه کننده بدونه به چی فکر کردید؛ نوع کد زدنتون رو هم که تا اینجا دیده احتمالش بسیار زیاد هست که نمره کامل رو براتون رد کنه و خدا می‌دونه که این امتیاز چقدر مهم و کمک کننده هست.


باقی در کامنت‌ها :

پست بالا رو با مواردی که بنظرم اشتباه می‌کنه یا نکات مهم مصاحبه با تجربه شخصی خودم آپدیت می‌کنم.

متاسفانه توی مصاحبه گفته نشد برای چه سطحی داره مصاحبه انجام میشه که خب خیلی مهم هست ولی با توجه به اینکه راجب system design صحبتی نشد و مستقیم روی OOP desing هستند فکر می‌کنم سطح midlevel داره مصاحبه می‌شه یا اینکه مصاحبه مرحله اول هست برای سطح senior

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


کامنت اول رو هم فراموش نکنید؛ اشتباهاتش زیاد بود خستم کرد
دقیقه ۳۲ به بعد رو خودتون تحلیل بزنید

#موقت

ویدئو آموزشی دیدن به خصوص Mock Interview باید اینطوری باشه فقط بیننده یا شنونده بودن خیلی تاثیر مثبتی نداره
سعی کنید غلط گیری و نکته برداری کنید.
خودتون رو جای مصاحبه کننده بذارید و فکر کنید چرا داره این سوال رو می‌کنه ؟ ( قطعا سادیسم یا مرض نداره - البته تو ایران ممکنه سادیسم دار ببینید که اکثرا از بیسوادی میاد حالا در آینده از تجربه یکی از بچه‌ها با منبع براتون میگم حتما)

گفتم حالا که دارم وقت میذارم؛ این ویدئو رو ببینم بگم که خودم چطور این موارد رو بررسی میکنم و امیدوارم برای شما هم مفید بوده باشه.

نکته آخر : هیچ مصاحبه‌ای فقط ۱ جواب درست نداره

امروز اومدم بشینم پیام‌ها رو جواب بدم :
حدوداً ۲۰۰-۳۰۰ تا شده (مجموع همه کانال‌ها)، واقعاً حوصله‌ام نشد ادامه بدم؛ ی سری موضوعات راجب تبلیغات و حمایت از دوره و ... که قبلاً توضیح دادم و هیچ.

اما این مدل سوالات هم جوابی نمیدم :

۱- راجب پایتون یک سوال داشتم، شما می‌تونید جواب بدید ؟
(خب اصل سوالتون رو بپرسید، سوال ندیده چطور بدونم می‌تونم جواب بدم یا نه ؟)

۲- روی فریمورک XYZ به مشکل خوردم، می‌شه کمک بخوام ؟ (بدون ارسال ارور یا توضیح)

۳- مدرس خصوصی می‌خوام؛ شما تدریس می‌کنید ؟
(خیر، کلا هم هزینه‌اش بصرفه نیست، مواردی هم که بلدم بهترین منابع رو بهتون دادم و رایگان هم راجبش توضیح میدم)

۴- کدوم دوره رو برای یادگیری پایتون تأیید می‌کنید ؟ (لیست n تا دوره ایرانی با قیمتای سرسام آور)
قبلاً گفتم هیچ دوره پولی ایرانی رو تأیید نمی‌کنم، حرفه‌ای ها و کار بلدهای ایران به رایگان توی یوتیوب و ... دارند دوره میذارند
انگلیسی هم که ببینید فوق‌العاده

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

شاید کمی‌ دیر اما همیشه سعی میکنم جواب افرادی که بدون حاشیه سوال پرسیدند رو بدهم (فارغ از هر چیزی)

اگر سوالات کلی دارید، یا نیاز دارید خیلی زود جواب بگیرید ، بهترین راه مطرح کردن سوال توی گروه متصل به کانال هست .

سپاس از همگی

پ.ن‌: ویس هم اصلا نفرستید، موزیک موقع کارم رو برای هیچکس قطع نمی‌کنم 😂

برای سوالات درست : در خدمت دوستان هستم، ببخشید اگر جواب دادن کمی طول می‌کشه 🌹