Увійти
PapaHR · Mike Pritula Academy · Посади

Розробник: профіль посади, KPI та запитання на співбесіді

Тут зібрано профіль розробника, ключові показники результативності (KPI) та матеріали для наймання. Вони допоможуть узгодити потрібний бізнесу результат і перевірити самостійність фахівця.

Створити профіль для своєї компанії Відкрити в PapaHR безплатно →

Профілі посад, найм, адаптація та оцінювання — у PapaHR. Безплатно для команд до 25 працівників.

  1. Візьміть профіль нижче або створіть власний у конструкторі.
  2. У PapaHR на основі профілю можна створити вакансію, план адаптації та цілі на випробувальний строк.
  3. Через 90 днів — оцінювання за тими самими KPI та компетенціями.

Профіль посади

Навіщо потрібна посада

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

Результат через рік

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

Місце у структурі

  1. ПідпорядковуєтьсяКерівнику розробки; у невеликій команді — технічному керівнику проєкту.
  2. ПідлегліНемає
  3. ВзаємодіяМенеджер продукту — користь змін та критерії приймання, Керівник проєкту — строки, залежності та черговість завдань, Тестувальник — сценарії перевірки та відтворення помилок, Дизайнер — поведінка інтерфейсу та неоднозначні стани, Служба підтримки — проблеми користувачів після випуску, Фахівець з інформаційних технологій (IT) — доступи та середовище
Ключові напрями результату
  1. Користувачі отримують узгоджені зміни — Виконання плану розробкиПриклад: виконано 100% узгодженого плану.
  2. Готові завдання проходять приймання без повернень — Приймання з першого разуПриклад: 100% уперше перевірених завдань прийнято без доопрацювань.
  3. Автоматичні перевірки захищають важливі сценарії — Виконання плану автоматичних перевірокПриклад: 100% запланованих сценаріїв захищені робочими тестами.
  4. Помилки виправляються в узгоджені строки — Своєчасне виправлення помилокПриклад: 100% помилок, строк виправлення яких настав, виправлено вчасно.
  5. Команда може підтримувати випущені зміни — Готовність документації до випускуПриклад: 100% запланованих описів готові до випуску змін.
Вимоги

Досвід: Досвід самостійних змін у робочому продукті відповідно до рівня вакансії.

Формальні вимоги: Уміння пояснити власний код і рішення; профільна освіта необов’язкова.

Потрібно знати

  • Мову програмування та бібліотеки, які використовує команда
  • Зберігання даних і перевірку їхньої цілісності
  • Принципи контролю версій і спільної роботи з кодом
  • Способи автоматичної перевірки програм
  • Обробку помилок, права доступу та захист секретів
  • Порядок збирання, випуску й повернення попередньої версії

Потрібно вміти

  • Читати наявний код перед зміною поведінки
  • Відтворювати помилку та перевіряти причину
  • Писати тести на важливі сценарії та обмеження
  • Пояснювати технічні рішення зрозумілою бізнесу мовою
  • Оцінювати роботу з урахуванням невідомих чинників і залежностей
  • Передавати зміни з інструкціями для перевірки та підтримки
Компетенції — три рівні

Розуміння завдання

Допомагає не витрачати час на функцію, яка не розв’язує проблему користувача.

  1. Переказує завдання й уточнює незрозумілі умови до початку роботи.базовий
  2. Узгоджує сценарії, обмеження та ознаки готовності до оцінювання строків.впевнений
  3. Знаходить зайву роботу й пропонує простіший спосіб отримати потрібний результат.сильний

Зрозумілий і зручний для підтримки код

Зменшує вартість наступних змін і залежність компанії від однієї людини.

  1. Дотримується структури проєкту та враховує зауваження під час перевірки коду.базовий
  2. Розділяє відповідальність компонентів і пояснює вибір рішення.впевнений
  3. Поступово спрощує складні ділянки, зберігаючи робочу поведінку продукту.сильний

Перевірка якості

Захищає користувачів від збоїв після змін і зменшує повторні виправлення.

  1. Перевіряє основний сценарій і додає тести за підказкою наставника.базовий
  2. Самостійно перевіряє межі, некоректні дані та пов’язані сценарії.впевнений
  3. Обирає перевірки за наслідками помилки та усуває причини повторних збоїв.сильний

Пошук причин помилок

Допомагає відновлювати роботу продукту без випадкових змін і повторних збоїв.

  1. Збирає умови помилки та відтворює її в безпечному середовищі.базовий
  2. Перевіряє гіпотези за даними й підтверджує виправлення повторною перевіркою.впевнений
  3. Локалізує збій між компонентами та пропонує захист від повторення.сильний

Відповідальність за результат

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

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

Спільна робота

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

  1. Пояснює свій код і ставить колегам конкретні запитання.базовий
  2. Дає корисні зауваження та обговорює рішення без переходу на особистості.впевнений
  3. Допомагає команді узгодити рішення й передає знання через спільну роботу.сильний
Конструктор

Створіть профіль для своєї компанії

Позначте, що ця людина робить у вашій компанії. Праворуч — готовий профіль: скопіюйте його або відкрийте в PapaHR.

Розробник

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

Обов’язки
  1. Уточнювати потребу користувача та критерії приймання до написання коду
  2. Розбивати зміни на невеликі завдання, які можна перевірити
  3. Оцінювати строки й завчасно повідомляти про ризики затримки
  4. Писати зрозумілий код із використанням прийнятих командою технологій
  5. Перевіряти звичайні сценарії, помилки та граничні випадки
  6. Покривати важливу логіку автоматичними тестами
  7. Перевіряти зміни колег і враховувати зауваження до власного коду
  8. Готувати випуск змін і спосіб повернення попередньої версії
  9. Знаходити причини збоїв і виправляти помилки
  10. Описувати запуск, обмеження та підтримку змінених компонентів
  11. Підключати зовнішні сервіси й обробляти відсутність з’єднання
  12. Переносити дані між версіями з перевіркою цілісності
  13. Прискорювати повільні операції після вимірювання причин
  14. Налаштовувати автоматичні перевірки перед випуском
  15. Брати участь в узгодженому чергуванні щодо збоїв продукту
  16. Навчати молодших розробників на спільних завданнях
  17. Оцінювати технічні обмеження нових продуктових ідей
Відкрити профіль у PapaHR

KPI розробника

  1. Виконання плану розробки — Прийняті завдання плану / завдання узгодженого плану × 100%. Помилка: Вважати завдання різної складності рівноцінними; приховувати перенесення зміною плану заднім числом.вага 30% · місяць
  2. Приймання з першого разу — Завдання, прийняті без доопрацювань / уперше перевірені завдання × 100%. Помилка: Виключати відхилені завдання з розрахунку; приймати код без перевірки умов завдання.вага 25% · місяць
  3. Виконання плану автоматичних перевірок — Сценарії плану з робочими тестами / заплановані сценарії × 100%. Помилка: Нарощувати кількість тестів без перевірки важливих сценаріїв і некоректних даних.вага 20% · місяць
  4. Своєчасне виправлення помилок — Вчасно виправлені помилки / помилки, строк виправлення яких настав × 100%. Помилка: Рахувати закриті звернення без перевірки виправлення; за відсутності помилок показник не розраховувати.вага 15% · місяць
  5. Готовність документації до випуску — Готові до випуску описи / описи за планом випуску × 100%. Помилка: Зараховувати текст, за яким колега не може запустити чи перевірити зміну.вага 10% · місяць
Калькулятор

Розрахуйте премію за KPI

Вкажіть виконання кожного показника у відсотках і суму премії за виконання на 100%. Вагу показників можна змінити.

ПоказникВага, %Виконання, %Внесок
Виконання плану розробки
Приймання з першого разу
Виконання плану автоматичних перевірок
Своєчасне виправлення помилок
Готовність документації до випуску
Підсумок за KPI
Премія
Сума ваг

Вага показників у прикладі — орієнтир. Сума ваг має становити 100%.

Запитання для співбесіди

Аркуш оцінювання

Проведіть співбесіду й отримайте підсумок

Оцінюйте кожну відповідь від 1 до 5: підсумок за компетенціями розрахується автоматично. Сторінку зручно тримати відкритою на телефоні під час співбесіди.

Розуміння завдання

Розкажіть про завдання з неповними вимогами. Що ви уточнили, що зробили самі та як перевірили результат?

✓ Що варто почути: Конкретні запитання, узгоджені сценарії, особисті дії та підтверджений результат.

⚑ Тривожний сигнал: Почав писати код без уточнень, потім звинуватив замовника.

Згадайте випадок, коли запропонували написати менше коду. Яку проблему розв’язували та що вийшло?

✓ Що варто почути: Зрозумів потребу, порівняв варіанти, узгодив спрощення та перевірив користь.

⚑ Тривожний сигнал: Прибрав потрібну поведінку без обговорення з власником завдання.

Зрозумілий і зручний для підтримки код

Розкажіть, як змінювали незнайому ділянку коду. Як розібралися, що змінили та як зберегли попередню поведінку?

✓ Що варто почути: Вивчив зв’язки, обмежив зміни, додав перевірки та пояснив результат.

⚑ Тривожний сигнал: Переписав велику ділянку без перевірки залежностей.

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

✓ Що варто почути: Визнає конкретну проблему, пояснює виправлення та ефект для команди.

⚑ Тривожний сигнал: Не може назвати власного невдалого рішення.

Перевірка якості

Згадайте зміну, що зламала пов’язану функцію. Як виявили проблему, виправили її та запобігли повторенню?

✓ Що варто почути: Називає пропущений сценарій, виправлення й тест, що виявляє попередню помилку.

⚑ Тривожний сигнал: Вважає перевірку виключно обов’язком тестувальника.

Розкажіть, як обирали перевірки за браку часу. Які ризики врахували та яким був результат випуску?

✓ Що варто почути: Виділив критичні сценарії, перевірив помилки, повідомив про залишкові ризики.

⚑ Тривожний сигнал: Перевірив лише успішний сценарій і нікого не попередив.

Пошук причин помилок

Опишіть складну помилку, яку виправили. Які гіпотези перевіряли та чим підтвердили причину?

✓ Що варто почути: Відтворення, спостереження, послідовна перевірка гіпотез і перевірка виправлення.

⚑ Тривожний сигнал: Змінював кілька речей одночасно й не зрозумів, що допомогло.

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

✓ Що варто почути: Уточнив середовище та вхідні дані, зібрав журнали подій, перевірив відмінності.

⚑ Тривожний сигнал: Закрив звернення, бо на його комп’ютері все працювало.

Відповідальність за результат

Коли ваша оцінка строку виявилася хибною? Як помітили, кому повідомили та як довели завдання до результату?

✓ Що варто почути: Ранній сигнал, пояснення причини, новий план та узгоджений результат.

⚑ Тривожний сигнал: Повідомив про затримку лише після пропущеного строку.

Розкажіть про випуск, за який відповідали. Що зробили до запуску, що перевірили після та що отримали?

✓ Що варто почути: Умови випуску, спосіб повернення версії, перевірка роботи та зв’язок із підтримкою.

⚑ Тривожний сигнал: Вважає завдання завершеним одразу після передавання коду.

Спільна робота

Згадайте суперечку під час перевірки коду. Що пропонували сторони, як домовилися та яким стало рішення?

✓ Що варто почути: Обговорив наслідки варіантів, використав факти, зафіксував домовленість.

⚑ Тривожний сигнал: Нав’язував рішення авторитетом або обговорював особисті якості колеги.

Розкажіть, як передавали компонент іншому розробнику. Що підготували та як переконалися, що він може працювати самостійно?

✓ Що варто почути: Пояснив будову, описав запуск і перевірив самостійну зміну колегою.

⚑ Тривожний сигнал: Надіслав посилання на код і вважав передавання завершеним.

Оцініть хоча б одну відповідь — тут з’явиться підсумок. ·
Вести кандидатів у PapaHR

Тестове завдання

Резервування товару без часткового списання · 2 години

Напишіть невелику функцію мовою, узгодженою з кандидатом. На вхід надходять залишки товарів і позиції замовлення: код товару та кількість. Повторювані позиції потрібно об’єднати. Кількість має бути додатним цілим числом, а товар — існувати. Якщо залишку достатньо, поверніть нові залишки. За будь-якої помилки поверніть зрозумілу причину, не змінюючи вхідних даних. База даних та інтерфейс не потрібні. Додайте автоматичні тести, інструкцію запуску й коротке пояснення рішень. Покажіть успішне замовлення, повторювані позиції, невідомий товар, некоректну кількість і нестачу залишку. Якщо не встигаєте, зазначте обмеження. Використовуйте лише навчальні дані.

Як оцінити

  • Усі умови виконано; повторювані позиції враховано разом
  • Помилка в одній позиції унеможливлює часткове списання
  • Вхідні дані збережено за будь-якого результату
  • Тести перевіряють успішне замовлення, помилки та граничні значення
  • Код зрозумілий, без зайвих компонентів і залежностей
  • Інструкція дає змогу запустити рішення; обмеження названо прямо

Готовий текст вакансії

Розробник у команду [назва компанії]

Розвиваємо [продукт] для [користувачі]. Шукаємо розробника для [зона відповідальності].

Завдання

  • Розробляти [компоненти продукту] на [мова та технології]
  • Узгоджувати поведінку функцій із [власник продукту]
  • Писати автоматичні тести для важливої логіки
  • Перевіряти код колег і враховувати зворотний зв’язок
  • Виправляти помилки та перевіряти роботу після випуску
  • Підтримувати інструкції запуску й описи змін

Вимоги

  • Досвід розробки на [мова] відповідно до [рівень посади]
  • Уміння розбиратися в наявному коді
  • Навичка спільної роботи через систему контролю версій
  • Уміння писати тести й знаходити причини помилок
  • Готовність обговорювати строки, обмеження та користь змін

Ми пропонуємо

  • Зарплата: [зарплата] грн, [порядок перегляду]
  • Графік: [графік], формат роботи: [формат]
  • Місце роботи: [місто]
  • Команда: [склад команди], керівник: [роль керівника]
  • Обладнання та доступи: [умови забезпечення]
  • Навчання і зворотний зв’язок: [формат та періодичність]

У PapaHR цей текст стає вакансією з кар’єрною сторінкою та воронкою кандидатів.

План адаптації на 90 днів

До першого робочого дня

  1. Надіслати графік виходу та контакти командиHR
  2. Підготувати обладнання й доступи з необхідними правамиIT
  3. Обрати перше невелике завдання з критеріями прийманняКерівник
  4. Перевірити інструкцію запуску проєкту для новачкаНаставник

Перший день

  1. Показати продукт і основні дії користувачаКерівник
  2. Пояснити зберігання секретів і порядок отримання доступівIT
  3. Запустити проєкт та автоматичні перевірки в робочому середовищіНовий працівник
  4. Показати порядок перевірки коду й випуску змінНаставник

Перший тиждень

  1. Виконати перше завдання й додати перевірку результатуНовий працівник
  2. Розібрати першу зміну та пояснити зауваженняНаставник
  3. Показати журнали помилок і спосіб повернення версіїНаставник
  4. Узгодити цілі випробувального строку та способи перевіркиКерівник

30 днів

  1. Випустити невелику зміну під наглядом наставникаНовий працівник
  2. Розібрати помилку від відтворення до перевірки виправленняНовий працівник
  3. Обговорити точність оцінок і причини затримокКерівник
  4. Перевірити, чи вистачає доступів і допомоги командиHR

60 днів

  1. Самостійно уточнити й виконати завдання узгодженої складностіНовий працівник
  2. Додати тести на ризиковані сценарії власної зміниНовий працівник
  3. Перевірити користь зауважень новачка до коду колегНаставник
  4. Звірити результати з цілями випробувального строкуКерівник

90 днів

  1. Показати випущені зміни та підтвердження їхньої роботиНовий працівник
  2. Перевірити інструкцію новачка запуском компонента іншим розробникомНаставник
  3. Оцінити самостійність, якість і виконання узгодженого плануКерівник
  4. Обговорити підсумки випробувального строку та подальший розвитокКерівник

Цілі на випробувальний строк

  1. Освоїти робочий цикл від запуску проєкту до випуску зміниДо 30-го дня самостійно запускає проєкт; зміну випущено з наставником і перевірено.
  2. Самостійно доводити узгоджені завдання до прийманняДо 90-го дня виконано узгоджений план; для кожного завдання підтверджено критерії приймання.
  3. Захистити важливі сценарії власних змін автоматичними тестамиДо 60-го дня перевіряються всі сценарії узгодженого списку; тести виявляють навмисно внесену помилку.
  4. Передати знання про підтримку зміненого компонентаДо 90-го дня колега запускає компонент і перевіряє зміну за підготовленою інструкцією.

Кар’єрний шлях

Молодший розробник

Виконує невеликі завдання зі зрозумілими умовами та регулярною допомогою наставника.

Для переходу: Самостійно уточнювати й завершувати типові завдання, писати перевірки та враховувати зауваження.

Розробник

Відповідає за зміну повністю: уточнення, код, перевірки, випуск і підтримку.

Для переходу: Розв’язувати неоднозначні завдання, бачити залежності й допомагати колегам покращувати рішення.

Старший розробник

Проєктує складні зміни, зменшує технічні ризики й розвиває інших розробників.

Для переходу: Для керівної ролі — освоїти планування команди, зворотний зв’язок і розподіл відповідальності.

Керівник розробки

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

Для переходу: Розширювати відповідальність за технічний напрям зі зростанням бізнесу та команди.

Запитання для зустрічі 1:1

  1. У якому поточному завданні ще незрозуміло, який результат потрібен користувачу?
  2. Яка залежність може зрушити строк і чим я можу допомогти?
  3. Де ми найчастіше переробляємо код після приймання й чому?
  4. Яку частину продукту зараз найризикованіше змінювати без додаткових перевірок?
  5. Яка ручна операція під час випуску забирає найбільше часу?
  6. Які зауваження до вашого коду повторюються та що допоможе їх усунути?
  7. Що в підтримці компонента зараз відомо лише вам?
  8. Яке наступне завдання хочете взяти для розвитку самостійності?

Помилки під час найму та управління

  1. Наймати за переліком технологій без обговорення власних рішень кандидата.
    Як краще: Розібрати конкретну зміну: завдання, код, перевірки, обмеження та результат.
  2. Оцінювати продуктивність кількістю рядків коду чи закритих дрібних завдань.
    Як краще: Дивитися на прийняті зміни, складність роботи та якість після випуску.
  3. Змінювати вимоги й залишати попередній строк без обговорення.
    Як краще: Повторно узгодити обсяг, строк і пріоритет; зберегти історію змін плану.
  4. Передавати тестувальнику всю відповідальність за помилки розробника.
    Як краще: Включати власні перевірки й автоматичні тести до критеріїв готовності завдання.
  5. Зосереджувати код і випуск продукту в руках одного сильного розробника.
    Як краще: Перевіряти код колегами, описувати запуск і регулярно передавати підтримку компонентів.
HR у грошах

Скільки коштує помилка найму розробника

Той самий розрахунок, що в розділі PapaHR «HR у грошах»: вартість добору плюс зарплата за місяці, коли новий працівник працював упівсили.

Одне звільнення
За рік

У перші місяці новий працівник дає приблизно половину результату — другу половину зарплати компанія платить за навчання. У PapaHR розрахунок ґрунтується на фактичних звільненнях у вашій компанії.

Запитання та відповіді

Чим розробник відрізняється від програміста?

У вакансіях ці назви часто означають одну роль. Для наймання важливіше описати відповідальність: лише писати код чи також уточнювати завдання, перевіряти й випускати зміни. Зазначте це в профілі та оголошенні.

Як перевірити розробника, якщо керівник не вміє програмувати?

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

Які показники підходять для оцінювання розробника?

Почніть із виконання узгодженого плану, приймання та перевірки важливих сценаріїв. Враховуйте складність завдань, нові вимоги й зовнішні затримки. Кількість рядків коду не показує користь зміни.

Чи потрібна розробнику вища технічна освіта?

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

Чи можна доручити одному розробнику весь продукт?

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

Наймайте, адаптуйте й оцінюйте — в одній системі

PapaHR безплатна для команд до 25 працівників: профілі посад, вакансії, адаптація, цілі, зустрічі 1:1 та оцінювання.

Відкрити профіль у PapaHR У мене є обліковий запис

Схожі посади