Войти
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 У меня есть аккаунт

Похожие должности