Главные технические навыки, которые нужно проверить до выхода разработчика
В «Позитив Стафф» мы рекомендуем начинать проверку не с вопроса «насколько хорошо кандидат знает конкретный язык программирования», а с другой задачи: сможет ли он выполнять ту работу, для которой его нанимают.
Главные навыки, которые стоит проверить:
- владение языком программирования и основными технологиями — важно не то, помнит ли кандидат все конструкции языка наизусть, а способен ли он правильно применять их при решении рабочей задачи;
- умение решать рабочие задачи — способен ли самостоятельно разобраться в поставленной задаче и выбрать подходящее решение;
- работа с чужим кодом — может ли быстро понять уже существующий код и найти в нем проблему;
- поиск и исправление ошибок — умеет ли определить причину сбоя, а не просто угадывать исправление;
- работа с базами данных — понимает ли структуру данных и умеет ли составлять корректные запросы;
- тестирование — проверяет ли кандидат результат и учитывает ли нестандартные ситуации;
- архитектурное мышление — особенно важно для специалистов среднего и высокого уровня;
- умение объяснять свои решения — разработчик должен понимать, почему он написал код именно так.
При этом проверять все перечисленное одинаково для каждого соискателя не нужно. Для начинающего специалиста важнее увидеть базовые знания и способность учиться, а от опытного программиста работодатель вправе ожидать самостоятельного решения сложных задач и понимания последствий технических решений.
Как составить технический профиль вакансии до начала проверки
Прежде чем давать тестовое или приглашать на техническое собеседование, стоит определить, какие именно навыки необходимы для конкретной должности.
Мы рекомендуем составлять такой профиль еще до начала поиска. Это помогает избежать ситуации, когда требования меняются уже во время собеседований.
| Что определить | Что нужно прописать | Зачем это нужно |
|---|---|---|
| Основные технологии | Языки программирования, библиотеки, базы данных и другие необходимые инструменты | Чтобы не проверять навыки, которые не потребуются сотруднику |
| Рабочие задачи | Какие задачи специалист будет выполнять в первые месяцы | Позволяет связать проверку с реальной работой |
| Обязательные навыки | Что кандидат должен уметь уже на момент выхода | Помогает отделить необходимые требования от дополнительных |
| Уровень самостоятельности | Какие задачи кандидат должен решать без постоянной помощи коллег | Особенно важно при найме специалистов среднего и высокого уровня |
| Критерии оценки | Что считать правильным решением и какие ошибки критичны | Позволяет оценивать кандидатов по единым правилам |
Например, если компании нужен ИТ-специалист для поддержки уже работающего интернет-магазина, нет смысла проверять его только на способность написать программу с нуля. Гораздо полезнее дать задачу, связанную с исправлением ошибки, изменением существующего кода или добавлением нового функционала.
Так проверяются не абстрактные знания, а то, с чем специалист действительно столкнется после выхода.
Тестовое задание: когда оно действительно показывает уровень разработчика
Оно может дать гораздо больше информации, чем десятки теоретических вопросов. Но только при одном условии: оно должно быть связано с будущей работой.
Плохой вариант, дать объемную задачу на несколько дней, которая практически не связана с должностными обязанностями. Такой подход может отпугнуть сильных специалистов и при этом не гарантирует объективной оценки.
Хорошее задание должно позволять проверить несколько вещей одновременно:
- понял ли кандидат условие;
- умеет ли разбить большую задачу на части;
- насколько логично строит решение;
- пишет ли понятный код;
- учитывает ли возможные ошибки;
- проверяет ли полученный результат;
- может ли объяснить, почему выбрал именно такой подход.
Для разных уровней сложность должна отличаться. Начинающему специалисту можно предложить небольшую задачу на базовые знания. Для опытного разработчика полезнее дать ситуацию, максимально похожую на ту, с которой он столкнется в компании.
Еще один важный момент: объем. Если для выполнения задания требуется несколько часов, это уже должно быть обосновано. Когда человек тратит целый рабочий день на бесплатную разработку полноценного решения, тест перестает быть просто способом оценки.
В «Позитив Стафф» мы рекомендуем заранее определить: что именно проверяет задание, сколько времени оно должно занимать и по каким критериям будет оцениваться результат. Тогда тестовое становится частью системы найма, а не формальностью.
Как провести практическую проверку технических навыков
Практическая задача в режиме реального времени
Один из способов - предложить небольшую задачу непосредственно во время технического собеседования. Здесь важно оценивать не только конечный результат. Работодатель может увидеть, как специалист думает, какие вопросы задает, как ищет решение и что делает после обнаружения ошибки.
Например, кандидату можно дать небольшой фрагмент программы и попросить добавить определенную функцию. Если он сталкивается с проблемой, интервьюер наблюдает, пытается ли кандидат разобраться самостоятельно или сразу начинает угадывать ответ.
При этом не стоит превращать встречу в экзамен на скорость. В реальной работе программисту важнее найти надежное решение, чем написать несколько строк кода быстрее другого человека.
Проверка умения находить и исправлять ошибки
Для многих должностей полезнее не заставлять писать программу с нуля, а предложить ему уже готовый код с ошибкой. Задача может выглядеть так: программа запускается, но в определенной ситуации выдает неправильный результат. Кандидату нужно найти причину, исправить ее и объяснить свои действия.
Здесь можно оценить сразу несколько навыков:
- умеет ли специалист воспроизвести проблему;
- понимает ли, где искать ее причину;
- формулирует ли предположения;
- проверяет ли их;
- исправляет ли ошибку без создания новых проблем;
- проверяет ли результат после исправления.
Такой формат особенно полезен при найме программистов, которым предстоит поддерживать уже существующие продукты.
Как проверить способность читать чужой код
Работа разработчика это не только написание нового кода. Во многих проектах значительная часть времени уходит на изучение того, что уже создано другими специалистами. Поэтому можно показать небольшой фрагмент существующего кода и попросить простыми словами объяснить:
- что он делает;
- какие части кажутся проблемными;
- где может возникнуть ошибка;
- что можно улучшить;
- какие проверки или тесты стоит добавить.
Особенно показательно, если кандидат не просто говорит «здесь код написан плохо», а объясняет конкретную проблему и предлагает обоснованный вариант исправления.
Как проверить алгоритмическое мышление без сложных задач «ради задач»
Сложные задачи сами по себе не делают проверку качественной. Иногда можно дать головоломку, которую специалист никогда не встретит в своей работе, а затем использует результат как основной показатель профессионального уровня. Мы считаем более полезным другой подход: выбирать задачи, похожие на реальные рабочие ситуации.
Например, если предстоит обрабатывать большое количество данных, можно проверить, понимает ли он, как организовать такую обработку и какие ограничения необходимо учитывать.
Главное, увидеть ход рассуждений. Кандидат может не сразу назвать идеальное решение, но при этом правильно анализировать условия, задавать уточняющие вопросы и постепенно находить подходящий вариант.
Как проверить прикладные навыки: базы данных, программный интерфейс и тестирование
Если разработчик будет регулярно работать с базами данных, можно дать ему небольшой набор данных и попросить составить несколько запросов. Если предстоит работа с программными интерфейсами, предложить разобрать пример запроса и ответа, обработку ошибки или способ взаимодействия между системами.
При необходимости отдельно проверяются:
- умение работать с системой контроля версий;
- понимание структуры проекта;
- написание и проверка тестов;
- работа с базами данных;
- поиск причин ошибок;
- оценка производительности.
При этом не обязательно проверять каждый пункт отдельным испытанием. Одно грамотно составленное практическое задание может показать сразу несколько технических навыков.
Как проверять разработчика, который активно использует ИИ
Сегодня проверка меняется вместе с инструментами. Кандидат может обратиться к ИИ за подсказкой, попросить его найти ошибку или предложить несколько вариантов решения. Сам по себе факт использования таких инструментов не говорит о профессиональном уровне специалиста.
Для работодателя важнее другое: понимает ли ИТ-специалист полученный результат и способен ли проверить его самостоятельно.
В «Позитив Стафф» рекомендуем не запрещать ИИ автоматически, а заранее определить правила его использования. Это позволяет проверить навык, который действительно нужен: способность получать помощь от инструмента, но не передавать ему ответственность за результат.
Практический пример № 1: разрешить ИИ написать решение
Кандидату можно дать небольшую задачу и сказать, что он вправе использовать ИИ. После получения готового кода попросить: объяснить назначение каждой ключевой части; назвать возможные ошибки; предложить способ проверки; изменить одно из условий задачи и объяснить, что произойдет после изменения.
Если кандидат самостоятельно разбирается в результате, использование ИИ становится рабочим инструментом. Если же он не может объяснить собственный код и не замечает очевидных проблем, работодатель получает важный сигнал для дополнительной проверки.
Практический пример № 2: дать код с ошибкой ИИ
Еще интереснее предложить фрагмент программы, который выглядит рабочим, но содержит ошибку. Задача специалиста не написать новый код, а определить, почему решение не работает, найти проблему и исправить ее.
Так можно проверить сразу два навыка: технические знания и способность критически оценивать результат, созданный с помощью ИИ.
Практический пример № 3: сравнить два решения
Кандидату можно показать два варианта выполнения одной задачи и попросить выбрать подходящий. Важно спросить не только «какой вариант лучше?», но и: почему; какие у каждого решения ограничения; как они повлияют на скорость программы; насколько легко код будет изменять в будущем и какие дополнительные проверки нужны.
Такой формат показывает глубину понимания лучше, чем простой вопрос о знакомстве с определенной технологией.
Практический пример № 4: попросить улучшить результат ИИ
Можно предложить исходный запрос к ИИ и полученный ответ, а затем попросить найти в нем недостатки. Например:
«ИИ предложил такое решение. Представьте, что этот код завтра попадет в рабочий проект. Что вы проверите перед его использованием?»
Сильный кандидат, скорее всего, начнет искать потенциальные ошибки, уязвимости, проблемы с производительностью и крайние случаи, а не просто согласится с готовым ответом. Главный принцип: проверять нужно не способность обходиться без ИИ, а способность отвечать за технический результат независимо от того, кто помог написать первоначальный вариант.
Как отличить реальный навык от заученных ответов
Один из распространенных рисков технического собеседования: кандидат знает правильные формулировки, но не умеет применять их в работе.
Например, специалист уверенно объясняет, что такое определенный принцип программирования, рассказывает о преимуществах конкретного подхода, перечисляет известные инструменты. Но когда условие задачи немного меняется, готовый ответ больше не подходит. Поэтому рекомендуем использовать уточняющие вопросы и изменение условий.
Прием 1. Попросить объяснить простыми словами. Если кандидат использует сложную терминологию, попросите объяснить решение так, будто он рассказывает его начинающему разработчику. Настоящее понимание обычно позволяет перейти от определения к понятному объяснению.
Прием 2. Изменить условие
Допустим, кандидат предложил решение задачи. После этого интервьюер добавляет новое ограничение: «А что изменится, если количество пользователей увеличится в десять раз?» или: «Что произойдет, если база данных будет временно недоступна?» Так проверяется способность применять знания, а не воспроизводить заранее подготовленный ответ.
Прием 3. Спросить о недостатках собственного решения
Полезный вопрос: «Какое слабое место вы видите в своем варианте?» ИТ-специалист, который действительно понимает решение, способен назвать его ограничения и объяснить, в каких условиях выбрал бы другой подход.
Прием 4. Дать чужое решение
Можно убрать фактор заранее подготовленного ответа и показать код другого специалиста. Попросите найти: ошибки; потенциальные проблемы; неоптимальные решения и места, которые требуют дополнительной проверки.
Прием 5. Попросить восстановить ход решения
Не всегда важно, насколько быстро кандидат написал код. Гораздо показательнее попросить его рассказать:
- с чего он начал;
- какие варианты рассматривал;
- почему отказался от других решений;
- что проверял;
- как убедился, что задача действительно решена.
Заученный ответ чаще всего хорошо работает только в неизменных условиях. Реальный навык проявляется, когда задачу приходится анализировать, менять и объяснять.
Какой формат проверки выбрать для junior, middle и senior
Уровень напрямую влияет на то, что именно нужно проверять. Одинаковое задание для начинающего специалиста и опытного разработчика не позволит получить объективную картину.
| Уровень | Что проверить в первую очередь | Подходящий формат | На что обратить внимание |
|---|---|---|---|
| Junior | Базовые знания языка, логика, понимание основных принципов программирования | Небольшая практическая задача + обсуждение решения | Понимает ли кандидат собственный код и способен ли исправлять простые ошибки |
| Middle | Самостоятельное решение рабочих задач, работа с существующим кодом, базы данных, тестирование | Практическое задание + поиск ошибки + разбор решения | Насколько самостоятельно кандидат принимает технические решения |
| Senior | Архитектура, производительность, надежность, технические риски и обоснование решений | Сложный практический кейс + обсуждение архитектуры | Видит ли кандидат последствия своих решений и умеет ли объяснять компромиссы |
При этом название уровня само по себе не должно становиться основанием для оценки. Если компания использует собственную систему грейдов, требования лучше привязывать прежде всего к конкретным задачам должности и степени самостоятельности специалиста.
7 ошибок работодателя при технической проверке разработчика
- Проверять все технологии подряд. Работодатель может составить огромный список технологий и пытаться проверить каждую из них. В результате собеседование превращается в экзамен, но не показывает, сможет ли человек выполнять реальные задачи. Правильнее: сначала определить ключевые рабочие задачи, а затем подобрать под них способы проверки.
- Давать слишком объемное тестовое задание. Это не всегда означает более точную оценку. Оно увеличивает время и может затянуть процесс найма. Правильнее: проверять несколько важных компетенций одним компактным методом.
- Оценивать только конечный результат. Два кандидата могут получить одинаковый результат совершенно разными способами. Правильнее: оценивать не только код, но и ход рассуждений, поиск ошибок, проверку результата и способность объяснить решение.
- Делать ставку только на теоретические вопросы. Кандидат может прекрасно знать определения и при этом испытывать трудности с реальной задачей. Правильнее: сочетать короткий теоретический блок с практической проверкой.
- Не учитывать уровень должности. Задавать senior-разработчику только вопросы о синтаксисе языка так же малоэффективно, как требовать от junior самостоятельной разработки сложной архитектуры. Правильнее: менять глубину проверки в зависимости от будущих обязанностей.
- Запрещать современные инструменты без необходимости. Полный запрет ИИ может создать искусственные условия, не похожие на рабочий процесс компании. Правильнее: заранее определить, какие инструменты разрешены, и проверить способность контролировать их результат.
- Не фиксировать результаты проверки. Если технический специалист после собеседования говорит «кандидат вроде сильный», рекрутеру сложно понять, на чем основано решение. Правильнее: использовать единую форму оценки с конкретными критериями и комментариями.
Топ вопросов о найме разработчика
1. Как проверить разработчика, если рекрутер сам не разбирается в программировании?
Рекрутеру не обязательно самостоятельно оценивать качество кода. Его задача организовать процесс и зафиксировать результаты. Техническую часть можно проводить совместно с руководителем разработки или привлеченным техническим специалистом. При этом рекрутер должен заранее понимать, какие компетенции проверяются и по каким критериям.
2. Нужно ли разрешать кандидату пользоваться ЧатГПТ во время технического задания?
Это зависит от условий. Если сотрудники компании используют ИИ, логично проверять способность работать с ним ответственно. Можно разрешить использование инструмента, но дополнительно попросить объяснить решение, проверить полученный код и исправить специально добавленную ошибку.
3. Как понять, что кандидат действительно написал код самостоятельно?
Полной гарантии один формат проверки не дает. Поэтому полезно сочетать несколько способов: практическую задачу, обсуждение решения, изменение условий и разбор ошибок. Если человек понимает код, он обычно способен объяснить, почему выбрал конкретный подход и что изменится при новых вводных.
4. Какие навыки обязательно проверять у senior-разработчика перед оффером?
В первую очередь те, которые связаны с его будущей зоной ответственности: самостоятельное решение сложных задач, архитектурное мышление, оценка технических рисков, работа с существующей системой, производительность, надежность и способность обосновывать решения.
5. Что делать, если кандидат не выполнил тестовое задание полностью, но хорошо объясняет ход решения?
Не стоит автоматически считать такого кандидата неподходящим. Нужно разобраться, почему задача осталась незавершенной. Если специалист правильно понял условие, выбрал подходящий способ решения, обнаружил проблему и может объяснить дальнейшие шаги, результат стоит рассматривать вместе с остальными данными проверки.
__
Техническая проверка нужна не для того, чтобы устроить сложный экзамен. Ее задача заранее понять, как специалист будет справляться с реальными рабочими ситуациями после выхода в компанию.
В «Позитив Стафф» мы рекомендуем строить проверку вокруг будущих обязанностей. Отдельное внимание сегодня стоит уделять работе с ИИ: важно не запрещать инструмент формально, а убедиться, что разработчик способен контролировать его результат и отвечает за конечное решение.
Такой подход помогает сделать подбор разработчика более предметным и снизить риск ситуации, когда кандидат хорошо проходит собеседование, но уже после выхода не справляется с задачами, ради которых его наняли.
Заимствования и названия в тексте
SQL — Structured Query Language — язык структурированных запросов. Используется для работы с базами данных: поиска, добавления, изменения и удаления информации.
API — Application Programming Interface — программный интерфейс приложения. Это набор правил, по которым разные программы и сервисы взаимодействуют друг с другом.
Git (гит) — система контроля версий.
Debugging — отладка. Процесс поиска, определения причины и исправления ошибок в программе.
Junior — начинающий специалист. В разработке так обычно называют специалиста с небольшим профессиональным опытом, которому для решения части задач может требоваться помощь более опытных коллег.
Middle — специалист среднего уровня. Разработчик, который способен самостоятельно решать большинство задач в своей профессиональной области и работать с существующим кодом без постоянного контроля.
Senior — опытный специалист высокого уровня. Такой разработчик не только решает сложные технические задачи, но и способен принимать самостоятельные решения, оценивать риски, выбирать подход к построению системы и объяснять свои решения команде.
