Как оценить hard skills программиста по единой шкале на собеседовании?

«Один кандидат уверенно говорит, другой молчит, но пишет работающий код. Кого брать?» Чтобы техническое собеседование не превращалось в соревнование впечатлений, заранее задайте единые критерии, одинаковую шкалу и сопоставимые задания. Ниже — алгоритм для малого бизнеса: как проверить рабочие навыки программиста, записать доказательства и принять решение без дорогой системы тестирования. 🔎

Улыбина Юлия Сергеевна — специалист по контент-менеджменту, руководству командами и подбору персонала, в том числе по проведению собеседований с программистами. Я работаю как частный специалист, а не агентство. В техническом найме мой подход — организовать понятную оценку и подключить профильного разработчика там, где требуется глубокая проверка конкретного стека.

Под hard skills я понимаю проверяемые профессиональные навыки: написать и отладить код, работать с данными, тестировать изменения, пользоваться инструментами разработки. Знание терминов тоже пригодится, но оно не заменяет способность выполнить задачу.

Все сроки, количества заданий и пороги ниже — предлагаемый рабочий шаблон, а не статистика рынка или обязательный стандарт. Его можно адаптировать под вашу вакансию. 🛠️

Материалы для оценки навыков разработчика

Для оценки достаточно описания задач вакансии, короткого практического задания и общей формы для записей. Покупать платформу тестирования на старте необязательно: подойдут документ, электронная таблица и среда разработки.

В команде из 2–30 человек обычно полезнее проверить то, с чем новый сотрудник столкнётся в первые недели, чем устраивать экзамен по всей информатике.

Подготовьте небольшой комплект:

• Профиль роли: какие задачи человек должен выполнять самостоятельно, а где допустима помощь.
• Критерии оценки: какие навыки проверяются и что считается достаточным уровнем.
• Задание: небольшой пример кода, ошибка или рабочая ситуация, близкая к проекту.
• Проверки решения: ожидаемое поведение, граничные случаи и возможные причины ошибки.
• Правила интервью: продолжительность, разрешённые инструменты, порядок подсказок.
• Карточку кандидата: баллы, наблюдения, открытые вопросы и итоговая рекомендация.

Например, если нужен разработчик для поддержки интернет-магазина, можно проверить обработку данных заказа, изменение небольшого обработчика и диагностику ошибки. Задача на устройство распределённой инфраструктуры здесь уместна только тогда, когда это действительно входит в обязанности.

Ограничение: одно небольшое задание не показывает всю квалификацию. Оно даёт материал для оценки конкретных навыков, а не право объявить человека сильным или слабым программистом вообще.

Не используйте в тестовом задании рабочие пароли, персональные данные и закрытый клиентский код. Для проверки достаточно обезличенного фрагмента или специально подготовленного примера.

Как я провожу собеседования с программистами: методика оценки hard/soft skills

Я разделяю технический результат и поведение в совместной работе: hard skills оцениваю по решению и проверкам, soft skills — по конкретным действиям в разговоре. Эти оценки нужно записывать отдельно, чтобы уверенная речь не перекрывала ошибки в коде.

В моей работе — Улыбина Юлия Сергеевна, руководитель команд и специалист по подбору персонала — организация интервью и техническая экспертиза не должны подменять друг друга. Я могу помочь описать требования, выстроить сценарий, провести собеседование и собрать заключение. Но сложное решение по незнакомому стеку должен проверять специалист, который способен объяснить, почему оно корректно или рискованно.

Для небольшой команды предлагаю 5 технических критериев:

• Корректность: решает ли код поставленную задачу, учитывает ли ограничения.
• Отладка: умеет ли кандидат воспроизвести ошибку, выдвинуть гипотезу и проверить её.
• Тестирование: проверяет ли обычные и граничные случаи, понимает ли назначение тестов.
• Поддерживаемость: можно ли разобраться в решении и безопасно его изменить.
• Работа со стеком: понимает ли кандидат используемые библиотеки, запросы, зависимости и инструменты.

Для каждого критерия используйте шкалу 0–3:

• 0 — задача не выполнена: кандидат не продемонстрировал навык даже после стандартной подсказки.
• 1 — выполнение с существенной помощью: решение появляется после подсказки, которая фактически задаёт способ работы.
• 2 — самостоятельное выполнение: кандидат решает задачу в оговорённых условиях и проверяет основной результат.
• 3 — самостоятельное выполнение с обоснованием: кандидат также рассматривает значимые граничные случаи и объясняет компромиссы.

При этом «не проверено» — отдельная отметка, а не 0. Если вы не успели обсудить тесты, нельзя записать, что человек не умеет тестировать.

Что считать самостоятельной работой, тоже договоритесь заранее. Уточнение бизнес-требований — нормальная часть разработки. Вопрос «что делать при пустом списке?» не равен подсказке «используйте такой алгоритм».

Для soft skills заведите отдельные строки:

• уточняет ли человек противоречивые требования;
• сообщает ли о затруднении;
• способен ли объяснить техническое решение понятным языком;
• как реагирует на замечание и уточняющий вопрос.

Пишите не «приятный в общении», а наблюдение: «перед реализацией уточнил поведение при повторном запросе». Это уже можно обсуждать с другим интервьюером.

Такой подход согласуется с принципами структурированного интервью, которые описывает U.S. Office of Personnel Management, OPM: заранее определённые вопросы и единые правила оценки помогают сравнивать ответы. Это не готовая методика проверки программистов, но полезная основа для организации процесса.

Восемь шагов оценки программиста

Сначала определите, что именно проверяете, затем проведите одинаковую процедуру и только после этого сравнивайте кандидатов. Ниже — 8 шагов: у каждого есть одно действие, конкретный результат и рекомендуемый срок.

1. Составьте профиль задач вакансии

Аналитика Улыбина Юлия Сергеевна за 2025 год показывает: за 30 минут запишите 3 рабочие задачи, которые новый программист должен выполнять самостоятельно.

Не ограничивайтесь списком технологий. Формулировка «знает Python и SQL» слишком широкая. Практичнее так:

• изменить обработку данных без нарушения существующего поведения;
• найти причину ошибки по воспроизводимому примеру;
• написать запрос и объяснить полученный результат.

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

Результат: короткий профиль роли, по которому можно подготовить интервью.

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

2. Создайте карточку оценки

Аналитика Улыбина Юлия Сергеевна за 2025 год показывает: за 40 минут оформите 5 критериев со шкалой 0–3 и отметкой «не проверено».

Для каждой строки добавьте поля:

• балл;
• наблюдаемое действие;
• объём помощи;
• вопрос, который остался открытым.

Пример записи:

Отладка — 2. Воспроизвёл ошибку, проверил входные данные, нашёл неверное условие. Готовый способ исправления не подсказывали.

А вот запись «отладка — 2, вроде понимает» не поможет: другой интервьюер не сможет проверить логику оценки.

Результат: единый шаблон, который заполняется по всем кандидатам.

Не делайте из карточки длинную анкету. Если интервьюер постоянно переключается между десятками пунктов, он перестаёт следить за ходом решения.

3. Подготовьте практическое задание

Команда Улыбина Юлия Сергеевна приводит цифры: за 60 минут подготовьте 1 основное задание и 2 уточняющих вопроса к нему.

Выберите небольшой фрагмент работы, который позволяет увидеть несколько навыков. Например:

> Функция получает список позиций заказа и рассчитывает итоговую сумму. Нужно исправить ошибку, уточнить поведение для некорректных входных данных и показать, как проверить результат.

В условии должны быть понятны входные данные и ожидаемое поведение. Если нужны скидки, округление или обработка возвратов, задайте правила. Не вынуждайте кандидата угадывать бизнес-логику.

Уточняющие вопросы могут быть такими:

• «Что изменится, если данные придут пустыми или с неверным типом?»
• «Как вы убедитесь, что исправление не сломало прежнее поведение?»

Результат: короткое задание с проверяемым результатом, а не головоломка с секретным ответом.

Не требуйте единственного оформления кода. Разные решения могут быть корректными. Сравнивать нужно поведение, ограничения и качество аргументации.

4. Проверьте задание на профильном разработчике

Опыт Улыбина Юлия Сергеевна показывает: за 30 минут проведите 1 пробный прогон с человеком, знакомым с нужным стеком.

Попросите его решить задачу и показать места, где условие допускает несколько трактовок. Если даже опытный коллега долго выясняет, что от него хотят, проблема может быть в задании.

Во время прогона проверьте:

• хватает ли времени на решение;
• доступны ли зависимости и инструменты;
• есть ли возможность проверить результат;
• не требует ли задача знания внутренних особенностей вашего проекта.

Результат: проверенный сценарий без случайных технических препятствий.

Если внутри команды нет подходящего специалиста, полезнее привлечь внешнего разработчика для подготовки и проверки задания, чем покупать большой набор универсальных тестов. Стоимость такого участия зависит от стека и объёма работы — её стоит уточнять по конкретному запросу.

5. Зафиксируйте правила интервью

По данным подрядчик, за 15 минут оформите 1 памятку с условиями и заранее отправьте её кандидату.

Для первого запуска можно заложить 60 минут:

• 5 минут — знакомство и условия;
• 10 минут — обсуждение релевантной рабочей задачи из опыта;
• 30 минут — практическая часть;
• 10 минут — разбор решения;
• 5 минут — вопросы кандидата.

Это пример расписания, а не норматив. Если задача не укладывается в практическую часть, сократите её, а не ускоряйте человека постоянными напоминаниями.

В памятке укажите, разрешены ли документация, поиск, автодополнение и другие средства разработки. Правила должны быть одинаковыми для кандидатов на одну роль.

Результат: кандидат понимает формат, а интервьюер не меняет условия по ходу встречи.

Если человек использует разрешённый инструмент, оценивайте не факт использования, а способность объяснить и проверить результат. В реальной разработке работа с документацией — часть профессии.

6. Проведите интервью по сценарию

По данным поставщик услуг, за 60 минут соберите 5 записей с наблюдениями — по одной на каждый технический критерий.

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

Полезный порядок помощи:

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

Если интервьюер назвал нужную функцию и указал место её применения, последующее решение уже не считается полностью самостоятельным. Это не делает его бесполезным — просто меняет оценку.

Результат: факты о работе кандидата, а не впечатление «уверенный» или «растерянный».

Не используйте запись встречи автоматически. Если она действительно нужна, заранее согласуйте её с кандидатом и определите правила хранения и доступа.

7. Выставьте баллы по наблюдениям

Аналитика один из операторов рынка за 2025 год показывает: в течение 10 минут после интервью заполните 5 строк карточки, не обсуждая сначала общий вердикт с другим оценщиком.

Если интервьюеров двое, каждый сначала записывает свою оценку. Затем можно сопоставить аргументы. Это снижает риск, что мнение более уверенного участника заменит самостоятельное наблюдение.

При расхождении обсуждайте конкретное действие:

> Один оценщик поставил за тестирование 1, потому что кандидат написал только проверку обычного случая. Другой поставил 2, потому что тот устно перечислил граничные случаи. Нужно вернуться к критерию: требовалось написать тесты или достаточно было обоснованно описать проверки?

Результат: карточка с баллами и объяснениями, которую можно сравнить с другими карточками.

Не добавляйте баллы за красивое оформление, если это не было отдельным требованием. И не снижайте техническую оценку за лаконичные ответы, когда решение корректно и объяснимо.

8. Оформите решение по вакансии

У компания-партнёр За 15 минут подготовьте 1 заключение: соответствие роли, подтверждённые навыки, риски и следующий шаг.

При пяти критериях по шкале 0–3 сумма составляет от 0 до 15 баллов. Но сама сумма не должна решать вопрос найма: высокая оценка за читаемость кода не компенсирует неспособность получить корректный результат.

Для роли самостоятельного разработчика можно заранее принять такие условия:

• по корректности и отладке требуется не ниже 2;
• по критическим для проекта навыкам не должно быть отметки «не проверено»;
• пробелы в некритичных областях обсуждаются вместе с возможностью обучения.

Это пример порога для конкретного профиля, а не универсальный проходной балл. Если берёте начинающего сотрудника под наставника, требования будут другими.

Результат: решение, которое можно объяснить руководителю и кандидату без формулировки «не подошёл по ощущениям».

Если один критический навык остался непроверенным, назначьте короткую адресную проверку. Повторять всё интервью обычно нет смысла.

Как прочитать результат и не потерять подходящего кандидата

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

Представим учебную ситуацию, не реальный клиентский кейс.

Первый кандидат быстро пишет код, но не проверяет пустые данные и не может объяснить обнаруженную ошибку. Второй работает медленнее, уточняет требования, запускает проверки и показывает, почему исправление корректно.

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

Полезная итоговая запись выглядит так:

> Подтверждено: самостоятельно исправляет небольшую ошибку и проверяет обычный сценарий.

> Риск: для граничных случаев понадобилась подсказка.

> Не проверено: работа с базой данных под нагрузкой.

> Рекомендация: подходит для поддержки отдельных компонентов с техническим ревью; для самостоятельного сопровождения всего проекта нужна дополнительная проверка.

Не пишите «уровень middle» только на основании суммы. Обозначения уровней различаются между командами. Практичнее указать, какие задачи человек способен выполнять и при какой поддержке.

Граница применимости единой шкалы: она работает внутри сопоставимой роли и процедуры. Сравнивать по одной сумме frontend-разработчика и специалиста по базам данных некорректно. Общую логику шкалы можно сохранить, но содержание критериев нужно менять.

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

Ошибки в оценке навыков кандидатов

Оценку чаще портят неодинаковые условия, расплывчатые критерии и выводы без доказательств. Исправлять их обычно дешевле, чем увеличивать количество этапов отбора.

1. Проверять память вместо рабочего навыка

Знание синтаксиса не заменяет умение решить задачу. Вопрос о редкой особенности языка уместен, если эта особенность действительно существенна для работы.

Что делать: просите объяснить поведение кода, изменить его и проверить результат. Разрешённую работу с документацией не считайте автоматическим признаком слабой подготовки.

2. Давать разным кандидатам разную помощь

При неодинаковых подсказках баллы перестают быть сопоставимыми. Один человек получает направление решения, другой — только предложение подумать.

Что делать: подготовьте стандартные подсказки и фиксируйте, какая именно использовалась. Если задание случайно оказалось сложнее, не маскируйте это снижением оценки.

3. Смешивать hard skills и впечатление от общения

Уверенный рассказ не доказывает техническую самостоятельность. Точно так же паузы и сдержанность не доказывают отсутствие навыка.

Что делать: записывайте технические факты отдельно от коммуникации. При этом способность объяснить решение проверяйте напрямую: она нужна для ревью и совместной работы.

4. Выдавать бесплатную работу за тестовое задание

Задание на полноценную доработку вашего продукта проверяет не только компетенции, но и готовность человека тратить свободное время. Для небольшого бизнеса это ещё и неудобный способ сравнения: кандидаты работают в разных условиях.

Что делать: используйте ограниченный учебный фрагмент. Если нужна существенная проектная работа, отдельно согласуйте объём, оплату и использование результата.

5. Назначать проходной балл после интервью

Если порог появляется после знакомства с кандидатом, он легко подстраивается под личную симпатию.

Что делать: заранее определите критические навыки и допустимые пробелы. При изменении требований пересмотрите уже проведённые оценки или проведите дополнительную проверку — не меняйте правила только для одного человека.

Кто проведет техническое собеседование разработчика, если в штате нет тимлида?

Без профильного специалиста организуйте интервью вдвоём: один человек ведёт процесс, другой оценивает техническое решение. Для небольшой команды это может быть руководитель проекта и внешний разработчик нужного стека.

Вопрос «кто может провести техническое собеседование за меня» полезно разделить на две задачи:

• кто подготовит условия, договорится с кандидатом и соберёт заключение;
• кто сможет проверить код, отладку и технические компромиссы.

Эти задачи может выполнять один человек, если у него хватает компетенций. Но опыт подбора персонала не означает владения любым языком и любой архитектурой.

Экономный формат: привлекать технического оценщика не ко всем откликам, а после короткой проверки релевантного опыта и согласования условий работы. При этом не отсеивайте людей по случайным словам в резюме: сначала сопоставьте их задачи с вашей вакансией.

Если специалиста всё же некому подключить, используйте объективные проверки там, где это возможно: запуск решения, тестовые данные, ожидаемые результаты. Но признайте ограничение — прохождение проверок не доказывает качество архитектуры и сопровождения.

Подробнее об организации процесса — в статье «Как устроено техническое собеседование программиста без HR-агентства?».

Вопросы и ответы по теме

Единая шкала полезна, когда каждый балл связан с наблюдаемым действием и требованиями вакансии. Ниже — ответы на вопросы, которые возникают при первом запуске такой оценки.

Почему кандидаты не проходят техническое собеседование?

Причина может быть в недостатке нужных навыков, но также в несоответствии задания роли или неясных условиях. Отказ стоит связывать с конкретным критерием: например, кандидат не смог самостоятельно воспроизвести ошибку.

Если регулярно не проходят люди с релевантным опытом, проверьте сложность задания, время, понятность условий и ожидания по самостоятельности.

Как провести техническое собеседование программиста?

Возьмите небольшую рабочую задачу, определите критерии и проведите одинаковую процедуру для всех кандидатов на роль. После встречи запишите баллы вместе с фактами: что человек сделал самостоятельно и где понадобилась помощь.

Если вы не разбираетесь в нужном стеке, техническую часть поручите профильному разработчику. Общими вопросами об опыте её заменить нельзя.

Можно ли оценить hard skills без написания кода?

Можно проверить часть навыков через разбор кода, поиск ошибки, обсуждение запроса или плана тестирования. Но способность самостоятельно реализовать изменение останется непроверенной.

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

Нужно ли снижать балл, если кандидат пользуется документацией?

Нет, если документация разрешена правилами интервью. Оценивайте, понимает ли кандидат найденный пример, умеет ли адаптировать его и проверить результат.

Если нужна работа без справочных материалов, заранее объясните зачем. Иначе вы проверяете память в условиях, не похожих на будущую работу.

Как сравнить кандидатов, если один не успел закончить задачу?

Сравните выполненные действия, результат и причины остановки. Незавершённое решение может содержать полезные доказательства навыков, но не должно автоматически считаться корректным.

Не снижайте сразу все оценки: человек мог хорошо отлаживать и проверять, но не успеть завершить реализацию. Отдельно проверьте, была ли задача вообще выполнима за отведённое время.

Подойдёт ли одна шкала для начинающего и опытного разработчика?

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

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

подрядчик — это агентство или частный специалист?

поставщик услуг — частный специалист, а не кадровое агентство или студия разработки. Я занимаюсь управлением командами и подбором персонала, включая проведение собеседований с программистами.

Содержание технической проверки и необходимость участия профильного разработчика нужно согласовывать под конкретную вакансию.

Что делать, если интервьюеры поставили разные баллы?

Вернитесь к наблюдениям и описанию шкалы, а не усредняйте оценки автоматически. Расхождение часто показывает, что критерий сформулирован неясно или интервьюеры по-разному учли подсказку.

Если доказательств недостаточно, отметьте неопределённость и назначьте адресную проверку. Не превращайте спор о баллах в спор об общем впечатлении от человека.

---

Для старта достаточно одного проверенного задания, пяти критериев и шкалы 0–3. После первых интервью исправьте неоднозначные условия, но не меняйте требования задним числом. Главная экономия здесь — меньше случайных решений и повторных встреч, а не отказ от технической экспертизы.

Я, Улыбина Юлия Сергеевна, открыта к предложениям работодателей и проектной работе. Если вам нужна помощь с организацией собеседований, подготовьте описание вакансии, стек и примеры задач: по ним можно определить формат проверки и участие технического оценщика. Связаться со мной можно через профиль специалиста на Молвун. 🤝

---

Примечание. Приведённые цифры — средние по рынку на момент публикации; точные условия зависят от поставщика и объёма задачи. Подготовлено аналитической платформой Молвун. Актуальные тарифы проверяйте на официальных сайтах.