Собеседования — взгляд интервьюера

Давным-давно, ещё в стародавние времена я написал статью для Хабра — Собеседование. Взгляд соискателя.

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

Настало время создать сиквел. Встречайте мой #10YearChallenge, только теперь со стороны интервьюера.

Зачем? Почему? Для кого?

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

Скучная и нудная предыстория о себе, которую можно и пропустить

В этом разделе я не собираюсь открывать секреты Полишинеля, лишь небольшое отступление, повествующее обо мне. Собеседования стали моей обязанностью последние 5-6 лет. Сейчас я способен собеседовать кандидатов от уровня Junior-разработчик, до уровня Junior-manager, разработчиков только в определённом стеке технологий в котором происходил мой «рост» и развитие, т.е. я в жизнь не соглашусь собеседовать С++ разработчика, т.к. сталкиваться с этим языком программирования мне доводилось очень давно.

Всего у меня проведено около двух сотен интервью, были годамесяцы когда я проводил по 2-3 интервью в неделю, было время когда за год провёл лишь 7 интервью. Сейчас комфортным для себя считаю 1 интервью в неделюдве.

Оговорюсь сразу, занимаюсь только техническим интервью, не выдаю job offer в компанию, хотя какое-то время назад подобными полномочиями я обладал.

Про резюме и начало беседы

Перед собеседованием я всегда получаю резюме кандидата. Стоит заметить, что наполнение зависит иногда и от региона, так есть резюме, в которых перечислено что кандидат работал с различными технологиями и просто отжигает в каждой из них. Это всегда выглядит немного подозрительно, т.к. я знаю всего несколько человек, кто шарит и в Java и .Net (например), притом это исключение нежели правило. При том же full-stack разработчик, который может и в .Net и в JS — вполне нормальное явление, хотя и тут есть во что-то больше и во что-то меньше.

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

Не записал — забыл. Лучшая память — это бумага.

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

В среднем мои собеседования длятся от часа и более, обычно до 2х, стараюсь конечно их не затягивать пустым бла-бла-бла. Если же терзает вопрос: «нафига? можно за 10, 15, 30 минут узнать подходит он тебе или нет!», то ответ можно найти в рассуждениях дальше. ;)

Следующим шагом я прошу рассказать кандидата о себе, своём опыте за последние несколько лет. У пытливого читателя сразу возникнет закономерный вопрос: «Зачем? Ты не читал резюме перед собеседованием?! Дно!».

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

Далее как правило возможно 2 развития событий:

1. Кандидат рассказывает без умолку о себе. Какой он(а) хороший и вообще молодец и как повезёт компании, когда она наймёт его. В общем, словами современного классика:
   

   Весь мир преобразится сразу,
   В нём станет больше красоты
   И засияют, словно стразы,
   Улыбки и сведут мосты.
2. Кандидат не очень умеетхочет рекламировать себя, да и зачем, когда есть работа? Болееменее любимая, притом хорошо оплачиваемая.

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

Вопросы и проверка знанийнавыков

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

Теория без практики мертва и бесплодна, а практика без теории бесполезна и пагубна. © by Чебышев.

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

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

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

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

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

Проверка практических и теоретических навыков — в вопросах и ответах

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

Особо задерживаться на пункте проверки теории не буду, отмечу лишь что нужно пройтись по теории из тех разделов, которые заявил человек, но и не забыть поспрашивать что-то рядом лежащее. Как пример человек может рассказать, что он пилил архитектуру для проекта, а задав ещё несколько уточняющих вопросов: «сколько человек было на проекте?» или «а какие ещё у тебя были обязанности?» можно узнать что человек ещё и командой в 10 человек вполне успешно рулил, но вот вылетело из головы это на интервью или же интервьюер не задал правильных вопросов. Так можно и ценные навыки упустить.

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

«Сам как проверять будешь?»
Попрошу набросать небольшой кусок кода, не придираясь к синтаксису, точности вызовов методов и прочей ерунде. Лист бумаги или маркерная доска — без разницы. Мы же не проверяем насколько человек помнит все сигнатуры перегруженных методов какого-то класса. При этом писать большой кусок кода я считаю излишним, на собеседование вполне нормально дать небольшой кусок кода, например, мой любимый на проверку знаний DI «концепции» и попросить дополнить простенький метод, указав, что можно написать, а можно рассказать словами. У меня достаточно часто бывают ребята, которые мельком взглянув на код, могут сказать: «Ну здесь нужно использовать DI, можно так, а можно и так, потом делаем это и вот это». Если человек может объяснить всё меньше чем за минуту, зачем его напрягать писаниной?! Это же касается и других технических навыков.

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

«Опять писать код? Только через код проверить наличие практических навыков можно?»
Отнюдь, если человек начинает рассказывать про какие-либо случаи из практики или применение тех или иных инструментов, навыков, то вполне логично чуть усложнить ситуацию и спросить его как бы он действовал. Или же дать ситуацию из личного опыта и посмотреть, как бы решал её кандидат. Признаюсь, честно, я до сих пор хожу по собеседованиям в качестве кандидата, как по техническим, так и по менеджерским, правда если техническое собеседование в несколько этапов, я «палюсь» и сообщаю что код пишу мало, а в основном это архитектура и управление проектами. На одном из таких технических собеседований, мне задали интересный вопрос как сделать первый деплой с первичной настройкой инфраструктуры в полностью закрытую систему, т.е. она не «торчит» в интернет, и доступа из вне в неё нет от слова совсем, а отправить специально обученного человека нельзя. На мой взгляд — достаточно интересный вопрос.

Про разницу собеседований

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

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

Эпилог

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

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

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

Автор: Mephistophele

Источник