Виктория Придатко – известный эксперт в области позитивного управления ИТ-персоналом: её можно встретить на ИТ-конференциях, посвящённых менеджменту. В этом году она является одним из хедлайнеров конференции HR-специалистов в ИТ «Найти Ответ» в Питере. Мы публикуем её доклад с конференции Software Project Management Conference , которая в этом году пройдёт в Минске.
Презентация доклада Видео доклада

Текст доклада

Одна из моих любимых фраз – я её часто повторяю, поскольку это «Капитан Очевидность», –

Первое впечатление второй раз не создашь.

Первое впечатление является очень важным, и часто кандидаты составляют впечатление о компании именно по первому собеседованию. Если оно было негативым – очень трудно потом убедить их в обратном. Зачем вам это надо? Где могут пригодиться эти знания? Чем приятней общение с вами, тем лучше ваша репутация, тем больше денег и больше выбор. Когда вы известны, в хорошем смысле этого слова, когда на вас обращают внимание – претенденты хотят попасть на собеседование именно к вам. И чем больше людей хотят к вам попасть, тем больше компаний делают вам предложения. А чем лучше вы проводите собеседования, тем больше у вас принятых офферов. Часто ПМ-ы говорят так: рекрутеры не могут нам никого найти, поэтому мы не можем создать команду. Когда я прихожу к ним на техническое собеседование и смотрю, как они его проводят, – я понимаю, почему так трудно найти людей, которые согласились бы там собеседоваться. Хорошее собеседование – это шаг к должности менеджера: если вы ещё не менеджер, но хотите стать им, вам надо уметь собеседовать.

• Собеседование – это коммуникация. Об этом мы и поговорим,
• Как это происходит? Я буду рассказывать о своём опыте.
• Ошибки в собеседованиях.
• Признаки классного интервью.
• Кто\что может помочь?

Интервью с HR-ом

Я не могу говорить за Россию, но в Украине сейчас в HR-ы берут очень симпатичных, не побоюсь этого слова – сексуальных девушек, которые всячески заманивают кандидатов. Как правило, организуются два интервью: с HR-ом и техническое. Часто кандидат на первом интервью расслабляется, а второе интервью очень сильно отличается от первого – собеседовать приходит технически сильный специалист. Проблема еще и в том, что очень часто такие специалисты хотят не сколько провести интервью, сколько показать себя. К сожалению, в компаниях этот процесс не всегда построен, и технических специалистов не спрашивают, когда им удобнее проводить интервью, – их просто вырывают из проекта. Как вы знаете, программисты работают в потоке, и им потом очень трудно в него вернуться... к сожалению, не все компании это учитывают. Соответственно, ощущения технического интервьюера следующие:

• Чёрт, опять собеседование!
• Ну, рассказывай что знаешь...
• Ага, так этого ты не знаешь, бугага – опять рекрутеры пригласили тупняков.
• А я вот знаю это и это, поэтому – я ПЕРЕЦ!

У меня как-то был такой опыт: мы очень долго искали джависта в одну компанию, и вот рекрутеры нашли классного джависта, пригласили на интервью, всё было супер, он пришёл во второй раз, и его собеседовал другой джавист, которому надо было самоутвердиться. В итоге он сказал: «Ну что, будем… меряться или поговорим?» Это впечатление просто убило кандидата, и впечатление сложилось соответствующее. Самое плохое, что эта информация потом транслируется дальше.
Почему так делать нельзя? Потому что по собеседованию люди часто составляют мнение о всей компании. Как известно – люди приходят в компанию, а уходят от менеджера. Допустим, во время интервью вы померялись… и ушли с ощущением, что вы классный, а кандидат ушёл с ощущением, что он ужасен, и что он будет рассказывать людям?.. Чем больше у вас таких собеседований, тем, к сожалению, меньше у вас кандидатов. Основные ошибки на техническом собеседовании:

• Понты;
• Умничанье и болтовня – когда люди компетенты в какой-то теме, они склонны эту тему развивать, и в результате интервью превращается в рассказ интервьюирующего о его любимом вопросе. Хочешь рассказать о себе – вали на конференцию и рассказывай, какая проблема?
• Равнодушие – тоже часто встречающийся паттерн, когда технические интервьюверы сидят устало, вся их поза свидетельствует о том, что им страшно скучно и вообще непонятно, что они здесь делают… Опять же, это очень сильно зависит от того, как это организованно в компаниях. Я знаю компании, где этот процесс организован классно, где людям, проводящим техническое интервью, за это еще и платят...
• Стресс-собеседование – такой вид панельного интервью, когда пять собеседующих тебя по очереди «мочит»… Хотя я видела интервью, когда интервьюировали пять человек и при этом была вполне дружественная обстановка.
• Опоздание . Давайте уважительно относиться к кандидатам: мы часто вырываем людей из проекта их компании, мы забираем их рабочее время и при этом сами позволяем себе опаздывать… Моя позиция такая: если человек приходит к вам в обеденный перерыв – накормите его обедом. Для компании это копейки – предложите ему сэндвич, а не только кофе или чай! Или, допустим, кандидат пришёл вечером – если рабочий день заканчивается в 18:00, а вы пригласили его на 19:00, то понятно, что он пришел к вам голодный. Ребята! Простой сэндвич творит чудеса! Вы не поверите, как сильно у людей меняется впечатление о вас.
• Отсутствие фидбэка . Итак, мы провели техническое интервью, а дальше мы считаем, что фидбэк – это ответственность рекрутера (я, кстати, тоже так считаю). Но фидбэк по техническому интервью должен давать тот человек, который его проводил. Когда мы звоним человеку – неважно, взяли мы его или нет – мы можем сказать ему, что нам понравилось, а что, на наш взгляд, можно улучшить. Чувство благодарности, которое возникает у людей после того, как вы им это рассказали, – это просто ни с чем не сравнимое ощущение. Они будут об этом помнить, и вы потом еще не раз удивитесь, в какие моменты это будет всплывать. Ведь кандидата всегда есть за что похвалить, и нет таких людей, которые вообще ни в чем не разбираются, – иначе мы не приглашали бы этого человека на собеседование. При этом очень важно сказать, что было хорошо, а что можно улучшить, и что плохо. У HR-ов есть такое выражение «зона развития»: не то чтобы у тебя всё плохо, просто у тебя в какой-то области наметилась «зона развития».

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

• Не плюй в колодец . Иногда случается, что человек, которого вы собеседовали, потом может собеседовать вас. У меня был такой случай в жизни – у меня достаточно много знакомых, и, допустим, наша компания отсобеседовала кандидата не очень хорошо, а потом ты сам попадаешь к нему на собеседование, и он говорит, ага, сейчас я тебя отсобеседую.
• Be nice or leave … Как я уже говорила, очень важно оставить у людей положительное впечатление. Для технических специалистов важна компетентность человека, который проводит собеседование, но его «хорошесть» (в хорошем смысле этого слова – его уважительное отношение, его «принятие другого человека») – важна не менее, чем техническая компетентность, а иногда даже больше.
• Тот человек, которого вы собеседуете, может оказаться вашим руководителем или рекомендателем в будущем. Рынок непредсказуем – люди растут по-разному, переходят в разные компании и, соответсвенно, все друг друга знают.

Как лучше? Лучше общаться с кандидатом как с потенциальным коллегой и приятным человеком. Представьте, что человек попал к вам в команду: как бы вы общались с уже нанятым сотрудником? Неважно, возьмете вы человека или нет, – помните, что вы можете пересекаться с этим человеком, и всякие резкие суждения могут быть неуместны. Спрашивайте его из желания узнать что-то новое, а не из чувства превосходства. Все люди знают что-то, чего не знаем мы, и мы не можем знать всё. Потому мы должны проводить собеседование с искренним интересом и действительно слушать человека. А понять, что мы на самом деле не слушаем, очень легко – это видно по нашим глазам, по нашей позе. Даже если люди не владеют языком тела – они всё равно понимают, слушают их или нет. Спросите человека о том, что для него важно. Благодаря этому вы многое узнаете от самого человека: что важно для него и что из этого может быть важно для вашего проекта. Так вы поймёте, как его лучше мотивировать и как с ним лучше обращаться. Спросите, с какими людьми ему нравится работать? Это очень важный вопрос: если вы понимаете, что у вас на проекте люди совсем не такие, то это для вас тоже будет индикатором. Я всегда за честное интервью: я за то чтобы говорить правду. Вы можете рассказать человеку про проект, про людей, чем они отличаются от его ожиданий – и пускай он выбирает, подходит ему это или нет. Берите людей, которые обожают то, что они делают. В ИТ очень любят «сениоров», по ним сходят с ума, их перекупают. Но некоторые «сениоры» не любят то, что они делают. Да они «сениоры», они ценятся на рынке, они получают хорошие деньги, но они терпеть не могут то, что они делают. Порой они приходят, «звездятся», уходят и таким образом часто перемещаются по компаниям. Я знаю людей, которые не так уж мегакомпетентны на данный момент, но за счёт того, что они заинтересованы и обожают то, что они делают, – очень быстро могут стать «сениорами». Совпадение по ценностям и умению взаимодействовать могут стать более важными, чем знания. Навыки и знания – это те вещи, которые можно получить. Если вы не совпадаете по ценностям – то это проблема на более глубоком уровне. Конфликт на ценностном уровне может решаться, но решается он очень нелегко… Сначала надо узнать мотивацию кандидата, а потом продавать бенефиты компании. В каждой компании по-разному, но часто техническое и HR интервью проходят вместе. Что обычно делает HR? Обычно он «продаёт» компанию, не спрашивая, что интересно кандидату. А ведь все аутсорсинговые, а то и продуктовые компании примерно равны по уровню компенсаций. Но не всем, например, важна страховка. Бывает такое, что человеку рассказывают про страховку, а он спрашивает: «А у вас в команде есть люди, которые играют в баскетбол?» – он ищет есть ли у него общие интересы с командой. Выслушайте, что человеку интересно, и продавайте ему то, что ему интересно. Обязательно узнайте, чем увлекаются люди у вас в команде, и спросите об увлечениях кандидата. Когда я просматриваю резюме – я обращаю внимание на то, чем увлекается кандидат, расспрашиваю его об этом, а потом рассказываю об этом в команде, и тогда у людей в команде формируется о нем совершенно другое впечатление. Кстати, заранее расскажите команде о новом человеке – и я за то, чтобы интервью проходило с участием членов команды. Когда спрашиваете у кандидата о достижениях – уточните, кто может это подтвердить. Покажите кандидату офис, его рабочее место. Этот момент часто упускают. Человека обычно сразу ведут в переговорку, там с ним общаются битый час, а потом выводят через «ресепшн». Я не считаю, что показать офис, показать проект, в котором вы участвуете, – значит раскрыть коммерческую тайну. Для меня очень важно атмосфера в компании, куда я прихожу работать. Для меня важно зайти в комнату и почувствовать, «как там». Приведите человека в проект, покажите, где у вас кто сидит, – даже если он у вас не будет работать, он может порекомендовать других людей. Ваш внешний имидж должен соответствовать внутреннему состоянию, состоянию внутри компании. Покажите человеку то, что вам в компании самим нравится, то что вызывает у вас эмоции, – люди откликаются на эмоции, и, когда они видят, что вам это нравится, – им тоже это нравится. Проводите собеседование с юмором и энергией, УГ много в компаниях-конкурентах:). Если есть возможность провести собеседование с юмором – это создает положительное ощущение у кандидатов. Люди постоянно сравнивают: в этой компании было хорошее собеседование, в той – не очень, и если ваше собеседование будет отличаться от других, это может дать вам бонусы.

Вы уже разместили на объявление на работных сайтах с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать.

У Вас есть продукт, устоявшаяся команда и финансирование. Вы (команда) хорошо работали, и руководство готово заплатить еще денег чтобы нанять человека, чтобы, соответственно, ускорить разработку, повысить качество и иметь возможность тратить ресурсы на технологическое развитие продукта. Вы уже разместили на hh объявление с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать. Знакомая ситуация? Тогда добро пожаловать под кат.

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

Для начала заметим, что крайне вредно нанимать человека под сиюминутную потребность. Скажем, сейчас у вас слегка «тормозит» разработка серверной части. Значит ли это что надо нанять server-side программиста? Вообще-то нет. Если у вас достаточно активная разработка, то приоритет разных кусков будет неизбежно меняться. В этом смысле глупо нанимать человека под задачу на ближайший месяц. Ведь месяц пройдет, а человек у Вас останется. И если в этом месяце Вы залатаете дыру в server-side разработке, то в следующем выяснится что server-side пишется быстрее чем клепается интерфейс. И что, в следующем месяце надо нанимать UI-программиста? Или уволить «слабое звено» в server-side? Нет, тут стоит подойти по-другому. Посмотрите, чем Вы занимались раньше в разработке продукта. Расспросите продажи, инвесторов или кто там определяет цели для разработки, и постарайтесь построить картину того что ждет вас, скажем, на год вперед. А теперь представьте, какой человек помог бы Вам работать в прошлом и будущем эффективнее. Надеюсь, Вам представился не один человек. Скорее всего окажется, что можно и тут укрепить команду, и здесь. А если где-то окажется слишком крепко (и соответственно где-то - слишком тонко), то кто-то из существующей команды возможно согласится «переключить» род деятельности.

Итак, Вы набросали несколько портретов «идеальных» кандидатов. Настала пора провести техническое собеседование. Кстати, надеюсь в Вашей компании именно техническое собеседование влияет на решение о найме сотрудников? Часто говорят о компании как о «семье» или о «коллективе где приятно проводить время». Так вот, компания это все таки не семья. И не друзья с которыми вы ходите в боулинг. Конечно, если человек болен клептоманией или проказой то брать его на работу опасно, даже если он лучше всех прошел техническое собеседование. Но не стоит слишком зацикливаться на личных качествах. В принципе, до или после технического собеседования необходимо выяснить, не выкинет ли человек какой-то фокус, и в этом смысле такое «не техническое» собеседование будет иметь роль «порога» - тот кто его не пройдет в компании точно работать не будет, а если пройдет - то не имеет значения будет ли он «душой компании» или просто добросовестным работником. Но это и все, собственно, все остальные решения должны определяться именно техническим собеседованием. Если в вашей компании HR донимают кандидатов вопросами об их карьерных устремлениях и «кем они видят себя через 10 лет» или «почему компания должна нанять вас», то вам еще рано искать технических специалистов. Для начала вам надо найти нового HR.

Но что же спросить на техническом собеседовании? Составить тест? Выяснить что человек делал на прошлом месте работы? Задать каверзный вопрос? Дать задачку с braingames.ru?
Давайте рассмотрим эти варианты по порядку.

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

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

Чем Вы занимались на прошлой работе?
- Ну там была сложная система моделирующая систему городских коммуникаций с поиском оптимальных маршрутов и (…)
- Что такое алгоритм Дейкстры?
- Эмм, да, и что-то такое я слышал.

Итого - что мы узнали? Да ничего. Какой-то сложный проект. Толком не понятно что за проект, что именно делал этот сотрудник, что он в итоге научился делать хорошо. Мы промотали 5 минут на то, чтобы не выяснить о человеке ничего. Конечно, можно потратить полчаса и разобрать все по полочкам. Но есть два «но».
Во-первых, цените время. Если на каждого кандидата будете тратить по 4 часа, то вы можете просто «не дойти» до действительно стоящего. Вообще, на мой взгляд, собеседование стоит жестко ограничить временными рамками, скажем одним часом. И постараться вытрясти за этот час из человека все, что Вам необходимо для принятия решения.
Во-вторых, не зацикливайтесь на том, кем человек был. Попробуйте оценить, кем бы он мог стать в вашей компании. Ваш кандидат говорит, что на прошлой работе сделал за неделю модуль, который Вы делали месяц? Так может на прошлой работе крутые бизнес процессы и гора готового кода, а у вас он бы делал этот модуль ровно столько же, сколько и Вы? Или Вам показалось, что на прошлой работе кандидат не сделал ничего сколько-нибудь примечательного? Очень может быть. Но может это талантливый человек, прозябавший в третьесортных «рогах и копытах», а у Вас раскроется весь его потенциал! Поверьте, во многих ситуациях за такого человека стоит побороться даже больше, чем за состоявшегося специалиста.

Стоит ли спросить что-то каверзное? Скажем вчера Вы прочитали на хабре, что, оказывается, хеш-код в джаве это не адрес (как Вы всегда считали), а случайное число, и Вам интересно, знает ли это кандидат. Или Вы на прошлой неделе ковырялись в никсах и выяснили, что "[" это не часть bash-скрипта как языка, а обычная программа с именем "[". Полезно ли будет выяснить, известно ли это кандидату?
Тут стоит опять же попробовать проиграть вопрос и варианты ответа.
Поиграйте по ролям.

- Ну это адрес объекта

И второй вариант:

Что такое Object.hashCode()?
- Да там генератор случайный чисел, вот он и возвращает.

Вы потратили 3 минуты на этот вопрос. Как вы сравните первого и второго кандидата? Можно ли сказать, что один из них лучше другого? Может быть второй листал на досуге grepcode. Или читал хабр вместо работы. А может и не вместо. Но вам-то это что-то говорит?

Не то чтобы не имело значения знает или нет человек тонкости реализации. Напротив - я считаю что очень важно знать мелочи. Человек, который знает ассемблер, для меня ценнее того, кто его не знает, даже когда я ищу джава разработчика. Но, к сожалению, мелочей так много, что прямой вопрос «А знаете ли вы что» почти никогда не несет смысла. А спросить о сотни вещей мы не можем, у нас ведь ограничено время.

Так что же спросить?

Мне кажется, лучше всего вести беседу, в ключе того чем Вы обычно занимаетесь и смотреть, как кандидат решает задачки которые Вы часто решаете.
Скажем в Вашем приложении есть UI-логика и серверный код. Спросите у кандидата, что, как ему кажется, интереснее.
Серверный код? Отлично. Давайте представим какой-нибудь типичный кусок кода в Вашей программе. Нам интересно, какие вопросы возникают у кандидата, и как увязывает он теоретические знания с практическими потребностями.
Скажем такая задачка:

Есть фрагмент кода

void x(List a)

…Some processing

Вопрос кандидату - предположим в этом коде нам надо перед «Some processing» отсортировать список в алфавитном порядке. Что будете делать? Кстати да, тут же можно сказать кандидату про Collections.sort - мы же не «словарный запас» проверяем.
Положим наш кандидат написал что-то типа

void x(List a)

List b = new ArrayList(a);

Collections.sort(b);

…Some processing with b

(надеюсь наш кандидат именно так решил эту задачу а не начал сортировать a).

Однако решение задачи тут не главное. Главное дискуссия.
Почему он создал новый список а не использовал старый? Всегда ли это правильно?
Почему использовал ArrayList а не что-то еще? А знает ли он что еще есть?

Самое интересное что дискуссия тут может быть почти бесконечная. Кандидат скажет что ArrayList лучше тем что он random access, а Вы скажите что sort все равно копирует перед сортировкой данные в массив, а потом возвращает обратно. Стал ли ArrayList лучше теперь, по мнений кандидата? Как, уже нет? Или все равно лучше?

Беседа с кандидатом должна раскрывать образ его мыслей. Посмотрите как много деталей он знает. Как реагирует на что-то новое? А самое главное - может ли правильно распорядится информацией, которую Вы ему дадите? Ведь абстрактное «знание всего» обычно не особенно важно, в конце-концов рядом есть коллеги и проблемный вопрос часто можно обсудить. Коллеги могут подсказать, но писать код вместо нового сотрудника не будут, так попробуйте понять, сможет ли он, выслушав совет, написать программу лучше?

Или скажем другой пример.

Не спрашивайте «что такое garbage collector». Не спрашивайте «сколько там поколений». Какая разница сколько. Какая разница может или нет человек рассказать как устроен gc - для вашей работы может быть важно только то, сможет ли человек исправить performance проблему если таковая возникнет, а не может ли он поведать душещипательную историю про сборку поколениями или там про concurrent mark sweep gc.
Я не говорю, что кто-то может решать сколько-нибудь интересные проблемы с GC не зная, как он работает. Один раз, конечно, может и повезет. Но на практике знание чрезвычайно важно. Проблема в другом - не каждый, кто может рассказать как что-то работает, может исправить проблему с этим чем-то. И, вообще говоря, интуиция, общая техническая подкованность часто для решения задачи важнее прочитанного где-то описания алгоритма.
Например, для gc хорошо будет привести опять же какую-нибудь практическую задачку.
Скажем, «вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?».

Увеличу хип

А станет ли быстрее? И самое интересное, а разве не стоит перед ответом на этот вопрос спросить, а что такое для меня «быстрее»? Посмотрите, понимает ли кандидат разницу между throughput и latency. Не спрашивайте что это и в чем разница. Если кандидату при вышеописанной постановке задачи не приходит в голову задаться такими банальными вопросами, значит и на практике у него этих вопросов не возникнет. Однако не стоит забывать, что мы ведем беседу. Если кандидат прыгнул с места в карьер, остановите его, расскажите про разные характеристики производительности. Кандидат никогда про них не слышал, но сходу сообразил что рост хипа возможно улучшит одно, но точно ухудшит другое? Ну так это же замечательно!

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

• Подбор и отбор, Оценка, Рынок труда, Адаптация

Собеседование находится на верхних позициях в рейтинге самых больших страхов большинства людей, наряду с публичными выступлениями. Вы не только выступаете перед кем-то, но вас еще и постоянно оценивают все это время... бррр!

Конечно, мы далеки от того, чтобы пытаться разобраться с вашими психологическими барьерами и преодолеть их, но совершенно точно лучше всего было бы рассматривать собеседования как шанс показать все те классные вещи, которые вы создали, и те интересные новые навыки, которые вы освоили. Лучшие собеседования - это полные энтузиазма разговоры с техническим уклоном.

Первым шагом перед всем этим будет подготовка. Вы наверняка захотите обдумать возможные вопросы (и наиболее распространенные на них ответы, которые подчеркнут вашу гениальость), а также изучить компанию-работодателя. Ваши знания о компании помогут вам преподнести себя так, что это будет соответствовать их потребностям, а также позволят вам задавать умные вопросы об их продуктах и технологиях, когда придет время. Еще раз, обратитесь к статье Happy Bear за практическими советами.

В чем заключается весь этот процесс

Просто небольшой обзор процесса, через который проходит средняя техническая компания при найме разработчиков:

1. Предварительное собеседование по телефону (Phone Screen)
2. Техническое собеседование
3. Тестовое техническое задание
4. Последующие собеседования, чтобы убедиться, что вы подходите (Fit Interviews)
5. Предложение работы (Job Offer)
6. Обсуждение условий предложения (Offer Negotiation)
7. Принятие предложения (Offer Acceptance)

Предварительное собеседование по телефону

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

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

ФИНАЛЬНОЕ ПРИМЕЧАНИЕ - это не универсальный метод и многие компании пропускают его, чтобы сразу же нырнуть в глубины технического собеседования, поэтому вам нужно приготовиться просто на всякий случай. Ссылка ниже на Coding Horror самая иллюстративная для этого случая.

• Добейтесь совершенства в телефонных собеседованиях от Monster
• 7 шагов на пути к достижению вершин мастерства телефонного собеседования

Техническое собеседование

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

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

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

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

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

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

Ссылки

• Разбиремся с собеседованием для программистов это ОБЯЗАТЕЛЬНЫЙ К ПРОЧТЕНИЮ МАТЕРИАЛ , который станет вашим лучшим другом. Он всесторонне рассматривает все виды задач, с которыми вы столкнетесь на собеседовании. Он выходит за рамки того, что мы уже изучили в этом курсе и затрагивает такие вещи, которые хорошо было бы знать, потому что скорей всего вы с ними встретитесь. Потратьте время на то, чтобы познакомиться с как можно большим количеством материала.
• Interviewing.io дает вам шанс попрактиковать анонимно и онлайн техническое собеседование.
• Как получить высшую оценку на техническом собеседовании
• Как выделиться на следующем собеседовани на должность веб-разработчика
• Прочитайте 40 ключевых концептов информатики, объясненных доступным языком
• Руководство для развития технических навыков от Google (для продвинутых)

Тестовые задачи на программирование:

• 8 королев - это классическая задача.
• Программирование на собеседоваии: знай стандартные библиотеки может оказаться перебором для начинающего, но никогда не повредит, если вы найдете на него время.
• На Project Euler вы найдете более обобщенные и сложные задачи, которые нужно эффективно решить (они могут потребовать большого объема вычислений).
• На Coding Bat опубликованы практические вопросы для Java и Python.

Обучение алгоритмам:

• Курс по алгоритмам от Udacity (несинхронизированны)
• Курс по алгоритмам от Coursera (частично-синхронизированный)

Архитектура:

Техническое тестовое задание

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

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

Финальное собеседование ("Fit")

Последним шагом перед принятием решением обычно является знакомство с командой и офисами в течение нескольких часов. Возможно, вас проверят технически, но основная цель - это удостовериться, что вы будете хорошим коллегой. Если какой-то другой член команды скажет, что вы не сработаетесь, вас скорей всего не возьмут. Совет? Не нужно быть странным или неловким, даже если вы дома:)

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

Немного о заработной плате

Не. Озвучивайте. Ваши. Зарплатные. Ожидания.

Вас всегда спросят "сколько вы хотели бы получать?" Ваш ответ? "Я хотел бы получать среднерыночную оплату" (если только вы не настолько наглы, чтобы просить выше рыночной. Посмотрим, как это у вас получится). Вы ничего не выиграете, назвав уровень желаемой зарплаты. Если она окажется ниже, чем они хотели вам предложить, они просто снизят этот уровень. А если выше, то они просто прервут весь процесс, решив, что вы слишком дороги для них.

Как только вы получите предложение, вы можете проверить, насколько оно соответствует среднему рыночному уровню оплаты, опросив нескольких человек (надеемся, что у вас уже есть несколько знакомых, которых можно спросить) или сходив на сайт Glassdoor (просто помните, что вы - начинающий, а значит вы не будете получать "среднюю" зарплату). Самое главное, это не навредить самому себе, когда вас спрашивают.

Сирадж Равал, разработчик, писатель и видеоблоггер, рассказывает как успешно пройти любое техническое собеседование в 5 шагов.

Я проходил через этот процесс дюжины раз в различных IT-компаниях, на моей памяти огромное число как отказов, так и предложений. И вот какие уроки я из этого извлек. Собеседование требует труда: не верьте тем, кто утверждает, что это должно быть легко. Это не так. Люди говорят только о своих успехах и никогда - о провалах.

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

Шаг 1. План подготовки

Учитесь. Еще до того, как вас посетит светлая мысль попытаться устроиться куда-нибудь работать, вы должны сконцентрироваться на прокачке своих технических навыков.

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

Единственный способ научиться этому - практика. Все мои друзья, работающие в крутых компаниях, очень много занимаются. Смысл здесь не в том, чтобы иметь выдающийся интеллект, а в том, чтобы усердно и продуманно трудиться.

Возникает вопрос, что именно надо практиковать? У вас не будут проверять знание синтаксиса какого-либо языка. При желании можно изучить основы синтаксиса Ruby за одну ночь. Но на что ночи не хватит, так это на основы фундаментальной информатики. А ведь на собеседовании у вас будут проверять именно знания структур данных и алгоритмов.

Начните с прохождения двух курсов:
введение в структуры данных (My Code School)
введение в алгоритмы (MIT Open Courseware)
Оба они находятся в открытом доступе и идеально подходят для того, чтобы получить базовые знания по этим разделам.

После этого можно закрепить полученные знания на HackerRank и HackerEarth . Эти ресурсы содержат огромное количество задач для оттачивания навыков программирования.

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

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

Шаг 2. Найдите компании, которые вас интересуют

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

Отслеживание процесса подготовки и прохождения собеседований в компаниях может быть довольно стрессовым делом, но пытайтесь оставаться организованным. Составьте список интересных вам компаний и отмечайте, на какой стадии находятся ваши отношения с каждой из них. Неплохими ресурсами для этого могут служить angel.co и Hacker News .

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

Шаг 3. Составьте портфолио

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

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

GitHub - прекрасное место не только для хранения вашего кода, но и как еще одно портфолио, которое может сослужить вам хорошую службу.

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

Шаг 4. Получите приглашение на собеседование

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

Настало время перейти к…

Шагу 5. Пройдите собеседование

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

Решая технические задачи, не бойтесь рассуждать вслух. Помните, что от вас хотят именно этого: правильный ответ не столь важен, как правильный ход ваших мыслей. Когда соискатель выдает первое решение, рекрутер часто просит его найти более эффективные варианты. Здесь в игру должны вступить ваши знания информатики.

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

Заключение

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

11 июля 2011 в 02:36

• IT-компании

Я уже достаточно давно провожу технические интервью с кандидатами на позицию Software engineer и на моем счету их имеется несколько десятков. Сегодня я попробую сформулировать основные моменты, которые лично мне, как интервьюеру, кажутся довольно важными.

Советы довольно очевидные (хотя, как показывает практика, бывают и те, кто не знает этих очевидных вещей) и субъективные.

1. Отвечая на общие вопросы помните, что интервьюер может ничего не знать о том, о чем вы говорите .
Бывает, что в самом начале интервью интервьюер задает общие вопросы - например «Расскажите о проекте Х, над котором вы работали в У» (список проектов берется из резюме) или «Расскажите про самую любимую технологию» или еще что-нибудь такое. Отвечая на этот вопрос очень важно помнить, что вы рассказываете о проекте не себе, а интервьюеру - и ваша задача, чтобы интервьюер вас понял.
Не надо предполагать, что интервьюер очень умный и все знает - он, вероятно, действительно умный, но точно знает далеко не все. И то, что для вас может быть очевидным потому, что вы этим занимались пару лет кряду, для интервьюера может быть совершенно новой областью. И поэтому не стесняйтесь начать с самых основ и время от времени интересуйтесь, понимает ли вас интервьюер.

2. Не гуглите во время интервью.
Бывает такое, что интервьюер задает вопрос, ответ на который вы смутно помните, и если бы только одним глазком взглянуть в википедию… Так вот - не надо этого делать. Стук клавиш обычно довольно неплохо слышен через телефон и ответ, который зачитывается из википедии без особого понимания - тоже довольно несложно отличить. Стоит ли говорить, какое впечатление оставляет у интервьюера такой кандидат?

3. Не врите в резюме.
Есть вещи, которые проверить относительно легко - знание какой-то технологии, например. И вещи, которые проверить сложно - например, если кандидат написал, что он в top 100 на topcoder (это такой сайт, где проводятся соревнования по программированию). Лично я этого на уровне «А под каким ником вы там числитесь?» никогда не проверяю, но от кандидата, который в top 100 на топкодере я жду, что простые вещи он напишет не приходя в сознание (я уже интервьюировала олимпиадников - и по моему опыту так и происходит). И если вдруг окажется, что кандидат пишет код медленно, с кучей ошибок - то это, скорее всего, значит, что либо он очень плохо себя чувствует, либо в резюме он указал неверную информацию.
Конечно, в компетенцию интервьюера не входит оценивать состояние кандидата, но я обязательно упомяну об этом несоответствии в своем отзыве.

4. Не пытайтесь «уболтать» интервьюера.
Если интервьюер задал вопрос - например, «Какая сложность у сортировки пузырьком?» - а вы не помните, то ли это O(N^2), то ли O(N), то ли O(NlogN), то ни в коем случае не надо маскировать свое незнание под кучей фраз, которые вы надеетесь что интервьюер примет за правильный ответ. Интервьюер очень внимательно вас слушает и замечает все попытки невзначай увести его от вопроса, на который кандидат не знает ответа. Лучше просто признаться, что вы точно не помните и подумать вслух - скорее всего вы придете к правильному ответу и так.

5. Говорите и объясняйте. Но не слишком много.
Бывают две крайности - кандидат, который молчит и почти ничего не говорит и даже на вопрос вроде «Расскажите мне, что вы думаете о Х, какие у Х достоинства и недостатки» умудряется ответить максимум одним предложением. И кандидат, который говорит и объясняет все вплоть до последней запятой - «Вот тут я ставлю запятую, потому, что таков синтаксис языка». И первый, и второй тип кандидатов очень сложно интервьюировать - из одних приходится тянуть ответы клещами, а других постоянно обрывать на полуслове.
Объяснений должно быть в самый раз - чтобы интервьюер понял суть, но при этом не чувствовал, что кандидат постоянно хочет сорваться в объяснение тривиальных основ.

6. Тестируйте код сами.
Во время интервью вы написали какой-то код, который по вашему мнению правильный. В этот момент важно этот код протестировать не дожидаясь, пока интервьюер вам скажет «А теперь давайте протестируем код на простом примере 123». Во время тестирования очень важно проверить так называемые corner cases - например, null, пустые строки и массивы, отрицательные числа, ноль - и еще более важно удостовериться, что код действительно работает на простых примерах. Потому что кандидат, который тестирует код, но при этом во время тестирования не замечает очень грубую ошибку, обычно не производит самого лучшего впечатления.

7. Не пытайтесь угодить интервьюеру.
В фильме «Bad teacher» есть один момент - один из главных героев спрашивает другого об акулах:
1: Что вы думаете об акулах?
2: О, акулы это такие ужасные рыбы, я слышал что они едят людей…
1: Но некоторые из них никого не едят, и очень даже милые…
2: О да, это ужасно, что люди истребляют акул, ведь акулы - это вымирающий вид и Бог создал их такими. Они - прекрасные создания…
1: Но ведь они едят людей…
2: Да, да, это ужасно, целые семьи бывают разрушены из-за акул…

Я не помню точно, но суть примерно такая. Так вот, не надо вести «разговор об акулах» с интервьюером. Интервьюер задает вопрос, чтобы узнать, что кандидат думает о том или ином аспекте, а не чтобы услышать, что кандидат с ним в любом случае согласен.

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

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