воскресенье, февраля 22, 2009

Как проводить телефонное интервью

В блогах полно статей для кандидатов о том, как проходить интервью. Этот пост наоборот, для тех кто проводит интервью.

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

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

1. Имейте в запасе побольше вопросов. Составьте вопросник по тому языку, платформе, framework, знания которых требуются от кандидата. В моем вопроснике по .Net более сотни вопросов, плюс около полусотни вопросов по RDBMS. Избегайте прямых вопросов о конкретных классах, ответы на которые легко читаются из документации. Например, вместо вопроса о классе XmlDocument спрашивайте о том, как работать с Xml DOM.

2. Начинайте с простых вопросов. С самых элементарных. Например таких "Собеседование. Вопросы на засыпку"). Если человек начинает плавать на простых вопросах вы можете быстро свернуть интервью, сэкономить свое и чужое время. От простых вопросов переходите к более сложным. Если кандидат знает, что такое XmlDocument, попросите его рассказать о том, как в XmlDocument добавить новый элемент.

3. Свободные вопросы - наиболее мощный инструмент при проведении телефонного интервью. Свободный вопрос - это когда вы просите кандидата рассказать все, что он знает по какой-то теме. Например, «Расскажите, что вы знаете о многопоточном программировании на .Net», или «Расскажите, что вы знаете об использовании триггеров в SQL». Старайтесь не перебивать человека, когда он отвечает на такой вопрос, он сам покажет ширину и глубину своих познаний. Можете попросить его уточнить какие либо детали, или направить его рассказ в нужное русло, подсказками.

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

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

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

16 комментариев:

BrigOS комментирует...

Чисто технический момент.

Если кандидат знает, что такое XmlDocument, попросите его рассказать о том, как в XmlDocument добавить новый элемент.

Наверное, ответ на этот вопрос должен дать представление о реальном опыте работы с XmlDom? Или о чем можно узнать вообще из такого вопроса?

BrigOS комментирует...

И еще. Какие вопросы таки относятся к "простым"? Вот лично мне гораздо проще рассказать про механизм активации remoting-объектов, чем разжовывать ответ на "а что такое массив?". Вообще такие "простые" вопросы часто выбивают из колеи - человек готовился, вспоминал что-то, а приходит и ему - "что такое .Net?". Или же это (в смысле перечень вопросов) все же зависит от желаемой позиции?

P.S. Понятия не имею что такое активация remoting-объектов.

Sergey Rozovik комментирует...

> Наверное, ответ на этот вопрос должен дать представление о реальном опыте работы с XmlDom? Или о чем можно узнать вообще из такого вопроса?

Именно так. Если человек работал с XmlDocument, то он знает что этот класс является фабрикой для остальных классов, представляющих Xml DOM в .Net.

Sergey Rozovik комментирует...

> И еще. Какие вопросы таки относятся к "простым"?

Простые - это вопросы, к которым не надо готовиться специально.

build_your_web комментирует...

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

Расскажите как у вас обстоят дела с кадрами. Какие сейчас тенденции - увольняют или набирают?

Sergey Rozovik комментирует...

> Какие сейчас тенденции - увольняют или набирают?

Да как всегда. И увольняют и набирают.

vilner комментирует...

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

Sergey Rozovik комментирует...

to vilner
Где вы увидели, что я пирзываю "гонять разработчика по вопросникам"? Я говорил об обратном. Нужно выявлять общий уровень знаний и опыта. А опросник нужен в основном тому, кто проводит интервью.
На счет бесполезности технических собеседований, позволю с вами не согласиться. Никто, никогда не возьмет на позицию ведущего разработчика человека, просто потому что у него хорошие рекомендации, он приятный собеседник и просто смышленый парень. Я, как работадатель принимая человека на работу, покупаю его знания, опыт и умение решать типовые и нетиповые проблемы в определенной области знаний. И я должен убедиться, что у него все это есть.
Мой личный опыт общения с работадателями из Германии и США подтверждает это - всегда общение начиналось с технического интервью.

vilner комментирует...

Совершенно с Вами согласен, что интервью вещь нужная и беседовать с человеком необходимо. Я против советов 1 и 2 –технических вопросов уровня знания XML-парсеров, наследования, указателей и проч.
Считаю что интервью это процесс подтверждения данных, указанных в бумагах, финальная стадия, до которой кандидату еще дойти надо. Исходные данные- резюме и рекомендации. Серьезно, не представляю, как претенденту на должность ведущего разработчика можно задать вопрос типа «В чем различие между классом и структурой?». Как бы Вы поступили, если б Вам задали такой вопрос при собеседовании?

Sergey Rozovik комментирует...

> Серьезно, не представляю, как претенденту на должность ведущего разработчика можно задать вопрос типа «В чем различие между классом и структурой?». Как бы Вы поступили, если б Вам задали такой вопрос при собеседовании?

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

vilner комментирует...

Интервьюеру с Вами невероятно повезло. Большинство моих коллег после такого поворота просто бы занесли работодателя в черный список.
Как сам бы поступил – не знаю. Последние лет 5 у меня не было ни одного технического вопроса на собеседованиях.

Sergey Rozovik комментирует...

to vilner

Работадателя в черный список? За что? За то, что он спросил на собеседовании про классы и структуры?
Take it easy! :))
Или может ты Лютц Рёдер, или Марк Русинович?

Анонимный комментирует...

от vilner
Как уже писал, мне лично технических тестов не предлагали и у меня черных списков нет :-) Про уровень Руссиновича и других мега-гуру и разговор не ведем :-) ,у них свои требования. Думаю, вообще мало какая фирма эти требования потянет.
Собеседование, не только техническое, играет роль при принятии решения для обеих сторон. Работодатель собеседует и работодателя собеседуют. Они равноправны. И для обеих сторон важно произвести хорошее впечатление друг на друга чтобы подойти к общему знаменателю- подписанию контракта. А здесь ключевое слово- доверие. Задавая вопросы, изначально не соответствующие уровню собеседника, доверие ставится под сомнение. Если нет доверия, зачем продолжать разговор? Что, например, ответить сантехнику, если его попросят рассказать о различиях ванны от унитаза?
Считаю, что информации начиная с пунктов 3 и далее совершенно достаточно чтобы принять решение о взаимном сотрудничестве. Даже сейчас, в кризис, хорошему специалисту гораздо чаще приходится выбирать работодателя, чем наоборот.

Sergey Rozovik комментирует...

to vilner
В общем-то правильно все, с одним но. Это все с точки зрения соискателя. С другой точки зрения все выглядит несколько иначе. Скажем мягко так, - самооценка и позиционирование кандидатов часто не совпадают с уровнем требований предъявляемых к позиции на которую они претендуют. Когда проведешь 30-40 собеседований, поймешь о чем я. Тут действует правило "доверяй но проверяй", потому что за ошибку при подборе кандидата расплачивается не кандидат, а наниматель.

P.S. Я ведь сразу написал - что этот пост, для тех кто проводит интервью :)

vilner комментирует...

Да нет, как раз прекрасно понимаю о чем вы пишете :-)
Года 4 назад мне пришлось нанять человек 30 для одной фирмы. Все собеседования вел сам. Т.к. дело еще было на родине, то было все, в т.ч. дутые резюме с липовым опытом. На Западе, кстати, это уголовщина, поэтому практически не встречается.
По результатам найма могу сказать что те разработчики, которые сыпались на средних технических вопросах, но обладали мотивацией, оказались более эффективными исполнителями, чем те, кто отвечал верно на большинство тех.вопросов, а впоследствии элементарно динамили проекты.

Анонимный комментирует...


>Если кандидат знает, что такое XmlDocument, попросите его рассказать о том, как в XmlDocument добавить новый элемент.

>>Наверное, ответ на этот вопрос должен дать представление о реальном опыте работы с XmlDom? Или о чем можно узнать вообще из такого вопроса?

>>>Именно так. Если человек работал с XmlDocument, то он знает что этот класс является фабрикой для остальных классов, представляющих Xml DOM в .Net..


И о чем это говорит-то? о знаниях MSDN? это ни о чем не говорящий опыт. Подобные знания возможно подчерпнуть за 20 минут изучения гугла. И это НЕ отражает реальных знаний программиста (!не кодера!). Весь msdn знать нереально (да и ну нужно).