ممکن است یک روزی برای انجام مصاحبه به یک شرکتی بروید. آن شرکت به شما یکسری پروژه و یا مسئله بدهد و بگوید این موارد را در خانه حل کرده و با ایمیل به ما پاسخ دهید. شما کل شب را مشغول نوشتن پروژه خواهید بود و در نهایت فکر می‌کنید که این بهترین چیزی‌ست که تا به حال نوشته‌اید.
به همین دلیل ایمیل‌تان را باز کرده و پروژه را برای شرکت مورد نظر ارسال می‌کنید. بعد از گذشت مدتی، شرکت به شما پاسخ می‌دهد. شما نیز در اوج اعتماد به نفس فکر می‌کنید که آن‌ها پیش‌نویسی از قرارداد کاری را برای‌تان فرستاده‌اند.
اما وقتی ایمیل را با دقت می‌خوانید، متعجب می‌شوید. آن‌ها صرفا یک تشکری کرده‌اند و گفته‌اند که می‌خواهند فرد دیگری را استخدام نمایند.
به نظرتان چه مشکلی وجود داشت؟ خب بیایید در این مطلب به این موضوع پی ببریم.
اشتباه ۱: ممکن است وظیفه‌ای که به شما داده شده را به خوبی درک نکرده باشید
برخی اوقات یک کلمه می‌تواند به صورت کل سوال را بهم بریزد و معنای دیگری را با خود به همراه داشته باشد. ممکن است شما در خواندن یا درک سوالی که به شما داده شده آن کلمه را از دست داده باشید و یا آنکه واقعا به نظرتان موضوع مهمی نیامده باشد.
بهتر است هر سوالی را چندین بار به خوبی مطالعه کرده و به درک خوبی از آن رسید، پس از این می‌توانید سراغ عملیات‌تان بروید.
اشتباه ۲: ممکن است بدون داشتن درک درست از سوال شروع به پیاده‌سازی آن کرده باشید
شاید پروژه اول را حل کرده باشید، اما سوال‌هایی دارید! پس بهتر است با فردی از همان شرکت که در ارتباط هستید، صحبت کنید و سوال‌های‌تان را بپرسید. این ایده بدی نیست. اگر شرکتی برای کارمندان و محصولات‌ش اهمیتی قائل باشد مطمئنا به شما پاسخ خواهند داد.
اما اگر واکنش آن‌ها منفی بود، پس بهتر است کلا آن شرکت را فراموش کنید، چرا که ظاهرا از آن دست شرکت‌های سمی هستند که کسی حق پرسیدن سوالی را ندارد.
اشتباه ۳: از گیت استفاده نکرده‌اید
لطفا! لطفا! هیچوقت یک فایل zip با حجم ۶۰ مگابایت که شامل یک دایرکتوری حجیم از node_modules است را به هیچ شرکتی نفرستید. اینگونه آن‌ها فکر می‌کنند که شما فرد مبتدی هستید و به همین دلیل شانسی برای گرفتن شغل نخواهید داشت.
از گیت استفاده کنید. اگر هم نمی‌دانید که گیت چیست و چگونه می‌شود با آن کار کرد، دست نگه دارید! ابتدا سراغ گیت رفته و پس از آن به سوال‌ها برگردید. شرکت‌های بسیار زیادی از گیت استفاده می‌کنند. به همین دلیل شما در نهایت باید گیت را بلد باشید.
اشتباه ۴: شما پیام‌های خوبی را برای کامیت‌های‌تان نمی‌نویسید
شما از گیت استفاده می‌کنید، این خوب است، اما همه چیز را در یک کامیت قرار ندهید. شرکت‌ها به git log شما برای مشاهده تاریخچه و پیام‌های مربوط به کامیت‌ها نگاه می‌کنند. باید همواره این موضوع را در ذهن داشته باشید که اگر قرار است با یک تیم در شرکت کار کنید، نوشتن پیام‌های خوب برای کامیت‌ها بسیار مهم است. البته نه صرفا در تیم‌ها، برای خودتان نیز باید از پیام‌های درست و شفافی استفاده نمایید، چرا که اگر بعد از دو هفته به کدهای‌تان بازگردید، باید بدانید که دقیقا منظورتان از کامیت x چه بوده است.
اشتباه ۵: فایل .gitignore را فراموش کرده‌اید
این موضوع به اشتباه شماره ۳ باز می‌گردد، اگر شما از .gitignore استفاده نکنید و تمام دایرکتوری را به گیت بسپارید، باز هم مجبور خواهید بود که node_modules را برای شرکت مورد نظر ارسال کنید. هیچکسی این دایرکتوری را از شما نمی‌خواهد.
یک مجموعه خوب از فایل‌های مختلف gitignore را می‌توانید در این لینک مشاهده کنید.
اشتباه ۶: شما در حال ارسال یک فایل Zip با ایمیل هستید
شما به عنوان یک توسعه‌دهنده باید کار با گیت هاب را بلد باشید! درست است؟ پس بهتر است که از آن استفاده کنید. کدهای‌تان را روی گیت‌هاب قرار دهید و لینک آن را برای فردی که قرار است کدهای شما را بررسی کند ارسال نمایید. مطمئنا همان فرد خیلی از این موضوع خوشش می‌آید. استفاده از گیت‌هاب برای بررسی کردن کدها بسیار خوشایندتر از دانلود یک فایل zip و مشاهده فایل‌ها در آن است.
اشتباه ۷: فایل README.md را فراموش کرده‌اید و یا آنکه آن را خوب ننوشته‌اید
گیت‌هاب فایل README.md شما را به صورت خودکار رندر می‌کند و به عنوان صفحه اصلی مخزن شما آن را قرار خواهد داد. این فایل را هرگز فراموش نکنید. همچنین برای نوشتن محتوای آن، حتما سعی کنید که محتوای با معنی بنویسید. بهتر است در رابطه با اینکه این کد چه کاری را انجام می‌دهد در کدهای‌تان توضیحات مناسبی بنویسید.
اشتباه ۸: شیوه کار با پروژه را توضیح نداده‌اید
خب مطمئنا به عنوان یک فرد حرفه‌ای می‌توانم کدهای شما را مطالعه کنم و در نهایت به یک صورت آن را اجرا نمایم. اما برای آنکه پروژه شما حرفه‌ای تر به نظر برسد، حتما باید سعی کنید که یک دستورالعمل اجرایی را در کدهای‌تان بکار ببرید. باید به صورت واضح شیوه اجرای پروژه را در README.md بنویسید.
اشتباه ۹: نسخه زنده از پروژه‌تان ندارید
لینک گیت‌هاب را برای بازبینی ارسال کرده‌اید. حال به نظرتان فردی که برای بازبینی در شرکت نشسته باید پروژه را دریافت کرده و از ابتدا به صورت مستقل روی کامپیوتر خود آن را اجرا کند؟ نه! شما باید همواره یک نسخه زنده از پروژه‌ای که به شرکت تحویل میدهید را روی یک لینک داشته باشید. این لینک را نیز در توضیحات پروژه حتما باید قرار دهید.
اشتباه ۱۰: فایل‌های بی استفاده را از پروژه‌تان حذف نکرده‌اید
شبیه آن دسته از توسعه‌دهندگانی که یک دایرکتوری _old را در جایی از مخزن گیت دارند نباشید. این کار باعث کلی سوال‌های عجیب و غریب در ذهن فردی که قرار است کدهای شما را بازبینی کند بوجود بیاید. چکاری باید با این کدها بکنم؟ آیا باید به این کدها نیز نگاه کنم یا خیر؟ اصلا چرا این کدها اینجا هستند؟ حتی نمی‌دانم که به درستی چه چیزی بگویم. پس لطفا تمام آن کدهای قدیمی را از پروژه‌تان حذف کنید.
اشتباه ۱۱: یک ایمیل مناسب ننوشته‌اید
فقط یک ایمیل خالی همراه با لینک پروژه‌تان نفرستید. اینگونه توهین آمیز به نظر می‌رسد. بهتر است که یک ایمیل ساده با این حالت که: «سلام فلانی، حالتون خوبه؟ امیدوارم همه چی خوب باشه. لینک پروژه‌ای که تمام کردم رو براتون فرستادم: {لینک پروژه}. روز خوبی داشته باشید. ارسطو عباسی.» را ارسال نمایید. –بسته به شرکتی که در آن کار می‌کنید، حالت گفتاری/نوشتاری را تغییر دهید.-
اشتباه ۱۲: از ظاهر کار برمی‌آید که نیاز به تست دارد اما شما تست ننوشته‌اید
نشان دادن توانایی‌های‌تان در تست نویسی می‌تواند یک پوینت مثبت باشد. لازم نیست که کار عجیبی انجام دهید، همین که بتوانید تست‌هایی را بنویسید که می‌تواند کاربرد اصلی و هدف پایه‌ای پروژه‌تان را هدف بگیرد نشانه بسیار خوبی از شما را در ذهن کارفرما ایجاد می‌کند.
اشتباه ۱۳: همه کدهای‌تان را در یک فایل بزرگ نوشته‌اید
اگر تمام کدهایی که نوشته‌اید را تنها در یک فایل قرار داده و برای شرکت ارسال کنید، آن‌ها روی خوشی به شما نخواهند داد. بازبینی چنین فایلی بسیار کار سخت و طاقت‌فرسایی است و از طرفی دیگر ابدا کار حرفه‌ای نیست. شما باید سعی کنید که کدهای‌تان را در فایل‌های کوچکتری قرار دهید، انجام چنین کاری برای ویرایش‌های بعدی نیز بسیار خوب خواهد بود. پس لطفا کدهای‌تان را در فایل‌های کوچکتری قرار دهید تا بازبینی آن ساده‌تر شود.
اشتباه ۱۴: کامنت ننوشته‌اید
این دقیقا اشتباهی است که حتی توسعه‌دهندگان حرفه‌ای نیز انجام می‌دهند. البته صرف نوشتن کامنت تنها مسئله نیست، شما باید کامنت‌ها را مختصرتر و به سبک منحصر به فردی بنویسید. استفاده از کامنتی مانند // Loops through an array بسیار بهتر از شرح کامل آن به صورت // preparing data for sending it via AJAX است.
اشتباه ۱۵: کدهای‌تان ظاهر نامناسبی دارند
const array = [ 1, 2];
array.forEach((a ) =>{
a = a+ 1;
console.log(a) ;
}
);
نوشتن کد به این صورت تنها بی دقتی شما را نشان می‌دهد. برای حل چنین مشکلی می‌توانید از eslint و یا prettier استفاده کنید. حتی ویرایشگرها و IDEهای بزرگ نیز این کار را به صورت خودکار انجام می‌دهند.
اشتباه ۱۶: از نام‌های نامناسب برای متغیرها استفاده کرده‌اید
const b = true;
const a = [];
وقتی به نام این متغیرها فکر می‌کنید یاد چه چیزی می‌افتید؟ درست است هیچ چیز. B هیچ معنای مشخصی ندارد. پس بهتر است از نام‌های معناداری استفاده کنید:
const isReady = true;
const listOfPersons = [];
اشتباه ۱۷: کدهای قدیمی را کامنت کرده‌اید
افراد بسیار زیادی وجود دارند که بجای حذف کردن کدهای بی استفاده‌شان آن‌ها را کامنت می‌کنند! خب این کاری بسیار اشتباه است. چرا که هدف از المان کامنت غیر فعال کردن کدهای شما نیست، بلکه ارسال پیامی برای کمک به درک کدهاست. بجای کامنت کردن کدهای بی استفاده، آن‌ها را پاک کنید.
اشتباه ۱۸: نسخه نهایی کدهای‌تان را برای اجرا شدن بررسی نکرده‌اید
این اتفاقات بسیار مرسوم است. شما کدهایی را برای شرکت ارسال می‌کنید و بعد از آن یک بار کدهای‌تان را اجرا می‌کنید، بعد متوجه می‌شوید که بنابر تغییر کوچکی که دیشب فکر می‌کردید جزئی‌ست و نمی‌تواند تاثیر چندانی داشته باشد، پروژه شما اجرا نمی‌شود. پس سریع یک ایمیل دیگر می‌فرستید و در آن می‌گویید که ایمیل قبلی را بررسی نکنید این ایمیل نسخه جدید است.
واقعا بعضی از افراد چنین کاری را کرده‌اند! قبل از ارسال پروژه، به خوبی از ماهیت و روش اجرا شدن آن مطمئن شوید.
اشتباه ۱۹: چیزی را تغییر داده‌اید ولی اجرا نکرده‌اید
در واقع این اشتباه نیز به اشتباه شماره قبلی برمی‌گردد. تغییرات به محض ایجاد باید به خوبی بررسی و اجرا شوند. در غیر اینصورت می‌توانند کل پروژه شما را نابود نمایند.
اشتباه ۲۰: برای مصاحبه کاری در بخش کدنویسی آماده نشده‌اید
برخی اوقات بین ارسال پروژه و مصاحبه واقعی یک مدت زمانی فاصله می‌افتد. مثلا یک هفته یا بیشتر. آیا بعد از آن مدت هنوز هم قسمت‌های مختلف کدهایی که نوشته‌اید را به یاد دارید؟ مطمئن هستید که با دیدن کدهای خودتان غافلگیر نمی‌شوید؟
یکی از مهمترین اهداف مصاحبه صرفا این نیست که شما را به عنوان یک برنامه‌نویس خوب کشف کنیم. بلکه هدف ما این است که سازگاری بالایی در شما با تیم برنامه‌نویسان ببینیم. در واقع به همان اندازه که توانایی‌های تخصصی شما مهم است، توانایی‌های دیگرتان نیز برای یک شرکت اهمیت دارد.
این اشتباهات تنها مواردی بودند که من با آن‌ها برخورد کرده‌ام، اگر شما نیز چیزی در ذهن دارید خوشحال می‌شویم که با ما به اشتراک بگذارید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید