نمونه رزومه برنامه‌نویس

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

رزومه‌ی این شغل چه چیزی باید ثابت کند

  • اینکه کد شما به دست کاربر رسیده است

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

  • عمق در یک حوزه، نه سطح در ده حوزه

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

  • اینکه در تیم و در کنار کد دیگران کار کرده‌اید

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

  • اثر کارتان روی چیزی که برای کسب‌وکار مهم است

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

  • پیوندی که بشود واقعاً بازش کرد

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

کلیدواژه‌هایی که ATS دنبالشان می‌گردد

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

  • JavaScript
  • TypeScript
  • Python
  • React
  • Node.js
  • REST API
  • Git
  • SQL
  • Docker
  • CI/CD
  • unit testing
  • code review
  • Agile
  • میکروسرویس
  • کنترل نسخه

نمونه جمله‌های تجربه‌ی کاری

هر جمله می‌گوید چه کاری انجام شد و چه چیزی در نتیجه‌اش تغییر کرد — الگویی که می‌توانید برای کار خودتان بازنویسی کنید.

  • زمان بارگذاری صفحه‌ی اصلی را با بازنویسی لایه‌ی داده و افزودن کش سمت سرور از ۴.۲ ثانیه به ۱.۱ ثانیه رساندم.
  • یک سرویس پرداخت را از مونولیت جدا کردم و به میکروسرویس مستقل تبدیل کردم؛ استقرارهای مربوط به پرداخت از هفته‌ای یک بار به روزی دو بار رسید.
  • پوشش تست واحد ماژول سفارش را از ۱۸ درصد به ۷۶ درصد رساندم و تعداد باگ‌های گزارش‌شده در محیط عملیاتی را در سه ماه ۴۰ درصد کاهش دادم.
  • خط لوله‌ی CI را بازطراحی کردم و مدت اجرای آن را از ۲۲ دقیقه به ۶ دقیقه رساندم، که چرخه‌ی بازخورد روی هر پول‌ریکوئست را کوتاه کرد.
  • فرایند دستی تولید گزارش ماهانه را با یک اسکریپت زمان‌بندی‌شده جایگزین کردم و حدود ۱۰ ساعت کار انسانی در ماه آزاد شد.

نمونه رزومه

سارا رستمی

برنامه‌نویس ارشد بک‌اند

  • تهران
  • [email protected]
  • ۰۹۱۲ ۰۰۰ ۰۰۰۰
  • github.com/example-handle
  • linkedin.com/in/example-handle

خلاصه

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

سوابق کاری

  1. برنامه‌نویس ارشد بک‌اند۱۴۰۲ تا کنون
    یک فروشگاه اینترنتی متوسط
    • سرویس سفارش را از مونولیت جدا کردم؛ زمان استقرار تغییرات مربوط به سفارش از ۴۰ دقیقه به ۷ دقیقه رسید.
    • با افزودن کش و بازنویسی کوئری‌های سنگین، زمان پاسخ صفحه‌ی جست‌وجو را ۶۵ درصد کاهش دادم.
    • فرایند کد ریویو تیم را مستند و اجباری کردم؛ باگ‌های رسیده به محیط عملیاتی در دو فصل نصف شد.
  2. برنامه‌نویس بک‌اند۱۳۹۹ تا ۱۴۰۲
    یک استارتاپ حوزه‌ی لجستیک
    • API عمومی ردیابی مرسولات را طراحی و پیاده‌سازی کردم که در پایان سال اول روزانه حدود ۲۰۰ هزار درخواست را پاسخ می‌داد.
    • پوشش تست سرویس مسیریابی را از صفر به ۷۰ درصد رساندم و استقرار هفتگی را بدون بازگشت به عقب ممکن کردم.

مهارت‌ها

  • TypeScript
  • Node.js
  • PostgreSQL
  • Redis
  • Docker
  • REST API
  • Git
  • CI/CD
  • unit testing

تحصیلات

  • کارشناسی مهندسی کامپیوتریک دانشگاه دولتی۱۳۹۵ تا ۱۳۹۹

این نمونه کاملاً ساختگی است. نام، اطلاعات تماس و سوابق آن به هیچ فرد واقعی تعلق ندارد.

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

  • فهرست کردن هر فناوری که تا به حال دیده‌اید

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

  • نوشتن شرح وظایف به‌جای دستاورد

    «توسعه و نگهداری بک‌اند» شرح شغل است، نه کار شما. هر جمله باید بگوید چه کاری کردید و چه چیزی در نتیجه‌ی آن تغییر کرد. اگر جمله‌ای را می‌شود عیناً در رزومه‌ی هم‌تیمی‌تان گذاشت، آن جمله چیزی درباره‌ی شما نمی‌گوید.

  • رزومه‌ی گرافیکی چندستونه که ATS نمی‌تواند بخواند

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

  • پروژه‌های شخصی بدون هیچ زمینه‌ای

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

  • یک رزومه‌ی واحد برای همه‌ی آگهی‌ها

    وقتی آگهی روی تایپ‌اسکریپت و تست تأکید دارد و رزومه‌ی شما با تجربه‌ی پی‌اچ‌پی شروع می‌شود، هم امتیاز تطابق ATS پایین می‌آید و هم ریکروتر در همان چند ثانیه‌ی اول رد می‌شود. ترتیب و تأکید را برای هر آگهی تغییر دهید.

پرسش‌های پرتکرار

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

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

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

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

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

رزومه‌ی خودت را با همین اصول بساز

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

نمونه رزومه‌های مرتبط