Одна из моих постоянных обязанностей, независимо от от места р | IT Монах

Одна из моих постоянных обязанностей, независимо от от места работы, это проведение технических собеседований с кандидатами на новые или освободившиеся вакансии в команде. И концентрация собеседований на единицу времени со временем увеличивается. Я думал, что деканство в Гикбрейнсе, где я проводил, в среднем, 3 собеседования в неделю в течение года — это предел и хуже уже не будет. Но сейчас на этапе формирования команды количество собеседований в неделю достигает 10.

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

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

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

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

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