Я проаналізував 1500 вакансій і зрозумів одну річ: більшість кандидатів покращують резюме не там

💡 Усі статті, обговорення, новини про HR — в одному місці. Приєднуйтесь до HR спільноти!

Усім добрий день! Передусім перед початком статті хочу побажати всім людям хто буде читати цю статтю гарного дня!!

Коли людина довго не отримує відповідей від роботодавців, вона зазвичай починає «покращувати резюме».

Додає красивіший шаблон. Переписує блок «Про себе». Змінює фотографію. Додає ще кілька soft skills. Іноді навіть вставляє шкалу, де JavaScript — 90%, а командна робота — 95%.

Проблема в тому, що рекрутер навряд чи сидить і думає:

Непоганий кандидат, але шкала стресостійкості лише на 82%. Відмовляємо.

Мене звати Денис Івшин. Під час роботи над власним продуктом я почав аналізувати вакансії та порівнювати їх із резюме кандидатів. Спочатку це було невеликим технічним експериментом. Згодом у вибірці накопичилося понад 1500 вакансій — від junior-позицій до ролей, де роботодавці очікують кілька років досвіду.

І чим більше текстів я переглядав, тим очевиднішою ставала одна річ:

кандидати часто оптимізують зовнішній вигляд резюме, тоді як роботодавець шукає докази відповідності конкретній роботі.

Що саме я аналізував

У вибірку потрапили вакансії за кількома напрямами:

  • Python і backend-розробка;
  • frontend;
  • QA;
  • DevOps;
  • data-напрями;
  • product і project management;
  • маркетинг та суміжні позиції.

Для кожної вакансії я виділяв:

  • назву посади;
  • обов’язкові та бажані навички;
  • інструменти й технології;
  • вимоги до досвіду;
  • повторювані дієслова та формулювання;
  • очікувані результати роботи;
  • вимоги, які стояли на початку опису або повторювалися кілька разів.

Важливе обмеження: це не академічне дослідження всього українського чи глобального ринку праці. Вакансії були зібрані з різних відкритих джерел, а розподіл між професіями не був однаковим.

Але навіть у такій вибірці повторювалися дуже стабільні патерни.

Перша проблема: резюме описує людину, але не доводить її цінність

Розглянемо типове формулювання:

Працював над розробкою та підтримкою вебзастосунку.

Формально все добре. Але після прочитання незрозуміло майже нічого.

Що саме розробляв кандидат? Який був масштаб? За що він відповідав? Який результат отримала команда або бізнес?

Порівняймо:

Розробив REST API для системи обробки замовлень, оптимізував запити PostgreSQL і скоротив середній час відповіді з [X] до [Y] мс.

У другому варіанті немає магії. Він просто відповідає на запитання, які виникають у роботодавця.

Під час аналізу я помітив, що вакансії майже завжди описують роботу через дії:

  • розробляти;
  • інтегрувати;
  • оптимізувати;
  • автоматизувати;
  • аналізувати;
  • підтримувати;
  • впроваджувати;
  • покращувати.

А резюме кандидатів часто складаються з пасивних конструкцій:

  • брав участь;
  • був залучений;
  • працював із;
  • відповідав за;
  • допомагав команді.

«Працював із PostgreSQL» нічого не говорить про рівень людини. Вона могла проєктувати структуру бази, а могла один раз виконати SELECT *.

Друга проблема: кандидати перераховують технології, але не показують контекст

Ще один типовий блок:

Python, FastAPI, PostgreSQL, Docker, Git, AWS, Redis.

На перший погляд усе виглядає переконливо. Але список не пояснює:

  • що людина робила з FastAPI;
  • наскільки складною була база даних;
  • чи розгортала вона Docker-контейнери самостійно;
  • чи використовувала AWS у production;
  • чи просто проходила курс.

Роботодавцю важливо побачити зв’язок:

інструмент → завдання → результат.

Наприклад:

Реалізував backend на FastAPI, налаштував асинхронну обробку завдань і розгорнув сервіс у Docker на Google Cloud.

Навіть без складних метрик це вже краще за перелік із десяти логотипів.

Третя проблема: одне резюме надсилають на всі вакансії

Це, мабуть, найочевидніша і водночас найпоширеніша помилка.

Дві вакансії можуть називатися однаково — наприклад, Python Developer, — але одна компанія шукає людину для Django-моноліту, інша працює з FastAPI та мікросервісами, а третій потрібна автоматизація внутрішніх процесів.

Кандидат бачить однакову назву посади й надсилає той самий файл.

Роботодавець бачить різний набір потреб.

Адаптація резюме не означає, що потрібно вигадувати досвід або копіювати весь текст вакансії. Йдеться про інше:

  • підняти вище найбільш релевантний досвід;
  • конкретизувати потрібні технології;
  • прибрати другорядні деталі;
  • використовувати зрозумілі для цієї ролі формулювання;
  • показати ті результати, які важливі саме цьому роботодавцю.

Soft skills займають забагато місця

Майже в кожному другому резюме можна зустріти набір:

  • комунікабельність;
  • відповідальність;
  • стресостійкість;
  • уміння працювати в команді;
  • швидке навчання.

Проблема не в тому, що ці якості неважливі. Проблема в тому, що їх неможливо перевірити зі списку.

Людина, яка пише «я комунікабельний», не обов’язково справді комунікабельна. Так само ніхто не напише: «погано працюю в команді, конфліктую на кожному мітингу».

Soft skills краще показувати через факти:

Координував роботу з frontend- і DevOps-командами під час міграції сервісу.

Або:

Проводив code review та допомагав двом junior-розробникам із входженням у проєкт.

Це сильніше за слово «лідерство».

ATS — не чарівний робот, який вирішує долю кандидата

Навколо ATS виникло багато міфів.

Найпопулярніший звучить приблизно так:

Якщо в резюме немає потрібного ключового слова, робот одразу видаляє файл.

Насправді системи відрізняються. Десь ATS переважно зберігає й структурує кандидатів, десь допомагає з пошуком і фільтрами, а десь справді використовуються складніші механізми ранжування.

Але незалежно від конкретної системи залишається проста реальність:

якщо у вакансії п’ять разів згадується FastAPI, а в резюме людини цей досвід захований у кінці третьої сторінки, знайти відповідність буде складніше і машині, і людині.

Оптимізація під вакансію — це не обман алгоритму. Це нормальна професійна комунікація.

Що варто перевірити перед відгуком

Я сформулював для себе короткий список.

1. Чи зрозуміло за перші 10 секунд, на яку роль я претендую?

Не потрібно змушувати рекрутера збирати професійний профіль по шматках.

2. Чи є у резюме ключові вимоги вакансії, якими я справді володію?

Не всі слова з опису. Лише реальний досвід.

3. Чи описані результати, а не тільки обов’язки?

Навіть якщо немає revenue-метрик, можна вказувати масштаб, швидкість, кількість користувачів, автоматизовані процеси або скорочення ручної роботи.

4. Чи видно контекст використання технологій?

Не просто «Docker», а що саме було контейнеризовано та де розгорталося.

5. Чи немає в резюме інформації, яка займає місце, але нічого не доводить?

Шкали навичок, загальні soft skills, довгі описи нерелевантної роботи.

Головний висновок

Після аналізу 1500 вакансій я не побачив секретного формату, який гарантує офер.

Не існує одного ідеального шаблону. Не існує магічної кількості ключових слів. І навіть добре адаптоване резюме не компенсує відсутність потрібного досвіду.

Але є принцип, який стабільно відділяє сильні резюме від слабких:

сильне резюме не просто розповідає, ким є кандидат. Воно показує, чому його досвід відповідає конкретній роботі.

Красивий дизайн може допомогти прочитати текст. Але він не замінить зміст.

Цікаво, як ви адаптуєте резюме: змінюєте його під кожну вакансію чи використовуєте один універсальний варіант?

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

«єпископ Рима, вікарій Христа, наступник князя апостолів, Верховний понтифік Вселенської церкви, примас Італії, архієпископ і митрополит Римської провінції, суверен держави-міста Ватикан та слуга слуг Божих»

Проблема в тому, що рекрутер навряд чи сидить і думає:

Це Ви про ботів? Але навіщо їм сидіти? Сьогодні «воно» мені пропонувало роботу в... моїй компанії, на мій поточний проєкт

Так, саме про автоматизовані системи та алгоритми рекомендацій 🙂 І Ваш приклад якраз добре показує їхню недосконалість: якщо система пропонує Вам вакансію у Вашій же компанії на поточному проєкті, очевидно, що контекст вона розуміє далеко не завжди. Тому повністю покладатися на такі алгоритми при відборі кандидатів теж досить ризиковано.

Роботодавцю важливо побачити зв’язок: інструмент → завдання → результат.
Наприклад: Реалізував backend на FastAPI, налаштував асинхронну обробку завдань і розгорнув сервіс у Docker на Google Cloud.

З такого завдання — в мене теж питання як в Богдана:

Що ви робили весь інший час?

Бо тут роботи залежно від рівня — ну умовно на пару днів з Claude. Бо складність не в ключових словах, а в тому щоб інтерпретувати задачу в технічні завдання.

А з тих завдань, які дають розробникам, не завжди виходить щось по менеджерськи красиве. Бо могло бути пофіксити тут, пофіксити там, і в результаті за купу часу, могло не бути чогось значимого...
Або ж було, але не можна розповідати через NDA, або було 3-4 невеликі проекти, які треба було просто пофіксити тут і там.

Розумію вашу думку. Дійсно, далеко не кожну задачу можна або потрібно перетворювати на красивий «бізнес-результат». Частина роботи розробника — це підтримка, виправлення багів, невеликі зміни, дослідження або задачі, деталі яких не можна розкривати через NDA.

Я б тут скоріше говорив не про те, щоб штучно «роздувати» кожен пункт резюме, а про те, щоб максимально зрозуміло показати свою роль, контекст і технічний внесок там, де це можливо.

Власне, я зараз розвиваю невеликий стартап, який якраз займається аналізом і адаптацією резюме під конкретні вакансії. І одна з проблем, яку ми постійно бачимо, — універсальної формули для хорошого CV справді немає. Те, що добре виглядає для однієї вакансії, для іншої може бути майже нерелевантним.

Тому я скоріше за чесне резюме без вигаданих метрик, але з нормально поясненим внеском кандидата.

І тому краще зробити табличку сайд-бай-сайд: вимога (з тексту вакансії) — скіл (з вашого резюме), і покрити так всі вимоги.

Є проблема, яку навряд чи можливо вирішити — кандидат не знає, що хоче бачити в резюме конкретна людина (а зараз ще у система), яка буде його читати. Саме тому будь-яке покращення резюме буде «не там».

Зараз на ринку є тенденція рекомендувати «резалт/бізнес-орієнтовані резюме». Але от приклади, що ви наводите є досить сумнівними покращеннями. Розглянемо

Що саме розробляв кандидат? Який був масштаб? За що він відповідав? Який результат отримала команда або бізнес?

Порівняймо:

Розробив REST API для системи обробки замовлень, оптимізував запити PostgreSQL і скоротив середній час відповіді з [X] до [Y] мс.

У другому варіанті немає магії. Він просто відповідає на запитання, які виникають у роботодавця.

Ви частково відповіли на питання, які ви ж і поставили. А от інший роботодавець, побачить у такій відмовіді «відсутність у кандидата ширшого погляду і зацикленість на технічних деталях»:

  1. не показаний результата для бізнесу
  2. «середній час відповіді з [X] до [Y] мс» різна бізнес логіка вимагає різний час відповіді, в середньому значення в рамках всієї системи не мають сенсу
  3. А якщо це не в середньому, а 1 ендпоінт, то це круто, але ви описали 1-10 днів роботи. Що ви робили весь інший час?
Пункт 3 нас же приводить до питання про загальний об’єм резюме. Скільки буде займати таке резюме для людини з 10+ років досвіду? А для людей з досвідом до року протилежна проблема — що їм писати? Тобто ваші поради мають сенс, але для дуже обмеженої аудиторії (наприклад мідли з 1-4 років досвіду), яку ви не вказуєте.

А делі буде казочка:

Python, FastAPI, PostgreSQL, Docker, Git, AWS, Redis. (1)

...

Реалізував backend на FastAPI, налаштував асинхронну обробку завдань і розгорнув сервіс у Docker на Google Cloud. (2)

Навіть без складних метрик це вже краще за перелік із десяти логотипів.

Ви кажете, що 2 краще, але от я бачив кілька разів, коли контора для клієнта або навіть рекрутер на етапі найму зовнішнього кандидата, просили кандидата з 2 зробити 1, бо на тому ринку вони продавали набори навичок, а не бізенс цінність кандидата.

І це повертає нас до першого абзацу:
Ваше резюме завжди буде комусь не підходити. Тому або пишіть його під конкретні вимоги, якщо знаєте їх; або пишіть його так, щоб воно підійшло такому роботодавцю у якого ви хотіли б працювати (пишіть так, щоб воно підійшло вам, якби ви наймали людей). Друга порада все ж передбачає, що у вас є загальне розуміння реалій ринку.

Дякую за такий розгорнутий коментар. Насправді я багато в чому з вами погоджуюся.

Основна думка мого допису була не в тому, що існує одне «ідеальне» резюме. Навпаки — універсального шаблону немає. Одне й те саме резюме може сподобатися одному рекрутеру і зовсім не підійти іншому.

Приклади в статті були скоріше ілюстрацією принципу: замість простого переліку технологій або загальних фраз краще, коли кандидат додає контекст своєї роботи. Це не обов’язково мають бути бізнес-метрики — іноді їх неможливо розкрити через NDA або вони просто недоступні. Але навіть опис масштабу системи, відповідальності, архітектурних рішень чи технічних викликів уже дає більше інформації, ніж просто «Python, FastAPI, PostgreSQL».

Так само погоджуюся, що для різних ринків працюють різні підходи. Десь дійсно продають набір навичок, десь — досягнення, а найчастіше потрібен баланс між цими двома речами.

Тому, мабуть, найкраща рекомендація — адаптувати резюме під конкретну вакансію, коли це можливо. А якщо такої можливості немає, то робити його максимально зрозумілим і таким, щоб воно відображало реальний досвід кандидата, а не просто відповідало модним трендам.

Колись я намагався розгорнуто подавати власне резюме. Ледь впирався у 8 сторінок, усе одне рекрутери це або не читали, або не розуміли про що текст, або просто не розуміли, що саме треба читати і що з цього треба зрозуміти.
Надсилав резюме на дві сторінки — ефект аналогічний, скорше спричинений нестачею ключових слів в тексті.
І відповідали усі рекрутери шаблонно, що вирішили далі рухатися з іншими кандидатами, які більше відповідають потребам замовника.

У цьому якраз і проблема. Якщо резюме на 8 сторінок не читають, а на 2 сторінках не вистачає інформації чи ключових слів, значить справа не лише в довжині.

Сьогодні резюме має пройти дві перевірки: спочатку ATS або швидкий перегляд рекрутера за 20–30 секунд, а вже потім — уважне читання наймаючим менеджером. Тому важливо не просто додавати чи прибирати текст, а правильно структурувати інформацію, використовувати релевантні ключові слова й одразу відповідати на питання: що саме ви робили, з якими технологіями працювали та який результат отримали.

Саме тому одне й те саме резюме часто працює для однієї вакансії й абсолютно не працює для іншої. Не тому, що кандидат гірший, а тому, що воно не адаптоване під конкретний запит роботодавця.

а на 2 сторінках не вистачає інформації

для цього існує співбесіда. Резюме це статус відповідності вакансії.

Підписатись на коментарі