Всем привет! Меня зовут Виталий, я ведущий фронтенд-разработчик в KTS.
Полтора года назад я начал участвовать в найме новых сотрудников: проводил собеседования и оценивал навыки кандидатов.
В статье поделюсь выводами за это время. Расскажу, как сделать результат собеседования объективным, а процесс — более комфортным для кандидата и интервьюера.
Что будет в статье
Для кого этот материал
Статья написана для тех, кто хочет — или должен — научиться проводить собеседования, но пока имеет только опыт их прохождения.
Материал будет полезен, если вы только начали участвовать в процессе найма — как я полтора года назад. Надеюсь, мой опыт поможет вам чувствовать себя более уверенно. Возможно, кому-то наблюдения и рекомендации покажутся очевидными, но я уверен, что многие найдут здесь что-то полезное.
Это не технический материал. Я рассказываю, как провести собеседование чтобы:
Качественно и объективно проверить навыки кандидата.
Сделать общение для обеих сторон комфортным.
Оставить у собеседника хорошее впечатление о компании и вас лично. Важно, чтобы хорошее впечатление сложилось не только у сильных кандидатов, а вообще у всех. Даже после отказа человек может рассказать о компании другим людям, либо попытаться пройти собеседование ещё раз.
Показать собеседнику профессионализм вашей команды и транслировать ценности компании.
Потратить своё время с пользой.
Как начать?
Наблюдение
На мой взгляд, самый простой и эффективный способ начать — попросить подключаться к собеседованиям в вашу компанию в роли наблюдателя. Так вы увидите как выстраивают диалог более опытные коллеги и многому научитесь:
Во-первых, вы познакомитесь с общим сценарием собеседований: как формулируются задачи и в каком порядке их задают
-
Увидите разных кандидатов. Все люди уникальны и на заданный вопрос реагируют по-разному:
человек может просто приступить к решению
он может решать задачу молча или активно комментируя
может начать отвечать вообще на другой вопрос
может сказать что-то вроде: «Я не буду этого делать» или «Я не знаю» и замолчать.
Это несколько совершенно стандартных ситуаций. Наблюдая, вы заранее поймете, как себя вести в таких случаях на примерах коллег
Поймете, как лучше управлять временем собеседования: не дать процессу затянуться и в то же время дать достаточно задач для объективной оценки кандидата
Услышите, какие вопросы может задать кандидат, и как стоит на них отвечать
Сначала вы понаблюдаете за тем, как кандидаты показывают себя, а затем узна́ете, какие оценки поставил интервьюер. Так вы сможете ощутить общую температуру рынка и точнее понять уровень требований к кандидатам на разных грейдах в вашей компании.
Если собеседования в вашей компании записываются, посмотрите записи. Но обязательно смотрите не только хорошие, но и неудачные примеры. Иначе есть опасность совершить «ошибку выжившего»: вы соберете информацию про успешных кандидатов, но упустите примеры проколов.
Внешний опыт
Богатый и разнообразный опыт полезен в любом деле. Поэтому не бойтесь проходить собеседования в другие компании и учиться у других интервьюеров.
У такой тренировки есть дополнительный важный плюс: вы оцените собственные навыки и своё место на рынке труда. Хотя это уже совсем другая история…
Переход от наблюдения к участию
В какой-то момент вы можете начать принимать активную роль в собеседовании.
Сначала возьмите на себя отдельные небольшие части. Обязательно просите обратную связь у опытного интервьюера, с которым проводите первые собеседования.
Накопив опыт в частичном интервью, переходите на полное. Всё, что написано ниже, должно помочь делать это эффективно.
Технические аспекты
Ниже — мой вариант идеальной комбинации технического оснащения АРМ:
Два монитора. На первом — комната звонка в сплит-скрине со списком заданий. На втором — codeinterview или другой сервис, в котором вы планируете проводить live coding.
Тихое место с хорошим интернетом. Заранее позаботьтесь об этом.
Розетка рядом.
Ноутбук должен стоять на зарядке.
Наушники. Во-первых, так вы не отвлекаете окружающих, во-вторых, уведомления и другие звуки не будут смущать собеседника.
-
Веб-камера. Включите сами и попросите собеседника о том же. Если есть проблемы с сетью, во время секции с кодом можно её отключить, но я рекомендую быть с камерой как можно дольше.
Ещё одна причина, по которой стоит просить собеседника включить камеру: иногда в процессе интервью кандидат начинает гуглить. Мне было печально столкнуться с таким поведением, и сразу после этого я стал учитывать этот сценарий :)
Подготовка. Для интервьюера собеседование начинается за 10 минут до назначенного времени. Мне этого хватает, чтобы всё подготовить.
Запись. На мой взгляд, это лишнее. Но если решили вести запись, обязательно обговорите этот момент с кандидатом.
Бонусный пункт — фиксирование собеседования. Мне сильно помогает. Звучит глупо, но это реально работает: если собеседование не записывается, с разрешения кандидата сделайте скриншот экрана с вашим и его лицом. Скорее всего, в резюме кандидата есть его фотография, но снимок в процессе живого общения помогает вспомнить, с кем вы общались неделю или месяц назад. Всё-таки очень важно сопоставлять резюме и результаты интервью с воспоминанием о реальном человеке.
Структура интервью
Главное, что нужно помнить при проведении собеседования — кандидат тоже человек, скорее всего, он волнуется.
Разделяйте секции заданий
Все кандидаты решают задачи с разной скоростью.
Если вести всех по общему сценарию и требовать решения всех задач, многие интервью сильно растянутся во времени. Поэтому нужно менять ход собеседования в зависимости от прогресса и скорости кандидата.
Задачи во время интервью обычно задают по секциям. На фронте я чаще всего спрашиваю сначала по JS, а затем по React. На каждую секцию советую установить формальные временные рамки: если понимаете, что кандидат не тянет, дойдите с ним до логической точки в задаче и переходите к следующей секции.
Лучше спросить немного по JS и перейти к React, чем потратить всё время собеседования на задачи одной секции. Часто кандидат силен в чём-то одном и имеет недостатки в другом, поэтому стоит дать человеку шанс проявить себя в разных направлениях.
Подготовьте один сценарий для всех
Я считаю, что собеседование будет объективным, если все интервью на одну позицию проходят по общему сценарию. Не важно, ведёте интервью вы или кто-то ещё.
Сформируйте матрицу требований к кандидатам на разных грейдах. В зависимости от них составьте списки требований-секций для каждой позиции.
Каждая секция должна состоять из нескольких групп заданий, примерно равных по сложности и важности.
Разделите секции по уровню важности и задайте временные рамки
Отсортируйте группы внутри секции по уровню важности от самой важной в начале до наименее важной в конце. В процессе интервью задавайте по одной случайной задаче из каждой группы. Если все собеседования проходят по одной схеме, вы будете уверены, что коллега проводит интервью равным образом, и его оценка навыков кандидата основана на той же системе. К тому же так вам не надоест спрашивать каждый раз одно и то же.
Каждая секция ограничена по времени. Если задания отсортированы по важности, вы сразу узнаете всё необходимое. В случае нехватки времени на все задания вы всё равно сможете объективно оценить кандидата.
Зафиксируйте формулировки задач. Это нужно, чтобы все собеседующие давали одинаковые входные данные и не пропустили важные детали. Оценка навыков кандидатов будет более объективной, если спрашивать всех одинаково.
Сдвигайте временные ограничения в зависимости от кандидата
Моё обычное собеседование состоит из секций JS и React. Суммарно оно длится не больше двух часов, а сколько конкретно, зависит от силы кандидата.
Если я понимаю, что кандидат слабый, трачу максимум 30 минут на задачи по JS и перехожу к React. По React сначала спрашиваю теорию. Если кандидат отвечает хорошо — после теории даю практическое задание. Если отвечает слабовато, ничего не даю и заканчиваю интервью.
Таким образом, со слабым кандидатом собеседование занимает не больше часа. И наоборот — если кандидат сильный, на каждую секцию можно выделить побольше времени.
Не советую заканчивать интервью быстрее, чем за час:
Нужно дать человеку шанс и время показать себя
Кандидат составляет своё впечатление о вас и затем распространяет его. Если вы завершите интервью слишком быстро, это может показаться грубым, что плохо скажется на репутации компании и вашей лично
Переходя между задачами и секциями, не давайте оценку их сложности: «Сейчас будет простенькая задача» или: «Начнём с простого». Если кандидат не справится с «простой» задачей, это может усилить его волнение.
Вместо этого говорите безоценочно: «Давай начнем с JS. Первая задача — …».
Как заканчивать секции и задания
Вы понимаете, что отведённое время на секцию заканчивается, и пора идти к следующим задачам.
Но говорить об этом не надо. Напомню, что кандидат волнуется, и такое поведение только усилит его стресс. Все временные ограничения условны.
Обязательно дайте кандидату закончить мысль, предложение. Не прерывайте, даже если понимаете, что мысль неверна. Затем, если требуется, покажите кандидату решение, которое вы ожидали, и переходите дальше.
Зачем рассказывать решение
Так вы покажете позитивное и дружественное отношение к кандидату, снимете стресс и расположите человека. Конечно, само объяснение должно быть позитивным и дружелюбным.
Т.к. я работаю в KTS, люди воспринимают меня как представителя ценностей компании. А одна из наших ценностей — развитое наставничество. На мой взгляд, небольшой разбор задач хорошо ей соответствует.
Когда можно подсказывать
Подсказывать можно, если вы видите, что кандидат сильно застрял на задаче и не решит её без подсказки.
Но не нужно рассказывать решение целиком. Давайте небольшие, подталкивающие подсказки. Только запоминайте, какие именно подсказки вы дали: каждая подсказка снижает долю самостоятельного решения кандидата, это очень важно учитывать при подведении итогов.
Я для себя выработал небольшой список точек останова, на которых даю подсказки по конкретным задачам, если человек с ними не справляется. Наверное, это индивидуально для каждого собеседующего и познается на практике, но в целом проследите за собой и постарайтесь осмыслить, в какой момент вы даёте подсказку и зачем.
Собеседование как диалог
Важный вопрос
Программирование — деятельность творческая, поэтому собеседование должно показать не только технические навыки, но и стремления, ценности и интересы кандидата. Вам нужно понять: по пути ли вам с этим человеком, станет ли он полноценной частью команды. Если видно, что сотрудничество априори не будет эффективным, не стоит тратить время.
На эти вопросы поможет ответить секция HR. Подробно рассказывать про неё не буду, но остановлюсь на одном из вопросов, который всегда задаю кандидатам в начале. Возможно, вы тоже отвечали на него: «Что самое интересное и самое сложное вы делали в этой области?»
Ответ демонстрирует ценности и профессиональную зрелость кандидата. Вы поймёте, на чем он делает основной упор: на техническом мастерстве или бизнес-ценности. Возможно, вы узнаете об интересах собеседника и его отношении к продукту.
Учитесь у кандидата
Если я вижу в резюме кандидата что-то незнакомое или интересное, я часто прошу рассказать об этом подробнее. Мне кажется, никогда не стоит упускать возможность учиться, а регулярные собеседования означают регулярное общение с профессионалами. Это приносит обоюдную пользу.
Ваша заинтересованность располагает к вам кандидата. Это демонстрирует, что вы видите в человеке не очередного ноунейма из откликов, а равноправного участника диалога. А вы можете узнать что-то новое.
Интересуйтесь мнением
Чтобы продемонстрировать, что я имею ввиду, расскажу о недавнем случае.
Пару недель назад я проводил собеседование с кандидатом, который в резюме указал обучение на одной известной образовательной платформе.
Тема образования и обучения мне очень близка, т.к. в KTS мы развиваем собственную школу Metaclass. Я с большим интересом послушал мнение человека, обучающегося на другой платформе: как устроены процессы, как решают проблемы, которые есть и у нас, насколько ему было интересно, сложно и полезно.
Ну и конечно, было интересно посмотреть, как обучение на этой платформе повлияло на качество решения задач.
Получайте удовольствие
Выше я показал, что вы можете получить пользу от общения с кандидатами.
Постарайтесь вести интервью как диалог потенциально равных профессионалов и просто двух хороших людей. Так вы оба проведёте время с пользой и останетесь после интервью в хорошем настроении.
Корректное завершение интервью
Как понять, что хватит заданий, я уже рассказал в разделе «Сдвигайте временные ограничения в зависимости от кандидата». Теперь расскажу, как я заканчиваю интервью.
После очередного задания говорю что-то вроде: «Это всё, что я хотел спросить. Теперь я готов ответить на твои вопросы».
Здесь помогает то, что вы не давали задачам оценки сложности. Вы можете оставить не лучшее впечатление и демотивировать кандидата, если сначала скажете: «Начнём с простого», а затем: «Это всё, что я хотел спросить». Не расставляя себе такой ловушки, вы получаете манёвр и можете завершить общение практически в любой момент. Но напомню, что в большинстве случаев нужно дать кандидату хотя бы час.
Обязательно попросите кандидата задать вопросы. Если вопросов нет, насторожитесь: хороший специалист обязательно уточнит какие-то детали, или хотя бы расскажет, что понял для себя из интервью.
Обратная связь с обеих сторон
Если в конце собеседования кандидат попросит обратную связь, обязательно поделитесь ей.
Но будьте аккуратны в формулировках. Не говорите: «Ты показал себя плохо», или: «Мне не понравилось». Я считаю, что самый корректный вариант — рассказать, в каких направлениях у кандидата есть пробелы и что ему стоит подтянуть. Если вы точно понимаете, что уровень кандидата не соответствует ожиданиям, можно сказать, какому грейду соответствуют его навыки по вашей матрице компетенций. Обратите внимание, что эта оценка должна быть объективной и не обижать человека.
Но чаще всего я завершаю собеседование фразой, что мы вернёмся с обратной связью в ближайшие дни.
Обязательно спросите сами, какие впечатления остались после собеседования у кандидата и сделайте выводы. Всё-таки ваша задача в том, чтобы сделать процесс интервью полезным и приятным для кандидата.
Иногда я спрашиваю, куда ещё собеседовался кандидат и какие вопросы задавали там. Это бывает полезно, и чаще всего я остаюсь довольным списком заданий нашей команды. Простите за минутку хвастовства :)
Как записать результаты
Результаты собеседования должны быть объективными.
Сначала перечислите список заданий, которые вы давали кандидату. Для каждого задания напишите, как справился претендент: много ли было подсказок и каких именно.
Потом напишите, как вы оцениваете грейд кандидата, независимо от его собственной оценки.
И уже в конце добавьте свою субъективную оценку и поделитесь общими наблюдениями или впечатлениями о собеседнике.
О чём рассказать кандидату
Это довольно редкий случай.
Если я понимаю, что кандидату нужно подрасти, чтобы претендовать на ожидаемую позицию, и диалог располагает к такому формату общения, я обязательно поделюсь, как именно он может подтянуть навыки.
Например, рассказываю о нашей школе и курсах, делюсь ссылками на записи наших лекций по конкретным темам.
Ну и конечно, не забываю поделиться ссылкой на блог KTS на Хабре. Каждая статья в нём — результат огромного труда нашей команды и может действительно прокачать человека в каком-то аспекте.
Чек-лист по структуре интервью
В заключение для вашего удобства составил небольшой чек-лист:
объедините взаимозаменяемые задания в группы;
разбейте группы заданий на секции по темам;
отсортируйте группы заданий в секции по убыванию важности;
подготовьте один сценарий и формулировки заданий;
подстраивайте временные ограничения в зависимости от силы кандидата;
не озвучивайте собственную оценку задачам;
не обрывайте кандидата при переходе от задачи к задаче;
запоминайте, какие подсказки вы дали;
делитесь решением, если это нужно.
Что думаете вы?
Для меня очевидно, что в направлении собеседований мне ещё есть куда расти. Поэтому мне было бы очень интересно прочитать мнение читателей о моих рассуждениях.
Также прошу поделиться собственным опытом проведения интервью с кандидатами. Наверняка есть моменты, которые я упустил, и буду благодарен за восполнение пробелов.
А ещё расскажите, какие ценности в проведении собеседований — помимо очевидного набора сотрудников — видите вы?
Комментарии (30)
TakashiNord
17.10.2021 18:28+3Очередной глупый мессендж про собеседование.
Вы когда нибудь читали про собеседования - врачей - хирургов? трактористов-машинистов? сварщиков? или машинистов-поездов?
коллега, вот вам тело с одной стороны-вот с другой, вырежьте этому пациенту гланды, а другому аппендикс
неважно, что у тебя 5 разряд - вот тебе задание, как открыть бутылку отвалом - сразу возьму
.... значит , разгоняемся до 120и, и уходим в депо. Увидишь алкаша-тормози. Но учти, у нас там 6 тыс тонн.
rustambmt
17.10.2021 22:58Согласен на 100%
От себя могу добавить что бывает так, человек прошедший великолепно собеседование на практике не может/умеет и ТД работать. И наоборот, чел не прошедший собеседование но имеющий сильное желание работать ...ну и ТД.
VitalyCherkov Автор
18.10.2021 00:10Согласен. Поэтому, думаю, очень важен предшествующий опыт кандидата.
Но все же собеседование позволяет оценить текущий уровень человека, чтобы понять, подходит ли он компании, оценить его soft skills. Ну и конечно, собеседуемый тоже решает, готов ли он сотрудничать с этой компанией.
hippoage
18.10.2021 09:02+3Есть знакомый сварщик -- при найме они делают тестовое задание по сварке, а для того, чтобы приступить к работе еще и теорию сдают по каким-то нормам.
Про машинистов и хирургов не знаю, но лучше бы делали какие-то тестовые задания, чем просто наличие обучения/опыта, но все зависит от кол-ва кандидатов: когда их меньше, чем вакансий, то часто берут всех подряд.
TakashiNord
20.10.2021 07:19еще со времен СССР - это называется аттестацией. Если человек работает на предприятии - то раз 3-4-5 года, собирается комиссия, в составе: глав инженер или нач предприятия, глав по специальности, мастер (уважаемый), главные по труду, пожарники, . Группа товарищей сдает охрану труда, безопасность, экз по спец, если нужно варит. И эти члены комиссии - если человек заслужил - повышают ему квалификацию (разряд). Нет, то ждать еще 3-4 года. Вне предприятия, эти функции выполняет Роспотребнадзор.
Driver86
18.10.2021 01:10+3Да уж. А начиналось всё очень скромно.
Сейчас мало уметь программирование, важно иметь подвешенный язык.
VitalyCherkov Автор
18.10.2021 10:42Дело не в подвешанном языке) Конечная цель труда программиста — это не написанный код, а решенная проблема. Это командная работа, поэтому очень важно убедиться, что сотрудник сможет с этой командой эффективно взаимодействовать: человек должен уметь доносить свои мысли и принимать чужие. Ну и конечно, нужно понять, подходят ли соискатель и команда друг другу по духу — людям просто должно быть комфортно вместе. При этом, конечно, никто не требует от кандидата “покорить” HR своими рассказами, чаще всего на этом этапе непосредственно из общения проверяется, насколько вообще человек адекватен, и по моему опыту, большинство кандидатов с ним успешно справляется.
mvv-rus
18.10.2021 21:40Конечная цель труда программиста — это не написанный код
Если программист — наемный работник, как это обычно бывает, то это утверждение неверно. Программист-наемный работник продает нанимателю свой труд, а не решение его проблем. Продуктом же труда программиста является написанный код, который от программиста отчуждается: права на код переходят к нанимателю.
А полезность этого, приобретенного нанимателем, кода — это чисто проблемы нанимателя: «бачили очі, що купували».
PS Если программист (или артель программистов) работает по подряду — то там все совсем по-другому. Но в наше время это редкость.
JustDont
18.10.2021 02:18+2Из всей своей практики (не супермного, но за полсотни перевалило, за сотню пока нет) — могу только сказать, что никогда в жизни я не встречал кандидата, чьи ответы на вопросы в стиле школьного экзамена (у меня было много коллег, обожавших экзаменационные собеседования) создавали бы более полное впечатление, чем сессия лайвкодинга на 15 минут на задаче уровня FizzBuzz.
Те, кто быстро и уверенно пишут простой код — так же спокойно ответят на существенную часть экзаменационных вопросов, те, у кого возникают затруднения уровня "как же мне написать цикл?" — засыплются на вопросах.
Я никогда не видел людей, которые бы прекрасно писали простенький код, но откровенно сливались бы на теоретических вопросах, зато я видел людей, которые могли очень долго и очень правильно отвечать на вопросы, но вот очень простой код писали с огромным трудом.Далее, я точно так же не встречал людей с существенным интересным опытом (те, кому есть что рассказать реально интересного на вопросы типа "какими проектами занимались и что в них было самым крутым?"), которые при этом не могли бы писать код. Встречал людей, которые очень любили поговорить о программировании без самого программирования, но они вычисляются крайне легко, так как в разговорах очень быстро уходят в очевиднейшую чушь.
Из этого вывел список приоритетов по убыванию:
- Мотивационно-жизненные вопросы ("секция HR"). Это без преувеличения самые важные вопросы, которые вы (не обязательно вы как технический специалист, но кто-то их должен задать обязательно) можете задать, и самые важные ответы, которые вы вообще получите от кандидата. Это практически единственная точка, на которой можно как-то отсеять тех людей, которые тем или иным способом навредят команде или компании (например тем, что возьмут и через квартал уволятся без объявления войны). Любые сомнения в мотивации и вовлеченности кандидата и в его способности работать в команде — это очень серьезно.
- Вопросы на подтверждение опыта. Это те самые "что наиболее крутое вы делали", просто разговор за плюсы и минусы технологий из опыта кандидата и по вашей вакансии (людям с опытом всегда есть что сказать на этот счет, всегда с кровавыми деталями), и тому подобное. С хорошими кандидатами эта секция практически всегда из вопросов превращается в беседу. Плохие — опять же крайне быстро выявляются по их куцым и формальным ответам. К джунами и трейни эта секция, увы, не применима, но для остальных она крайне важна.
- Лайвкодинг. Максимально быстрый способ понять, может ли кандидат писать код. Иногда это уже заведомо понятно из прошлой секции, но в случае сомнений или собеседования людей без особого опыта — это становится ключевой проверкой. Задачи лучше давать исключительно очень простые, но открытые (в которые можно продолжать добавлять новые условия вплоть до превращения очень простой задачи в очень сложную). Ни в коем случае не с заковыристым алгоритмом (чтоб не было ложноположительной офигенности, если кандидат вдруг откуда-то назубок знает этот конкретный случай), и ни в коем случае не с leetcode и подобных источников (мы проверяем, может ли человек писать код, а не практиковался ли он перед собеседованием на leetcode). Тут очень важно именно постепенное усложнение задачи — насколько далеко за отведенное время кандидат способен забраться в дебри постепенно усложняющейся задачи. Заодно это и проверяет не менее важные вещи типа понимания добавляющихся условий и их влияние на уже написанный код.
- Специализация. Это если нужен именно гуру реакта или тому подобное. Зачастую (если команда уже укомплектована специалистами) эта секция может быть вообще не нужна, т.к. отсутствие опыта энтерпрайзовой практики с конкретной либой/фреймворком — весьма незначимая деталь, и чуть более хороший "в общем" кандидат без опыта того же реакта — куда лучше чуть более плохого, но с опытом. Но если в команде специалистов нет — то это имеет большее значение, и выделять под это отдельную часть собеседования может быть весьма оправданно. И, опять же — только если после секции №2 остались какие-то сомнения.
В вопросах закрытого типа (когда кандидат должен дать некий максимально близкий к эталону ответ) я смысла не вижу, в крайнем случае только лишь в секции №4. Это долгий и трудоемкий способ собеседовать — составить хорошо сбалансированный опросник сильно тяжелее и дольше, чем придумать одну простую, но усложняемую задачу; пройти этот опросник с каждым кандидатом — аналогично, тяжелее и дольше.
VitalyCherkov Автор
18.10.2021 10:34Во многом согласен, только уточню пару моментов:
3. Ровно поэтому все вопросы мы формулируем в виде задач. Думаю, нет смысла спрашивать об особенностях языка или технологии, которые ни разу не приходилось использовать и которые легко гуглятся при первой же потребности. В целом, описанный вами сценарий полностью ложится на предложенный мной в статье. В частности, в моем случае каждый следующий вопрос в секции по Реакт — это расширение предыдущего задания)
4. Про конкретно мой кейс с Реактом. Возможно, здесь сработала специфика рынка, но у большинства кандидатов в резюме есть несколько лет опыта использования React. Думаю, в таком случае вполне обоснованно можно провести целую секцию, посвещенную данной технологии, потому что тут мы явно проверяем, насколько глубоко за последние несколько лет разработчик освоил свой основной инструмент. Кажется, это важный показатель не только технических навыков, но и желания разбираться в разных вещах. Конечно, если у кандидата нет опыта в конкретной технологи, то и нет смысла задавать по ней вопросы, вместо этого можно сделать упор на чем-то другом.
По поводу фиксированных формулировок дополнил в тексте статьи. Это скорее нужно для команды собеседующих: если процесс интервью распределяется на несколько человек, очень важно, чтобы все кандидаты получали одинаковые входные данные, и чтобы интервьюер не упустил никакие важные моменты в формулировке впороса и не повлиял бы этим на объективность ответа. Конечно, это только стартовая точка вопроса, от которой далее могут быть отклонения в зависимости от хода мыслей кандидата.
JustDont
18.10.2021 15:39Что-то я не очень понимаю, как выглядят "вопросы в виде задач" — нельзя ли один (хотя бы совсем мелкий) пример?
Секцию по реакту-то можно проводить, конечно, только что она покажет? Разные люди пользуются реактом на совсем разном уровне — у одних всё готово и настроено и код обязан укладываться в пространные и подробные code style guide, другие всё сами на коленке настроили-собрали, третьи в силу каких-то соображений шпарят на голом реакте без всего остального, у четвертых реакт только рендерит, а всё остальное делают другие либы… что из этого принципиально именно для вашей вакансии, и насколько это критично?
Это скорее нужно для команды собеседующих: если процесс интервью распределяется на несколько человек, очень важно, чтобы все кандидаты получали одинаковые входные данные, и чтобы интервьюер не упустил никакие важные моменты в формулировке впороса и не повлиял бы этим на объективность ответа.
Я, если честно, совсем не понимаю, зачем это вам. Вы не ЕГЭ проводите же, зачем вам откалиброванные вопросы? В моем понимании, любая процедура технических собеседований обязана ответить на один, максимум два вопроса:
1) Берем ли мы этого кандидата? Да/нет.
2) Если на первый вопрос ответ "нет", то почему?
И второй вопрос — нужен по большей части для выдачи фидбека.
В чем смысл выставлять кандидатам какие-то оценки? Да, если в моменте у вас есть несколько подходящих кандидатов, то естественно их можно и сравить (если нет возможности и необходимости нанять всех). Но вообще-то надо вакансию закрыть пригодным для этой роли человеком, а не сидеть и ждать божественного программиста, который восхитительно ответит на вопросы.
А когда не надо ставить оценки — то калибровка вопросов не нужна. Специалист по проекту/направлению, на которое нужны люди — составляет вопросы/задачи, и конкретной вакансии сопоставляется конкретный набор этих вопросов и задач. На другие вакансии может быть легче/сложнее отбор? Ну так и пусть, что в этом плохого? Если надо будет отбор скорректировать (слишком хреновых кандидатов берем, либо наоборот никто не может пройти отбор) — то скорректируете.VitalyCherkov Автор
18.10.2021 16:50К сожалению, не могу опубликовать конкретный пример с заданием. Но чаще всего это задача на live coding, покрывающая какую-то область или открытый вопрос о том, как бы человек решал определенную проблему.
По поводу React, нам удалось, на мой взгляд, разработать задание, которое раскрывает то, насколько вообще человек понимает, как устроена эта библиотека и принципы, на которых она основана. Если, например, человек указывает N лет опыта React, то как бы он его ни использовал, мы можем предположить, с чем он сталкивался и можем это проверить. Дело не в стайл-гайдах, а в понимании базовых концепций. Но опять же, это всё частности, специфичные для предметной области.
По поводу откалиброванных заданий. Здесь дело именно в том, что на одну вакансию собеседуем параллельно несколько человек и часто бывает, что есть два примерно равных кандидата, которых собеседовали разные интервьюеры, хочется достичь объективности в том, кому отдать приоритет.
Как пример: мы регулярно проводим школы, после которых выпускается несколько сильных студентов. Все хороши, но пока что у нас нет ресурса предлагать стажировку всем, поэтому нужно справедливо определять лучших)
strannik_k
19.10.2021 19:25что наиболее крутое вы делали
Вы, как и я, фронтенд разработчик. Можете привести пример, что бы вы ответили на этот вопрос? Я не работал в каких-либо крутых компаниях. В обычных средненьких компаниях над обычными проектами. За 5 секунд на собесе не смогу среди сотен (а то и тысяч) выполненных задач вспомнить крутые, отфильтровать их по крутости и сформулировать, что и как я там делал несколько лет назад. Да и язык у меня не подвешен. Без подготовки к этому вопросу меня уже на этом этапе отнесут к непрограммистам или плохим программистам. А ведь потом еще надо решить простую задачу, и ответить на вопросы по теории, что опять же не сделаю без подготовки.
JustDont
19.10.2021 19:44+1Я не работал в каких-либо крутых компаниях.
Я тоже. Из самого крутого — делал визуальный (и невизуальный, чисто конфигами) конструктор UI, чтоб продукт был гибко настраиваемым либо шарящим в теме (сетевое администрирование) клиентом, либо же собственными конторскими спецами предметной области, без дальнейшего привлечения программистов.
Дальше я по этой теме могу еще минут 10 минимум говорить, там есть что вспомнить, но давайте пример на этом завершим :-)Далее по списку самого интересного можно еще остановиться на графиках с очень продвинутой автоподстройкой осей (удобные для восприятия периоды времени, правильные множители единиц, кило/мега/итд, подбор количества меток по осям, чтоб не слишком мало и не слишком много, автовыбор между логарифмической и линейной осью, вот это всё); и даже на интеграции ужей с ежами (реакта/ангуляра/вебкомпонент) — но это всё уже несколько менее интересные темы относительно топ-1. В общем, рассказом можно легко занять полсобеседования, при желании.
За 5 секунд на собесе не смогу среди сотен (а то и тысяч) выполненных задач вспомнить крутую и сформулировать что и как я там делал несколько лет назад.
Вспомните заранее. Вопросы подобного вида сейчас, без преувеличения, задают на 8 собеседованиях из 10.
Без подготовки к этому вопросу меня уже на этом этапе отнесут к непрограммистам или плохим программистам.
Скорее к программистам, которые ничего более запоминающегося, чем двиганье кнопочек, не делали. Но в этой секции у меня еще вопросы по плюсам-минусам технологий, и шансов развести на разговор еще предостаточно.
strannik_k
19.10.2021 20:13Спасибо за подробный ответ!
Вспомните заранее.
В последнее время так и делаю. Это в прошлом пару собесов с самого начала пошли не так, т.к. не был готов к этому вопросу.
DenisTrunin
18.10.2021 03:29А с вашей стороны(для описываемых ситуаций в статье) какой результат ждут? Прошел\Не прошел и какой-то условный грейд? Или наоборот - хотят знать ответ на вопрос кандидат к примеру хочет 200к, стоит ли он этих денег
VitalyCherkov Автор
18.10.2021 10:57Здесь бывает по-разному. Иногда кандидат действительно сам спрашивает, на какой грейд мы его оцениваем. В таком случае мы отвечаем на данный вопрос, опираясь на нашу матрицу компетенций.
Чаще всего в процессе общения кандидат озвучивает свои ожидания и далее по итогам собеседования мы решаем, готовы ли мы эти ожидания удовлетворить. Если ожидания кандидата расходятся с нашими итогами, то в случае отказа тоже обосновываем, почему именно отказали. А если делаем оффер, и считаем, что вилка кандидата не соответсвует его результатам, то можем предложить свой вариант также обосновывая свое решение. Кстати, оффер может отличаться как в меньшую, так и в большую сторону.
Ну и если произошел match, то тут вообще всё здорово :-)
Nialpe
18.10.2021 10:06+1На собеседовании очень хочется проверить насколько хорош кандидат для выполнения предполагаемой работы, состоящей из набора умений X, но проверяют умения Y, которые умеют (могут, хотят) проверить и считают коррелирующими.
По моей практике большинства собеседований предполагается такая работа разработчика:
Без IDE (только хардкор, пишем в блокноте, если умеешь водить жигуль - значит на бэхе будешь вообще красавчик)
Без Интернета и документации (ты должен помнить все, склеротикам не место у нас)
Без времени для размышлений (у нас спринты, дедлайны, планирование для галочки, мы набрали столько, что не вывозим, машем веслами)
С обязательным персональным надсмотрщиком (мы должны контролировать, что пишешь именно ты)
С написанием велосипедов (ты должен понимать основы, если надо и до квантовой физики углубимся)
Критикуешь - предлагай. Совместное код ревью, состоящее из двух частей. Первая часть кандидат показывает свой код, вторая интервьювер. И во время ревью уже можно слово за слово погружаться в дебри языковых конструкций, паттерны и прочие прелести, отталкиваясь от написанного. У меня есть свои заготовки со специально допущенными ошибками и с удовольствием посмотрю любой helloworld кандидата, пусть даже скопированный за минуту до собеседования с интернета, найду о чем спросить.
Но нет, всем проще так делать: "билет номер 4, а при нем задача".
Резюмируя. Нет правильного или неправильного собеседования. Каждый ищет под свои заморочки.
VitalyCherkov Автор
18.10.2021 11:16Согласен со многими мыслями. Именно поэтому думаю, что нет смысла спрашивать на собеседовании теорию, которая используется раз в жизни и легко гуглится. Не раскрывал этого в статье, но уточню: на мой взгляд, если у кандидата в резюме указан богатый и релевантный нашим потребностям опыт, то стоит проверить именно его — опыт, а не знания. Это не то, что гуглится или запоминается, это вещи, которые нужно в первую очередь понять. И то, насколько глубоко человек понял некоторые моменты (на примере конкретных кейсов), отлично демонстрирует его опыт.
Классный пример с заданиями на поиск ошибок / ревью. У нас тоже бывают такие вопросы. Еще из интересного, к чему пришел. Если кандидат прикрепил свой Гитхаб, можно заранее изучить его и найти какие-нибудь примеры кода, которые затем предложить проревьюить самому кандидату. Таким образом можно проверить профессиональный рост человека: кем он был раньше и что делал тогда, и как он изменил свои взгляды на данный момент. Но тут, конечно, нужно быть аккуратным: примеры должны быть такими, которые можно улучшить, но они должны оставаться релевантными (т.е. чтобы не было ответа: тут всё переписать с одной технологии на другую)
dsavenko
18.10.2021 11:25Таким образом, со слабым кандидатом собеседование занимает не больше часа. И наоборот — если кандидат сильный, на каждую секцию можно выделить побольше времени.
То есть у вас получается, что слабых кандидатов вы отпускаете пораньше, зато сильных мурыжите по полной программе? :) Это им в награду за то, что они сильные? :)
По-моему, должно быть наоборот. Если видно, что кандидат сильный, не парить ему мозги. А если видно, что кандидат слабый (но не безнадежный), то посидеть с ним подольше, дать больше шансов все-таки что-то нарешать и доказать, что "слабость" кажущаяся. Вроде так логичней.
mercifulcarnifex
18.10.2021 23:14Задача на собеседовании ведь определить границы познания человека, а не просто сказать «ок» или «не ок».
Поэтому, например, если кандидат плавает уже в базовых вещах, он точно не подходит и нет смысла его мучать. На практике «кажущейся» слабости не встречал. Наоборот скорее, начальные задачки кандидат может решать хорошо, а с более сложными не справляться.
Поэтому важно «прощупать» уровень человека, давая разные кейсы, разной сложности и на разные темы. Так можно более точно определить грейд и соотвественно уровень зп и тд. Мало ли, вы рассматриваете вакансию мидла, а перед вами сеньор.
Warg_nvkz
18.10.2021 11:27Как же любят люди устраивать допросы с пристрастием. Все эти "каверзные" вопросы по основам, на которые сами не смогут ответить, не подготовившись. Для чего это все? Все равно все непонятные моменты о работе технологии или гуглятся, или тестируются.
Для того чтобы понять, разбирается ли человек в теме, работал ли он с этой технологией, достаточно одного правильно поставленного вопроса. Суть вопроса в том, что на него нельзя ответить открыв учебник и найдя ключевое слово, человек должен знать общие принципы, механизмы работы, должен иметь опыт, который позволит ему собрать множество знаний, переформулировать его в терминах технологии и ответить на вопрос. Да, над его формулировкой нужно поломать голову, но это время будет явно меньше, чем многочасовые собеседования с кандидатами.
Например, вопрос о работе с cmd.exe: "Есть два текстовых файла. Как вывести только их содержимое вместе на экран (соответственно одной командой и чтобы не было никакой дополнительной информации)?". Если человек может написать хотя бы одну команду (путь даже и с ошибками, но в правильном направлении), то это означает, что он имеет достаточный уровень знаний и опыта, чтобы работать с cmd, а если что-то не знает, то может быстро узнать и никакие дополнительные вопросы уже не нужны.
На своем опыте могу сказать, что когда мы составили список из 10 подобных вопросов по нашим технологиям, даже собеседования проводить было не нужно, люди сами понимали уровень своих знаний, могут они ответить на эти вопросы или нет.
Чтобы понять, как человек программирует не нужно: "это же вам нужна работа, так что быстренько, за пару дней, напишите нам проектик, над которым мы будем работать две недели, но нам лень, а мы возможно вам потом перезвоним". Достаточно простого задания, там будут видны основные моменты, которые вас интересуют. А программирование на листочках, с поиском ошибок, это вообще за гранью добра и зла.
А еще эти "психологические"/HR вопросы. Зачем это программисту? Психопаты и нарциссы могут производить очень хорошее первое впечатление даже на психологов. Для этого нужен прямо профессиональный психотерапевт. Единственно, член или руководитель группы, представляющий с кем он работает, может представить по манере разговора, как он в эту группу впишется и как группа изменится с его приходом. А может наоборот спонтанный и активный человек поднимет производительность вашей команды.VitalyCherkov Автор
18.10.2021 11:29Спасибо за коммментарий. Так вышло, что на многие тезисы ответил в других ветках.
Чтобы не дублировать, прикреплю ссылки:
1. О формулировках вопросов и о том, что нужно проверять не сухую теорию, а опыт ответил здесь:
https://habr.com/ru/company/kts/blog/583816/#comment_236012242. В этой ветке обсудили способы, которыми можно проверить опыт кандидата:
https://habr.com/ru/company/kts/blog/583816/#comment_236010703. Здесь ответил о секции HR
https://habr.com/ru/company/kts/blog/583816/#comment_236012484. О тестовом задании на несколько дней:
Здесь я всё же склоняюсь к тому, что не совсем корректно заставлять кандидата выполнять тестовое, особенно, если это задание несет коммерческую выгоду компании, в которую он собеседуется. Поэтому считаю, что нужно стремиться проверить match с кандидатом не выходя за рамки собеседования (или если нужно, нескольких собеседований).
Warg_nvkz
18.10.2021 11:56Сразу уточню, что статья называется, "Как проводить собеседования", а не "Как мы у себя проводим собеседования". Если у вас задача HR сводится к пониманию насколько человек адекватен, и в состоянии общаться по делу, то хорошо, но у других не так.
Про все остальное я веду к тому, что полноценное тестирование всего спектра навыков занимает долгие часы и даже дни. Сразу вспоминается история моей подруги с Яндексом и тремя собеседованиями. Если человеку нечего делать и он готов на все это, ну ок. Но, полагаю, большинство ищет работу не уходя с предыдущей и даже час времени, это, в общем случае, роскошь.
Поэтому я и считаю, что хороший общий вопрос, ответ на который можно узнать только из личного опыта, лучше многочасовых наблюдений за тем, как человек пишет код (тем более на листочке, как предлагают на некоторых собеседованиях) и покрывает большой процент ЗУНов(знания/умения/навыки) кандидата и, при этом, требует от силы 1-2 минут. Естественно иногда нужно видеть и навыки написания программ, но они не связаны напрямую со знанием технологии и такие тестовые задания можно упростить до максимума.
Mike-M
18.10.2021 16:58Но чаще всего я завершаю собеседование фразой, что мы вернёмся с обратной связью в ближайшие дни.
И как, возвращаетесь? Или используете эту фразу как другие, для вежливого отказа?VitalyCherkov Автор
18.10.2021 17:03+1Возвращаемся, конечно) Если это отказ, то он должен быть корректным и уважительным к кандидату, с указанием причины.
zhuravlev_oe
19.10.2021 07:07У автора замечательный академический стиль, чувствуется школа.
Такой подход хорош, если у вас есть куча времени, масса народа для собеседования со стороны работодателя и поток собеседуемых, которых нужно всех прогнать через процедуру и проранжировать в соответствии с их ценностью для компании, обосновав рейтинг каждого. Здесь процесс не менее важен, чем результат.
Для основной массы работодателей, представляющих из себя компании с численностью от 5 до 50 человек, такая растрата ресурсов неприемлема.
Как правильно отметили выше, существуют гораздо более экономичные способы поиска кандидатов, когда несколько правильных вопросов позволяют принять решение по кандидату
Автор, случаем, не в Газпроме работает? :)
isicju
У меня на практике оказывались такие ограничения что все лучшие практики катились в ад Как то я писал статью про проведение собеседований ( https://dzone.com/articles/how-to-conduct-an-interview-and-evaluate-developer задавая сначала сложные вопросы и переходя к простым в случае провала). Но потом оказалось что тотальная масса собеседуемых не тянут, а кого то нанять нужно. Сошлись на том что сдали задавать простые задания и затем сравнивать насколько люди следуют лучшим практикам от tdd и базового oop до использования функционалки и исключений с корректными тестами.