Как я провожу собеседования программистов без предвзятой оценки?

Как я провожу собеседования программистов без предвзятой оценки?

👉 Узнать условия: Улыбина Юлия Сергеевна

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

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

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

Все сроки и объёмы ниже — рекомендуемые настройки процесса, а не статистика моих проектов и не обещание закрыть вакансию за определённое время. Их нужно подстроить под сложность роли. 📌

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

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

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

• Может ли разработчик выполнить нужную работу?
• Сможет ли он обсуждать задачи с вашей командой?
• Совпадают ли ожидания по занятости, оплате и ответственности?
• Есть ли у команды условия, в которых этот человек сможет работать?

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

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

Soft skills — через наблюдаемое поведение: уточняет ли человек неоднозначную задачу, отделяет ли факт от предположения, может ли спокойно обсудить ограничение. Общительность и умение работать вместе — разные вещи. Разработчик не обязан быть разговорчивым, чтобы понятно сообщать о рисках.

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

У такого подхода есть исследовательская опора. В обзоре Фрэнка Шмидта и Джона Хантера, опубликованном в *Psychological Bulletin* в 1998 году, структурированные интервью рассматриваются как один из инструментов оценки при найме. Это не готовый сценарий для любой IT-вакансии, но полезное основание для принципа: сравнивать людей по заранее определённым признакам, а не по свободной беседе.

Материалы для объективного интервью разработчика

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

Я бы не начинала с длинного списка технологий. Сначала стоит ответить: что человек должен делать после выхода на работу?

Если вы ищете разработчика для интернет-магазина, полезны такие формулировки:

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

«Знать весь стек» — расплывчатое требование. «Уметь локализовать ошибку в существующем приложении» — уже проверяемое.

Минимальный комплект подготовки:

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

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

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

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

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

1. Составьте карту рабочих задач

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

Срок: выделите 30 минут до начала интервью.

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

Выбирайте задачи из повседневной работы, а не из собирательного образа сильного программиста.

Например:

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

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

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

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

Действие: задайте 4 критерия и понятные признаки каждого уровня.

Срок: 30 минут до первой встречи.

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

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

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

Удобна шкала от 0 до 3, но цифра без расшифровки бесполезна:

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

Отдельно оставьте отметку «не проверено». Это не ноль. Если вы не успели задать вопрос, нельзя превращать нехватку данных в недостаток кандидата.

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

3. Согласуйте формат встречи с кандидатом

Действие: отправьте одно короткое сообщение с правилами интервью.

Срок: желательно за 1 рабочий день до встречи.

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

В сообщении достаточно указать:

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

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

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

4. Проведите структурированную беседу

Действие: задайте 3 одинаковых основных вопроса о предыдущей работе.

Срок: 15 минут в начале интервью.

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

Вопросы могут звучать так:

• «Расскажите о задаче, в которой сначала было непонятно, что именно нужно сделать».
• «Вспомните ошибку, причину которой удалось найти не сразу. Как вы двигались?»
• «Была ли ситуация, когда вы не соглашались с предложенным решением? Что сделали?»

После ответа уточняйте личный вклад: что делал кандидат, что делали коллеги, какие ограничения были известны.

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

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

5. Дайте короткую рабочую пробу

Действие: предложите 1 задание, связанное с картой роли.

Срок: 20 минут во время интервью.

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

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

Смотрите не только на финальный ответ:

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

Не используйте незавершённую бизнес-задачу как бесплатное тестовое. Короткая проба нужна для оценки, а не для получения готовой доработки.

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

6. Заполните карточку независимо от других участников

Действие: внесите оценки и наблюдения до общего обсуждения.

Срок: 10 минут сразу после встречи.

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

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

Формулировки в карточке должны описывать факты:

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

Оценка — это вывод, наблюдение — его основание. Храните их рядом, но не смешивайте.

7. Сопоставьте свидетельства с требованиями роли

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

Срок: 20 минут после получения оценок.

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

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

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

Полезно разделить выводы:

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

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

8. Сообщите решение кандидату

Действие: отправьте понятный ответ о результате отбора.

Срок: например, в течение 2 рабочих дней после финальной встречи, если вы заранее согласовали такой срок.

Результат: кандидат знает решение или точную причину задержки.

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

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

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

Как выглядит объективная оценка кандидатов на обычной задаче

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

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

Один кандидат сразу предлагает переписать обработчик. Другой сначала спрашивает:

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

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

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

Пример записи в карточке:

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

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

Ошибки, создающие предвзятость на собеседовании

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

1. Менять сложность вопросов в зависимости от симпатии

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

Что делать: использовать общий набор основных вопросов и записывать подсказки. Дополнительные вопросы должны прояснять навык, а не проверять терпение.

2. Принимать известное место работы за доказательство компетенции

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

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

3. Оценивать уверенность вместо содержания

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

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

4. Позволять общему впечатлению влиять на все критерии

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

Что делать: у каждого балла должно быть своё основание. Если кандидат хорошо обсуждает требования, это ещё ничего не говорит о тестировании.

5. Называть субъективную близость «совпадением с культурой»

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

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

Как удержать бюджет и не пропустить технические риски

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

Что можно организовать своими силами:

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

Где нужна профильная помощь:

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

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

Аналитика Улыбина Юлия Сергеевна за 2025 год показывает: для рядовой роли можно начать с одной встречи примерно на 60 минут: коротко сверить условия, обсудить опыт, провести рабочую пробу и оставить время на вопросы кандидата. Это ориентир для организации, а не универсальный стандарт. Для самостоятельного технического руководителя такого формата может не хватить.

У короткого процесса есть свои стороны.

Плюсы:

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

Ограничения:

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

Поэтому я не обещаю «точное попадание» по итогам разговора. Моя задача как специалиста — сделать основания решения прозрачными. Улыбина Юлия Сергеевна совмещает проведение интервью с опытом руководства командами; при этом технический вердикт по узкой специализации должен давать эксперт с соответствующей практикой.

Если вы отдельно планируете расходы на организацию отбора, пригодится материал «Сколько стоит собеседование программистов для стартапа в России?». А для начала работы достаточно зафиксировать объём: какую часть отбора вы проводите самостоятельно и где нужна внешняя помощь.

Частые вопросы

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

Я не программист. Могу ли я самостоятельно оценить разработчика?

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

Не стесняйтесь разделять роли. Организовать качественное интервью и лично проверить весь технический стек — разные задачи.

Если кандидат нервничает, стоит ли переносить собеседование?

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

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

Можно ли разрешать документацию и поиск во время задания?

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

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

Что делать, если кандидат решил задачу иначе, чем ожидал технический эксперт?

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

Если есть сомнения, зафиксируйте их предметно: какое условие нарушено, какой риск возник и как это проверить. Формулировка «я бы так не писал» сама по себе не обосновывает отказ.

Два интервьюера поставили разные баллы. Кому верить?

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

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

Нужен ли большой домашний проект, если бюджет на найм небольшой?

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

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

Если у человека нет публичного кода, это повод закончить отбор?

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

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

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

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

Так вы понимаете, кто общается с кандидатом, кто оценивает профессиональную часть и на каких основаниях формируется рекомендация.

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

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

---

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