Собеседования — взгляд интервьюера
Давным-давно, ещё в стародавние времена я написал статью для Хабра — Собеседование. Взгляд соискателя.
За 10 лет прошедших с тех пор многое поменялось: увеличилось количество проектов в моём портфолио, как успешных, так и успешно проваленных; прочитаны десятки книг, просмотрены десятки тренингов и видосиков на ютубе, как полезных так и просто «поедателей времени», а также десятки собеседований, но которые проводил уже я. Спустя некоторое время произошёл пересмотр взглядов, но это не точно, о чем я и хочу рассказать в этой дискуссионной статье.
Настало время создать сиквел. Встречайте мой #10YearChallenge, только теперь со стороны интервьюера.
Зачем? Почему? Для кого?
Утверждение что я такой офигенный и сейчас лёгким взмахом пера или нажатием кнопок на клавиатуре дам самые дельные советы и всё будет хорошо — в корне лживо. Цель этой статьи — обмен опытом и, возможно, дать начинающим интервьюерам какие-то общие рекомендации, т.к. человек интервьюирующий кандидата — лицо компании. Вы захотите пойти в контору, в которой на входе интервьюер или HR\Recruiter мудаки со стажем и с порога демонстрируют это? Я — нет.
Скучная и нудная предыстория о себе, которую можно и пропустить
В этом разделе я не собираюсь открывать секреты Полишинеля, лишь небольшое отступление, повествующее обо мне. Собеседования стали моей обязанностью последние 5-6 лет. Сейчас я способен собеседовать кандидатов от уровня Junior-разработчик, до уровня Junior-manager, разработчиков только в определённом стеке технологий в котором происходил мой «рост» и развитие, т.е. я в жизнь не соглашусь собеседовать С++ разработчика, т.к. сталкиваться с этим языком программирования мне доводилось очень давно.
Всего у меня проведено около двух сотен интервью, были года\месяцы когда я проводил по 2-3 интервью в неделю, было время когда за год провёл лишь 7 интервью. Сейчас комфортным для себя считаю 1 интервью в неделю\две.
Оговорюсь сразу, занимаюсь только техническим интервью, не выдаю job offer в компанию, хотя какое-то время назад подобными полномочиями я обладал.
Про резюме и начало беседы
Перед собеседованием я всегда получаю резюме кандидата. Стоит заметить, что наполнение зависит иногда и от региона, так есть резюме, в которых перечислено что кандидат работал с различными технологиями и просто отжигает в каждой из них. Это всегда выглядит немного подозрительно, т.к. я знаю всего несколько человек, кто шарит и в Java и .Net (например), притом это исключение нежели правило. При том же full-stack разработчик, который может и в .Net и в JS — вполне нормальное явление, хотя и тут есть во что-то больше и во что-то меньше.
Минутка оправдания: к сожалению на собеседования я прихожу с ноутбуком
Не записал — забыл. Лучшая память — это бумага.Поэтому пришёл, объяснил зачем нужен ноутбук и, если кандидат не против, открыл записную книжку
В среднем мои собеседования длятся от часа и более, обычно до 2х, стараюсь конечно их не затягивать пустым бла-бла-бла. Если же терзает вопрос: «нафига? можно за 10, 15, 30 минут узнать подходит он тебе или нет!», то ответ можно найти в рассуждениях дальше. ;)
Следующим шагом я прошу рассказать кандидата о себе, своём опыте за последние несколько лет. У пытливого читателя сразу возникнет закономерный вопрос: «Зачем? Ты не читал резюме перед собеседованием?! Дно!».
Читал, но как показывает практика иногда люди рассылают резюме морально устаревшее, не отображающее последних достижений. Нет это не людская лень, иногда у человека нет времени, иногда другие задачи, иногда обновил второпях. Притом в IT сфере зачастую работа ищет кандидата, а не наоборот — это нужно понять и принять.
Далее как правило возможно 2 развития событий:
- Кандидат рассказывает без умолку о себе. Какой он(а) хороший и вообще молодец и как повезёт компании, когда она наймёт его. В общем, словами современного классика:
Весь мир преобразится сразу,
В нём станет больше красоты
И засияют, словно стразы,
Улыбки и сведут мосты. - Кандидат не очень умеет\хочет рекламировать себя, да и зачем, когда есть работа? Более\менее любимая, притом хорошо оплачиваемая.
В первом случае нужно слушать кандидата крайне внимательно, делать пометки и по результатам пометок задавать глубоко вопросы. Как показывает практика, бывают случаи, когда люди прекрасно разбираются в различных вопросах, в добавок имеют достаточно крутой навык самопрезентации — красавцы, аплодирую таким стоя! Иногда бывает наоборот, набрали всевозможных названий, терминов и, не только впихнули это всё в резюме, но и решили покозырять этими словами на собеседовании
Вопросы и проверка знаний\навыков
Сразу замечу, что стоит разделять 2 подхода к вопросам — наличие практического опыта и наличие теоретический знаний.
Теория без практики мертва и бесплодна, а практика без теории бесполезна и пагубна. © by Чебышев.В моём понимании хороший инженер — человек, сочетающий в себе, как наличие практического опыта, так и теоретических знаний, т.к. задания нужно не только уметь делать от забора до обеда, делать его хорошо (читай профессионально), но иногда и объяснять, что сделано коллегам, да и просто не выглядеть профаном в глазах других.
Поэтому, когда человек рассказывает о своём предыдущем опыте, он показывает, что действительно «щупал» на практике, а потом уже можно и теоретических вопросов накинуть, чтобы иметь представление что человек пользовался микроскопом не для забивания костылей в шпалы.
Если человек хочет порисовать, объяснить что на бумажке или на доске для рисования — пожалуйста, я, например, буду только рад такой наглядности.
Так же я буду явно подталкивать кандидата к рассуждениям «вслух», т.к. это достаточно полезный процесс, как с точки зрения соискателя — он демонстрирует свои навыки рассуждать и делать выводы, так и с точки зрения интервьюера — возможно кандидату не хватает сущей малости чтобы человек смог раскрыться с положительной точки и продемонстрировать свои знания, что подобно небольшому камушку, способному вызвать огромный камнепад.
Таким образом мы приходим к тому, что одна из основных задач интервьюера — помочь кандидату продемонстрировать свои знания и практические навыки. Поэтому и интервью может длиться более часа.
Проверка практических и теоретических навыков — в вопросах и ответах
Поспрашивать теоретические вопросы вполне полезно и интересно, это показывает и широту взглядов и познаний человека, так и умение находить информацию в различных источниках. Особо уважаю людей, которые отвечая на теоретический вопрос могут вплести какую-то отсылку из своего практического опыта.
Особо задерживаться на пункте проверки теории не буду, отмечу лишь что нужно пройтись по теории из тех разделов, которые заявил человек, но и не забыть поспрашивать что-то рядом лежащее. Как пример человек может рассказать, что он пилил архитектуру для проекта, а задав ещё несколько уточняющих вопросов: «сколько человек было на проекте?» или «а какие ещё у тебя были обязанности?» можно узнать что человек ещё и командой в 10 человек вполне успешно рулил, но вот вылетело из головы это на интервью или же интервьюер не задал правильных вопросов. Так можно и ценные навыки упустить.
«Ну ладно, теорию опросить довольно легко, а практику как проверять-то будем? Посадим за комп и заставим писать код? Или за тестовое сейчас начнёшь топить?»
Я как был противников тестовых заданий, так и остаюсь приверженцем этой теории. Человек не должен тратить своё личное время на решение задач, которые не оплачиваются, если же интервьюер не может понять способен человек писать код, не прибегая к тестовому, то такой интервьюер дно. Более того в законодательстве закреплена норма испытательного срока, который работает в обе стороны: сотрудник понимает подходит ему компания, оправдались ли ожидания, компания же в свою очередь может оценить более детально профессиональные качества человека.
«Сам как проверять будешь?»
Попрошу набросать небольшой кусок кода, не придираясь к синтаксису, точности вызовов методов и прочей ерунде. Лист бумаги или маркерная доска — без разницы. Мы же не проверяем насколько человек помнит все сигнатуры перегруженных методов какого-то класса. При этом писать большой кусок кода я считаю излишним, на собеседование вполне нормально дать небольшой кусок кода, например, мой любимый на проверку знаний DI «концепции» и попросить дополнить простенький метод, указав, что можно написать, а можно рассказать словами. У меня достаточно часто бывают ребята, которые мельком взглянув на код, могут сказать: «Ну здесь нужно использовать DI, можно так, а можно и так, потом делаем это и вот это». Если человек может объяснить всё меньше чем за минуту, зачем его напрягать писаниной?! Это же касается и других технических навыков.
Чуть сложнее дело обстоит с навыками проектирования, например БД, тут я могу попросить и набросать на доске, но загоняться следует ли человек каким либо нотациям я точно не буду.
«Опять писать код? Только через код проверить наличие практических навыков можно?»
Отнюдь, если человек начинает рассказывать про какие-либо случаи из практики или применение тех или иных инструментов, навыков, то вполне логично чуть усложнить ситуацию и спросить его как бы он действовал. Или же дать ситуацию из личного опыта и посмотреть, как бы решал её кандидат. Признаюсь, честно, я до сих пор хожу по собеседованиям в качестве кандидата, как по техническим, так и по менеджерским, правда если техническое собеседование в несколько этапов, я «палюсь» и сообщаю что код пишу мало, а в основном это архитектура и управление проектами. На одном из таких технических собеседований, мне задали интересный вопрос как сделать первый деплой с первичной настройкой инфраструктуры в полностью закрытую систему, т.е. она не «торчит» в интернет, и доступа из вне в неё нет от слова совсем, а отправить специально обученного человека нельзя. На мой взгляд — достаточно интересный вопрос.
Про разницу собеседований
Пожалуй, одна из самых дискуссионных тем, т.к. с точки зрения интервьюера нужно иметь чёткое понимание как, куда и зачем мы собеседуем кандидата. Рассмотрим по порядку:
- Т.к. я занимался наймом и в маленькой компании и в достаточно большой, то здесь есть свои различия. Нанимая в большую компанию важно понимать, что человек знает и умеет, т.е. интервьюер обязан определить список навыков и глубину владения данными навыками. Связано это с тем что можно найти проект подходящий под навыки и умения кандидата.
- Проектное собеседование или собеседование в маленькую компанию. Я специально не разделяю два этих понятия потому что по своему механизму подходы в этих собеседованиях очень сходны. В таких интервью у вас есть один или несколько кандидатов, тут как повезёт, и вы пытаетесь понять насколько кандидат подходит вам, по навыкам которыми он владеет. При этом технический интервьюер должен быть вовлечён в проект, а не быть приглашённым со стороны, т.к. такой человек имеет представление о необходимости наличия тех или иных навыков и возможностью пожертвовать ими или нарастить недостающие в приемлемые сроки.
Эпилог
Замечу что когда начинал свою деятельность интервьюера, то опирался на заметки из своей предыдущей статьи и старался не допускать ошибок, которые наблюдал у других. Хотя и мой путь был тернист и не безболезнен.
В этой статье, призывающей к дискуссии, я намеренно опустил способы задавать вопросы, т.к. это выбор каждого, да и объём написанного получился уже большой.
Надеюсь, эта статья будет полезна для всех кто начинает свой путь в собеседованиях и не забывайте, что вам должно это нравиться иначе у вас будет только негатив и демотивация, которая не скажется положительно ни на ком.