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

Все нижеописанное характерно для моей компании, но сам HR достаточно стандартен по калифорнийским стандартам (что сейчас уже практически стало международными стандартами). Никакого пиара, так что просто в двух словах: моя компания — это маленькая транснациональная компания со штатом где-то в 4000 человек, HQ — в Palo Alto, R&D (где я работаю) — Vancouver, BC. Я интервьюирую на позицию в моей команде, которая занимается разработкой web-frontend для встраиваемых устройств (используется Python, C и стандартный HTML-набор).

Составление объявления о приеме на работу

Объявление составляется не только для кандидата, но и для HR-отдела. Первый этап в собеседовании — это телефонное интервью, и объявление должно иметь ключевые слова, которые будут использоваться во время разговора. К сожалению, HR-отдел не всегда компетентен в технической области, и надо это учитывать. Другая скрытая цель объявления — это отпугнуть неквалифицированных кандидатов. К сожалению, зачастую это делается неправильно, и менеджеры указывают глупости типа «30 лет программирования на .NET». Также очень распространен метод «копирования и вставить», когда ищут уже готовые объявления и меняют их под свои нужды. В итоге глупости из оригинального объявления переходят во все остальные.

Так что на объявления надо смотреть трезво, очень часто там сильно перебарщивают. К сожалению, в последнее время к этому уже все так привыкли, что просто плюют на все требования указанные в объявлении, и шлют свое резюме независимо от квалификации.

Анализ резюме

Резюме — это один из ключевых этапов в получении работы, многие весьма недооценивают насколько это важно. Итак, кандидат отсылает резюме со своими данными, и возможно cover letter (все то, что не входит в резюме, обычно это сообщение в стиле «какая вы хорошая компания, и я тоже хороший, давайте дружить!»). В большинстве случаев резюме обрабатывается автоматически, в любой большой компании HR получает по сотни заявок в день, они просто не успевают все обрабатывать вручную. Так что если вы сделали вычурное резюме в фотошопе, есть огромный шанс, что его рассматривать не будут. Это касается иногда и маленьких компаний, когда HR использует стандартные решения в этой области.

При автоматической обработке из резюме извлекаются персональные данные. Если данные некорректны, то в БД они могут попасть в некорректную таблицу. Так что надо лучше соблюдать стандартное форматирование — ФИО, контактные данные в стандартном формате, адрес в стандартном формате. Если не удалось извлечь эти данные автоматически, то в БД будут пустые записи, и они будут рассматриваться в последнюю очередь (или не будут рассматриваться вообще).

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

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

Так что в основном я делаю проверки компаний, указанные в резюме и онлайн-профиль кандидата (просто говоря, ищу в Интернете). Естественно, смотрю блоги и проекты кандидата. Хочу сразу дать рекомендацию для потенциальных кандидатов — имейте профиль в Linked In, свой технический блог и несколько OSS-проектов. Если я не могу найти сетевого присутствия кандидата, то это жирный минус. Я понимаю про NSA, но тем не менее, если человек нигде не светится, то есть две причины — он параноик (что хорошо для некоторых работ), либо он не имеет никакой жизни помимо работы и дома (пусть даже у кандидата есть только страница с котятами в фейсбуке, это уже хорошо — значит это человек, а не обезьянка, умеющая только долбить по клавиатуре). Конечно, есть исключения, но моя практика показывает, что человек, который нигде не светится, обычно достаточно банальная личность без явно выраженных интересов и хобби. Для России это может быть совершенно противоположно, но думаю, также применимо в какой-то мере. В любом случае, для запада проверка сетевого присутствия — must-do.

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

Телефонное интервью

Это стандартная практика, и практически всегда это означает, что ваша кандидатура заинтересовала компанию, и она проведет полноценное интервью. Цель разговора по телефону — выяснить коммуникативные навыки (знание языка), технические навыки (обычно берется пара пунктов из объявления, и уточняется квалификация) и договориться про последующие действия. Не надо ожидать серьезных технических вопросов на первом телефонном интервью, однако надо быть готовым к тому, что могут загадать вопросы с подковырками. Например, спросить сколько у вас опыта работы с .NET, (и учитывая, что в объявлении указано «30 лет опыта») при ответе «31 год» с вами могут тут же попрощаться, потому что они знают, что это вранье. Обычно для такого случая у HR есть специальный вопросник. Но опять-таки ничего сложного обычно не спрашивают, для этого есть техническое интервью.

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

Письменное задание

По сути, это набор вопросов, требующих написания кода. Все ответы можно найти в Интернете, однако есть специфические вещи, с которыми он не поможет. Это позволяет определить, какой терминологией владеет кандидат (обычно знание и умение правильно применить термины говорит многое о квалификации). Например, у нас есть вопрос «перепишите такой-то код используя Python built-in functions». Это многих ставит в тупик, потому что они не знают, в чем отличие built-in-функций от других функций.

Многие вопросы достаточно элементарны, но предполагают несколько вариантов решений. Естественно, мы тоже используем Интернет, и мы знаем какие решения можно найти в Интернете, а какие скорей всего кандидат нашел сам. Однако уровень доверия к любому коду достаточно низок, и мы всегда предполагаем, что кандидат пользовался помощью. Поэтому уже во время личного интервью, мы уточняем как работает тот или иной код.

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

Личное интервью

Если письменное задание было более или менее нормальное, мы назначаем личное интервью. Иногда это происходит, даже если письменное задание было сделано плохо, т.к. необходимо учитывать стресс кандидата. Некоторые люди показывают себе очень плохо при стрессе, и этот фактор нами учитывается. Поэтому в начале интервью мы проводим ice breaker (незначимые разговоры) про погоду, про нас (компанию и нашу команду) и про самого кандидата.

Следующий этап — резюме. Цель разговора про резюме — выяснить социальные навыки и уровень кандидата. У нас был кандидат, которые указал в резюме «Google Street driver» (он водил машину, которая делала снимки) в Ирландии много лет назад. Было интересно просто про это поговорить, и оно хорошо повлияло на саму атмосферу интервью, т.к. сняло скованность. Также мы уточняем инструментарий, которым пользовался кандидат (OS, VCS, языки программирования, среды редактирования, сервера непрерывной интеграции и т.п.) Обычно этот этап проходит положительно, т.к. мы не углубляемся в детали, однако если кандидат говорит, что всю жизнь программировал только под Windows (в то время, как нам нужен Linux разработчик), это уже создает маленькие минусики. То же самое касается про хранение исходников в архивах, использования Far в качестве редактора и другие вещи, которые говорят о том, что человек не интересуется ИТ, и живет в своем маленьком мирке «работа-дом».

Почему это плохо? Несколько причин:

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

Это — мои наблюдения за такими людьми всю свою сознательную жизнь. Еще ни разу не встречал исключения, но предполагаю, что они могут быть. Для себя же я ставлю минусики таким людям.

После разговора про резюме, переключаемся на технологии. Цель данного этапа — выяснить теоретическую базу и набор терминов, используемых кандидатом. Языковой барьер — это весьма серьезная вещь, особенно в международной компании. Если помимо чисто разговорного барьера будет еще и барьер терминологий, это приведет к весьма мучительным последствиям. Я много раз видел, когда менеджер устно дает задание сотруднику, тот кивает головой — да-да, все понял, и через неделю приходит с совершенно неправильным решением, потому что подумал что разговор о чем-то другом (например, вместо CSRF подумал про XSS). Иногда даже переписка исключительно по электронной почте не помогает, просто потому что подразумеваются разные понятия. Например, «stream» — менеджер не уточнил, что имел в виду network stream, а сотрудник подумал, что это надо просто переписать код с использованием C++ I/O streams. Близко, да, но неправильно.

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

В основном, здесь мы либо закругляемся (если видим что у кандидата накопилось слишком много минусов), либо переходим к анализу технического задания. Помимо очевидных вопросов про синтаксические ошибки и как это работает, мы просим кандидата написать более эффективный алгоритм (либо быстрее, либо чтобы потреблял меньше памяти). Иногда мы подводим кандидата к решению, если видим, что у него есть какие-то мысли, но не может сформулировать решение. Вопросы на улучшение эффективности алгоритмов оправдали себя долгой практикой, т.к. они сразу показывают несколько навыков кандидата: знание алгоритмов и структур данных, знание низкоуровневой составляющей (битность, бинарные операции), знание языка программирования и в целом умения решать задачи, причем иногда нестандартным путем. Для примера, даже в Python-е с арифметикой неограниченной точности целочисленных операций, знание низкоуровневых вещей достаточно важно, т.к. Python автоматически переходит с быстрой арифметики в регистрах на неэффективный bigint, и иногда простейшее изменение в разы ускоряет программу. Но это просто пример — если программа быстрая, но неправильная, то она уходит на свалку независимо от ее оптимизаций.

После обсуждения задания (если все прошло хорошо) для кандидата наступает кошмар, т.к. мы выдавливаем из него все возможные знания в интересующей нас области. Это могут быть вопросы и про менеджер памяти в Python-е, и как je_malloc лучше PyMalloc, и про сегментацию памяти и использования sbrk в malloc, javascript-прототипы и closures, css-селекторы, возможности HTML5 EcmaScript Shims, jQuery deferred, CSS3 псевдо-классы (привожу более конкретные примеры с целью минимизировать разночтения) и т.п. Цель этого — выяснить пределы знаний и стрессоустойчивость кандидата. Обычно мы это делаем для кандидатов, которых уже решили принять на работу, но хотим теперь определиться с его позицией и зарплатой (естественно, те, кто проходит испытания с блеском, получают более выгодное предложение).

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

Критерии отбора

И наконец, небольшие выводы — какие критериями мы рассматриваем перед тем, как пригласить на работу:

• Технические навыки (учить никогда не выгодно)
• Социальные навыки (коммуникативный барьер может снизить эффективность работы)
• Опыт работы в похожей сфере (минимальный фактор, но может повлиять на конечное решение)
• Overqualification (не уверен насчет русского термина, но в целом это означает что мы не будет брать профессора на место младшего аналитика)

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

Автор: nuald

Источник