За свою профессиональную карьеру разработчика и лида, я не раз был как с одной, так и с другой стороны собеседований. Я хочу поделиться своими советами и наблюдением как найти и максимально раскрыть кандидата, на что обратить внимание, какие вопросы уместные, а какие задавать не стоит.
Начну чуть издалека — для того, чтобы быть в тренде полезно периодически посещать собеседования. При этом важно не превратиться в маньяка, который заточил себя под вопросы и задачи, но совсем потерял опыт и мотивацию делать настоящие проекты. В этом случае нужно придерживаться здравого баланса.
В рамках этой заметки будем рассматривать собеседование кандидата на должность тех специалиста в команду.
Техническая часть
Здесь все зависит от сложности проекта, реально используемых технологий и нагрузки. Если в проекте нет хайлоада, глубокой оптимизации производительности, я бы не стал сильно грузить кандидата задачами на эту тему, но прошёлся бы по базовым темам.
На мой взгляд, оптимально начать с общих вопросов. ICE-breaker, но не сильно опускаться в «кринж» вопросы, которые будут неудобными как задающему, так и отвечающему.
Хорошая практика это иметь готовую таблицу вопросов, по которой можно идти выбирая несколько подходящих из секции. Документ будет хорошо периодически расширять и обновлять, чтобы не скучали интервьюеры. При этом менять не так часто, не повышая когнитивную нагрузку задающего вопросы и анализирующего ответы. Я бы назвал оптимальным интервал ротации файла для интервью от полугода до года.
Решать задачи в онлайне — часто используемая практика, но достаточно стрессовая. Поэтому ее стоит использовать аккуратно, делать скидку на то, что не каждый может под пристальным вниманием сразу написать хитрый алгоритм в IDE или онлайн редакторе без автокомплита и прочих плюшек. Да и в целом этот скил можно тренировать в том же leetcode, не умея решать реальные задачи. Обычно к такому интервью стоит готовиться, а в этом есть как плюсы, так и минусы.
Все индивидуально. Я бы посоветовал не сильно ударяться, проверить общее умение мыслить, думать и рассуждать.
Вопросы по инструментам будут приемлемы, если у вас схожий стек. Если это не так, то полезнее будет узнать про те инструменты, которые использовал кандидат. Это поможет выявить насколько он гибок и умеет ли быстро разбираться в новом. Такой подход намного интереснее и практичнее.
Пример интересных вопросов
- Какой твой любимый фреймворк, почему? А нелюбимый?
- Какие плюсы и минусы лично для тебя в работе с докером?
- В каком случае отдашь предпочтение NoSQL бд и почему?
Бизнес мышление
Обычно это про софт скилы, понимание для чего вообще нужно IT. Как стоит выстраивать коммуникацию с бизнесом? Откуда берутся деньги на техдолг?
Как правило, есть разные модели и проекты, поэтому важно понимать — нужен ли вам человек с развитой бизнес ориентацией, хардкорный технарь, а может золотая середина.
В этом случае простыми вопросами не обойтись и лучше задавать открытые, слушать и видеть человека (хорошо когда есть камера, можно калибровать человека, его реакцию).
Примеры интересных вопросов
- Бизнес заказчик требует очень быстро сделать фичу, которую хорошо за такой срок не сделать. Твои действия?
- Заказчик просит работать сверх урочно, как ты к этому отнесёшься?
- Если ты видишь, что требования не оптимальны, будешь ли проводить коммуникацию и как?
Моделирование ситуаций
Здесь начинается самое интересное. Первые 2 части помогают собрать некий портрет, провести условный экзамен, но самое интересное то, как человек будет вести себя дальше. Есть выражение — «посмотри как человек готовит яичницу — так он будет делать все».
Вспомните самый свежий факап на вашем проекте, упакуйте его как некую интерактивную игру, где вы выступаете в роли условной тех поддержки, и идете к кандидату с этой проблемой.
У него есть весь инструментарий, возможность задавать уточняющие вопросы, любой административный ресурс. Играйте в эту игру, смотрите, как человек будет действовать.
Ситуаций можно придумать много, например: самый проблемный деплой, какая-нибудь большая задача или проект, которая имеет не одно решение. Пытаемся увидеть какой кругозор у человека.
Основная задача — не проверить зазубренный материал или умение щелкать алгоритмические задачи, а понять наличие фундамента и базы, эрудицию, умение анализировать, принимать решения, рассуждать, задавать правильные вопросы, слушать и слышать ответы.
Знакомство с командой
Если мэтч пойман — двигаемся дальше.
Как рассказать про команду и проекты? Чем проще, тем лучше. Максимально реально и правдиво. Не стоит приукрашать и продавать, после выхода человек все равно все увидит и узнает.
Если можете — покажите часть кода, инструментарий, UI, так знакомство будет более наглядным. Глубоко в детали уходить не стоит, надо оставить пространство для вопросов.
Еще важно отметить, какие вопросы будет задавать сам кандидат: технические, бизнесовые, на чем он делает акценты.
Если вы в поиске кандидата уровня Junior/Middle — то вопросов может быть мало, либо вообще не быть, а если уровень Senior — наличие вопросов — обязательный фактор, имхо, так как это и показывает опыт человека, умение расставлять акценты, показывает заинтересованность.