رزومه برنامه نویسی؛ نمونه پروژه، GitHub و اشتباهات رایج

اگر می‌پرسید رزومه برنامه نویسی چیست، پاسخ این است: سند کوتاهی که به استخدام‌کننده می‌گوید شما چه مسئله‌ای را برای چه کسی حل کرده‌اید، با چه شواهدی، و برای کدام نقش مناسبید — نه فهرستی از بیست ابزار که یک‌بار اسم‌شان را شنیده‌اید. رزومه برنامه نویسی جایگزین پروژه زنده و گفت‌وگوی مصاحبه نیست. کارش این است که در سی ثانیه اول رد نشود و خواننده را به لینک GitHub یا دمو برساند.

جست‌وجوهایی مثل «رزومه برنامه نویسی»، «نمونه رزومه برنامه‌نویس جونیور»، «GitHub در رزومه»، «اشتباهات رزومه فنی» و «آمادگی مصاحبه برنامه‌نویسی» معمولاً از کسی می‌آید که دوره دیده اما هنوز نمی‌داند کارفرما چه را می‌خواند. در این راهنما ساختار، نقش پروژه، پروفایل GitHub، خطاهای رایج و آمادگی مصاحبه را عملی می‌نویسیم. ساخت خودِ پروژه در مسیر شغلی برنامه‌نویسی است، اتصال لایه‌ها در مسیر فول‌استک، و بازخورد روی کار در خدمات منتورینگ روبینش.

Your profile README is a special repository that appears on your GitHub profile, letting you share information about yourself with the community.

رزومه برنامه نویسی چه کاری می‌کند و چه کاری نمی‌کند؟

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

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

یک صفحه برای جونیور و میدل معمولاً کافی است. دو صفحه وقتی معنا دارد که سابقهٔ تیمی، چند نقش یا پروژه‌های طولانی با مسئولیت روشن دارید. طول را با تکرار ابزار پر نکنید. هر خط باید به این سؤال جواب دهد: این evidenc برای نقش هدف چه کمکی می‌کند؟ اگر جواب «هیچ» است، خط را حذف کنید حتی اگر ساعت‌ها روی آن دوره وقت گذاشته‌اید.

نمونه پروژه بهتر از لیست مهارت است

لیست مهارت بدون پروژه برای استخدام‌کننده تقریباً بی‌معنی است. نوشتن React، Next، Node و PostgreSQL فقط ادعا است. نوشتن «فرم رزرو نوبت با احراز، ذخیره در دیتابیس و پیام وضعیت خطا» قابل بررسی است. سه پروژه کوچک کامل از یک پروژه عظیم نیمه‌تمام بهتر دیده می‌شوند، چون تمام‌کردن را نشان می‌دهند. جزئیات ساخت portfolio را در مسیر شغلی بخوانید؛ در رزومه فقط همان پروژه‌ها را با نتیجه و لینک بیاورید.

برای هر پروژه چهار چیز بنویسید: کاربر یا مسئله، کاری که شما کردید، فناوری مرتبط نه همهٔ استک دنیا، و لینک. اگر پروژه تمرینی است، آن را دروغ نگویید. بنویسید مسئله فرضی فروشگاه آزمایشی بوده، پرداخت واقعی وصل نشده، و چه را عمداً خارج گذاشته‌اید. صداقت اینجا اعتبار می‌سازد. ادعای «فروشگاه کامل با درگاه» وقتی دمو سبد خالی است، مصاحبه را خراب می‌کند.

اگر کارفرما فروشگاه می‌خواهد، پروژه‌ای نشان دهید که کشف محصول، سبد و یک جریان خرید آزمایشی دارد. مسیر ساخت ویترین را در طراحی سایت فروشگاهی ببینید و در رزومه ادعا نکنید «سئو فروشگاهی تسلط کامل» مگر کار قابل نمایش دارید. اگر هدف کلینیک یا نوبت است، صفحهٔ خدمت و فرم را نشان دهید نه قالب عمومی. جذب بیمار از جست‌وجو را در سئو سایت پزشکی جدا نگه دارید تا رزومه نقش طراح یا سئوکار را قاطی نکند مگر همان نقش را می‌خواهید.

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

GitHub را چطور به رزومه وصل کنیم؟

لینک GitHub در رزومه برنامه نویسی وقتی ارزش دارد که بازدیدکننده در کمتر از یک دقیقه بفهمد شما که هستید و کدام ریپو را باز کند. پروفایل README کوتاه، دو یا سه ریپوی پین، و ریپوی اصلی با توضیح مسئله کافی است. ریپوی درسی بدون README و با پوشهٔ «final-final2» سیگنال منفی است. تاریخ آخرین commit هم دیده می‌شود؛ شش ماه سکوت با ادعای «فعال در اوپن‌سورس» نمی‌خواند.

README را مثل صفحهٔ فرود پروژه بنویسید: مسئله، نحوهٔ اجرا، اسکرین‌شات یا لینک زنده، محدودیت، و کار بعدی. commit با پیام «fix» پشت‌سرهم بدون زمینه، کیفیت را پایین نشان می‌دهد. یک تاریخچهٔ کوتاه با پیام معنادار برای جونیور کافی و بهتر از تاریخچهٔ جعلی حجیم است. اگر هنوز با جریان شاخه و درخواست ادغام راحت نیستید، همان عادت را در پروژه‌های کوچک تمرین کنید؛ بازخورد کد را در کد ریویو چیست جدا بخوانید.

GitHub جایگزین رزومه نیست و رزومه جایگزین GitHub نیست. بعضی استخدام‌کننده‌ها اول PDF را می‌خوانند و بعضی اول لینک. هر دو باید نام نقش و پروژه‌های یکسان داشته باشند. اگر در رزومه Next نوشته‌اید و در گیت‌هاب فقط تمرین HTML است، تناقض دیده می‌شود. لینکدین را با همان داستان هماهنگ کنید اما آن را جای شواهد کد نگذارید مگر نقش‌تان غیرفنی است.

اشتباهات رایج در رزومه برنامه نویسی

• عنوان مبهم مثل «برنامه‌نویس و علاقه‌مند به فناوری» بدون نقش هدف
• جدول مهارت با نمرهٔ ستاره‌ای که هیچ‌کس معیارش را نمی‌داند
• کپی توضیحات دوره به‌جای توضیح پروژهٔ خودتان
• اغراق در عنوان سینیور وقتی هنوز پروژهٔ مستقل تمام نشده
• ایمیل غیرحرفه‌ای یا نبود راه تماس
• عکس و طرح گرافیکی شلوغ که نسخهٔ متنی و ATS را خراب می‌کند
• فهرست بیست فریم‌ورک که در هیچ ریپویی دیده نمی‌شود
• غلط املایی در نام فناوری و در فارسی عنوان شغل
• لینک شکسته به دمو یا ریپوی خصوصی بدون دسترسی

قالب رنگی با ستون کناری شلوغ ممکن است روی گوشی استخدام‌کننده غیرقابل خواندن شود. متن ساده با سلسله‌مراتب روشن معمولاً بهتر کار می‌کند. اگر طراح محصول هستید ظاهر رزومه بخشی از نمونه است؛ اگر برنامه‌نویسید، خوانایی و لینک مهم‌تر از گرادیان است. فایل PDF و یک نسخهٔ متنی یا وب کوتاه هر دو مفیدند. نام فایل را «resume-final3» نگذارید؛ نام و نقش کافی است.

ترجمهٔ ماشینی بدون ویرایش فارسی آسیب می‌زند. اگر رزومه را انگلیسی می‌فرستید، آن را یک انگلیسی بخوانید نه فارسی واژه‌به‌واژه. اگر فارسی می‌فرستید، اعداد، تاریخ و نام شرکت را یکدست کنید. تاریخ‌های overlapping یا «تاکنون» روی سه شغل هم‌زمان، سؤال ایجاد می‌کند. شکاف زمانی را دروغ پر نکنید؛ یادگیری یا پروژهٔ شخصی را شفاف بنویسید.

آمادگی مصاحبه بعد از رزومه

رزومه وعده است؛ مصاحبه تحویل آن وعده. برای هر پروژهٔ روی کاغذ آماده باشید بگویید مسئله چه بود، کدام راه‌حل را رد کردید، کجا گیر کردید و چه را هنوز نمی‌دانید. «نمی‌دانم، این‌طور امتحان می‌کنم» از حفظ تعریف کتاب قوی‌تر است اگر با صداقت باشد. شبیه‌سازی با منتور یا همکار بهتر از خواندن صد سؤال بدون پروژه است. ساختار همراهی را در تفاوت منتورینگ با دوره آموزشی ببینید. لایهٔ جلسه را در مصاحبه فنی برنامه نویسی تمرین کنید.

سؤال رفتاری را دست‌کم نگیرید. کارفرما می‌خواهد بداند با ابهام، مهلت و اختلاف نظر چه می‌کنید. یک داستان کوتاه با موقعیت، کار شما و نتیجه آماده کنید. داستان ساختگی زود لو می‌رود. اگر تجربهٔ تیمی ندارید، از تمرین گروهی، ریویو آنلاین یا پروژهٔ اوپن با issue واقعی بگویید — بدون بزرگ‌نمایی نقش.

آزمون زنده یا take-home را با همان استاندارد README جلو ببرید: فرض را بنویسید، محدوده را محدود کنید، تست یا حداقل مسیر اجرای روشن بگذارید. تحویل دیر و بی‌توضیح بدتر از محدودهٔ کوچک کامل است. اگر زمان کم آمد، در پیام بگویید چه را عمداً نساختید. این همان عادتی است که در کار واقعی هم لازم است. برای کار مستقل، جزئیات تحویل را در فریلنسری برنامه‌نویسی جدا ببینید.

رزومه را با نقش هدف هم‌تراز کنید

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

کلیدواژه‌های آگهی را فقط وقتی بیاورید که در پروژه هست. کپی همهٔ مهارت‌های آگهی داخل رزومه، فیلتر ماشینی را شاید رد کند اما مصاحبه را سخت می‌کند. بهتر است سه مهارت اصلی را با شواهد بیاورید تا دوازده مهارت بدون شاهد. اگر آگهی فروشگاه یا پزشکی است و شما آن حوزه را تجربه نکرده‌اید، پروژهٔ نزدیک یا یادگیری مرتبط را صادقانه بنویسید؛ ادعا نکنید «تخصص سئو پزشکی» مگر کار دارید.

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

بازار فارسی گاهی رزومه را با «معرفی» و سفارش شفاهی قاطی می‌کند. معرفی در را باز می‌کند اما همان سند و همان پروژه هنوز لازم است. اگر فقط روی رابطه حساب کنید و فایل و گیت‌هاب را رها کنید، در شرکت بعدی دوباره از صفر شروع می‌کنید. برعکس، ارسال انبوه بدون نقش هدف هم انرژی را می‌سوزاند. هفته‌ای چند آگهی هم‌خوان با نسخهٔ مناسب، از پنجاه ارسال کلی بهتر است. بعد از هر رد شدن، یک فرض را عوض کنید: نقش، پروژهٔ اول، یا توضیح مسئله — نه فقط رنگ قالب.

چک‌لیست قبل از ارسال رزومه برنامه نویسی

این فهرست را قبل از هر درخواست پر کنید. اگر دو مورد خالی ماند، همان را درست کنید نه اینکه بیست آگهی دیگر بفرستید.

1. نقش هدف در خط اول آمده است.
2. حداکثر سه پروژه با مسئله، کار شما و لینک.
3. GitHub یا دمو باز می‌شود و README دارد.
4. لیست مهارت با همان پروژه‌ها هم‌خوان است.
5. ایمیل و راه تماس حرفه‌ای است.
6. غلط املایی و لینک شکسته نیست.
7. برای آگهی فعلی یک تأکید جدا دارید نه فایل واحد ابدی.
8. آماده‌اید همان پروژه‌ها را در مصاحبه شرح دهید.

جمع‌بندی: سند کوتاه، شواهد باز، داستان یکسان

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

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