Искусство проведения интервью
Joel on Software Джоэл о программном обеспечении | |||||
Автор: Джоэл Сполски Переводчик: Михаил Цукерман Редактор: Семён Хавкин 18.10.2002 Для нашей компании (Fog Creek Software) проблема найма подходящих работников является первостепенной. Людей, работающих в области программного обеспечения, можно разделить на три группы. Первая — это , не обладающая даже основными навыками программирования. Ее представителей легко распознать и отсеять, просто посмотрев резюме и задав пару простых вопросов. Ко второй, диаметрально противоположной группе относятся — люди, способные просто так, ради интереса, за одни выходные написать на ассемблере компилятор с языка Lisp для Palm Pilot'а. А между этими двумя крайностями находится большое количество середнячков, возможно, на что-то способных. Проблема, стоящая перед нами, как раз и заключается в том, чтобы отличить суперзвезд от посредственностей, поскольку Fog Creek Software нанимает на работу только суперзвезд. Каким образом нам это удается? Главное и единственное требование, предъявляемое к кандидату на работу в нашей компании: он должен знать свое дело и уметь его делать. И больше ничего. Это все, что нам нужно. Запомните и повторяйте ежедневно перед сном. Нас интересуют люди, обладающие способностями, а не конкретным набором знаний. Любые знания все равно технически устареют через пару лет, поэтому лучше нанимать людей, способных освоить новую технологию, а не просто кого-то, кто знает SQL. Знать свое дело — понятие, которому трудно дать точное определение. Ниже мы увидим, как с помощью нескольких простых вопросов можно распознать знающего, умного кандидата. Умение делать дело — также крайне важное качество. Знающие, но не делающие работники — умные бездельники — обычно просиживают ученую степень в больших компаниях, где их никто не слушает из-за их полной непрактичности. Они скорее станут думать об академическом подходе к проблеме, а не о выпуске продукта в срок. Их легко узнать по склонности к поиску теоретического сходства между двумя совершенно разными концепциями. Например, они могут заявить: «Таблицы — это, в сущности, частный случай языка программирования», а затем исчезнуть на неделю и написать потрясающую статью о теоретических атрибутах вычислительной лингвистики электронных таблиц как языка программирования. Круто, но бесполезно. Наконец, попадаются и деятельные дураки. Они не задумываясь делают глупости, которые кому-то потом приходится разгребать. Это превращает их в обузу для компании, так как они не только сами пользы не приносят, но и у других время отнимают. Такие работники любят копировать большие куски кода вместо создания подпрограмм, поскольку это хоть и коряво, но работает. Важнейшее правило интервьюирования гласит: Примите решение. Закончив интервью, вы должны принять четкое решение. Возможных вариантов только два: нанимать или не нанимать. Повернитесь к компьютеру и отправьте сообщение рекрутеру. Тема сообщения — имя кандидата. Первая строка — нанимать или не нанимать. После этого обоснуйте свое решение в двух абзацах. Других вариантов быть не может. Никогда не говорите: «Нанимать, но не в мою группу». Это невежливо, так как предполагает, что кандидат, недостаточно умный для работы с вами, подойдет этим бездарям из другой группы. Вместо «Нанимать, но не в мою группу» напишите, не задумываясь, «не нанимать», и все будет в порядке. Даже если вы столкнулись с прекрасным специалистом в одной конкретной области, но для вас не подходящим — это значит «не нанимать». Обстоятельства меняются настолько часто, что ценность представляют люди, способные работать везде. Если вам попадется узкий специалист, просто-таки блестяще знающий SQL, но не способный обучиться чему-то другому, не нанимайте его. У таких людей в нашей фирме нет будущего. Никогда не говорите «может быть» или «не уверен». Не уверены — не нанимайте. Это проще, чем кажется. Не уверены? Скажите нет. И ещё, если вы занимаете выжидательную позицию, это тоже значит «не нанимать». Никогда не говорите: «Хорошо, я думаю, мы его возьмем, хотя есть некоторые сомнения насчет...». Это тоже «не берем». В процессе интервьюирования важно помнить следующее: лучше отказаться от хорошего кандидата, чем нанять плохого. Плохой работник будет стоить кучу денег, усилий и времени, которое другие люди потратят, исправляя его ошибки. В случае любых сомнений лучше сказать «не берем». Проводя интервью, не думайте, что если вы откажете слишком многим, наша фирма не найдет себе работников. Это не ваша проблема. Это проблема рекрутеров и отдела кадров, это проблема Джоэля, но никак не ваша. Спросите себя, что хуже — если мы станем большой конторой с кучей дураков или останемся маленькой, но высококачественной фирмой? Конечно, важно искать хороших сотрудников, и все должны рассматривать это как часть своей работы. Но в процессе интервью лучше думать, что у нас есть куча классных кандидатов. Никогда не снижайте стандартов, как бы ни сложно было найти хороших работников. Но как же принять это самое решение? Нужно постоянно спрашивать себя во время интервью: А дело он знает? Он способен нормально делать дело? Чтобы получить ответ, нужно задавать правильные вопросы. Вот вам, смеха ради, отвратительный вопрос для интервью: «В чем разница между varchar и varchar2 в Oracle 8i?» Задавать такой вопрос совершенно бессмыссленно: между людьми, знающими эту бесполезную мелочь, и людьми, действительно нужными нашей компании, нет ни малейшей корреляции. Кого волнует, в чем эта разница? Ответ ищется в Интернете за 15 секунд! Правда, есть вопросы и похуже; к ним я еще вернусь. Теперь перейдем к самому интересному — собственно вопросам для интервью. Я начал составлять свой собственный список во время моей первой работы в Майкрософте. Существуют сотни знаменитых вопросов от Майкрософт. У каждого есть свои любимые вопросы. Вам тоже нужно разработать свой набор вопросов и собственный стиль интервью, это поможет вам принимать правильные решения. Вот некоторые приемы из моей практики. Перед интервью я читаю резюме кандидата и набрасываю план интервью на листке бумаги — просто список вопросов, которые я собираюсь задать. Вот типичный план интервью кандидата на позицию программиста: До интервью я стараюсь избегать всего, что может создать у меня предвзятое мнение о кандидате. Если вы сочтете кого-то умным еще до того, как он войдет в комнату, только потому, что он Ph.D. из MIT, ничто из сказанного им за час не перевесит этой предвзятости. Если вы заранее решили, что он — полный дурак, ничто вас не переубедит. Интервью подобно чувствительным весам: очень трудно судить о ком-либо на основании часовой беседы. Но если вы что-то узнаете о кандидате до интервью, на одной чаше весов появится здоровенная гиря, и интервью потеряет смысл. Однажды прямо перед интервью к нам в офис зашел рекрутер и сказал: «Этот парень вам очень понравится!» Это меня полностью выбило из колеи! Я должен был сказать что-то типа «если вы так уверены, что он мне понравится, что ж вы его сразу не наняли и не сэкономили мне время ?» Но я был молод и наивен и пошел его интервьюировать. Когда он говорил что-нибудь не очень умное, я думал: «Ну, это исключение, подтверждающее правило». Я смотрел на все его ответы через розовые очки. В итоге я сказал «берем», хотя это был никудышный кандидат. И что бы вы думали ? Все остальные, интервьюировавшие его, сказали «не берем»! Мораль: не слушайте рекрутеров, не спрашивайте никого о кандидате и не говорите о нем с другими интервьюерами до момента принятия независимого решения. Это и есть научный метод! Фаза вступления в интервью должна расслабить кандидата. Я трачу около 30 секунд, рассказывая кандидату, кто я такой и как буду проводить интервью. Я всегда заверяю кандидата, что нас интересует его подход к проблеме, а не его конкретные ответы. Кстати, в процессе интервью не стоит сидеть через стол от кандидата, поскольку это создает формальную преграду и мешает ему расслабиться. Лучше поставить стол к стене или обойти стол и сесть рядом с кандидатом. Интервью при этом проходит лучше, поскольку он меньше нервничает. Вторая часть — это вопрос о каком-нибудь проекте, в котором кандидат недавно участвовал. Если он только что окончил институт, спросите о теме диплома, о курсовом проекте или о предмете (не обязятельно компьютерном, так даже интереснее), который ему больше всего понравился. При интервьюировании опытных кандидатов можно спросить о предыдущем месте работы. В ответе на этот вопрос меня волнует только одно: энтузиазм. Вот хорошие признаки при обсуждении предыдущей работы: Третьим в списке идет вопрос на засыпку. Это забавно. Смысл в том, чтобы задать вопрос, на который у человека не найдется ответа — просто чтобы посмотреть, что он будут делать. Сколько окулистов в Сиэтле? Сколько тонн весит Вашингтонский Монумент? Сколько бензоколонок в Лос-Анджелесе? Сколько настройщиков роялей в Нью-Йорке? Из программистских вопросов мне больше всего нравится попросить написать небольшую функцию на Си. Вот обычные задачи: Не стоит задавать задачи, требующие более 5 строк кода; на это просто нет времени. Рассмотрим эти задачи подробнее. #1: Переворот строки на месте. Каждый кандидат, с которым я имел дело, первый раз делал это неверно. Все без исключения пытались выделить новый буфер в памяти и переворачивать строку в нем. Вопрос, кто выделяет буфер? И кто его освобождает? Задавая этот вопрос множеству кандидатов, я обнаружил любопытную вещь. Большинство людей, думающих, что они знают Си, на самом деле не понимают работы памяти или указателей. Это до них просто не доходит. Удивительно, как эти люди работают программистами, но ведь работают же! Вот несколько способов судить о кандидате на основании этого вопроса: Третья задача показывает, насколько хорошо они учили побитовые операторы в Си... но это уже навык, а не способность, и тут им можно помочь. Интересно посмотреть, как они пишут программу, пересчитывающую все биты в байте, а потом попросить сделать это гораздо, гораздо быстрее. Сообразительный кандидат создаст поисковую таблицу (там ведь всего 256 значений), заполняемую только один раз. С хорошим кандидатом можно даже завести интересную беседу о компромиссах между скоростью выполнения и требуемой памятью. Поднажмите. Скажите, что не хотите тратить время на создание таблицы при инициализации. Очень умные кандидаты могут даже предложить схему кэширования, где биты считаются при первом использовании и сохраняются в таблице, чтобы не пересчитывать их в следующий раз. А самые умные попробуют изобрести способ вычисления значений таблицы, используя для этого некие расширенные методы программирования. Наблюдая, как кто-нибудь пишет код, используйте следующие полезные приемы: Непременно скажите кандидату, что вы понимаете, как трудно писать код без редактора, от руки, и чтобы он не переживал, что его каракули будут не так легко разобрать. Признак хорошего программиста: он имеет привычку сразу ставить фигурные скобки { и } и писать между ними. У него обычно есть своя, пусть и примитивная, система присвоения имен. Хорошие программисты обычно используют короткие имена для индексов цикла. Если такая переменная названа CurrentPagePositionLoopCounter, значит, немного кода этот человек в своей жизни написал. Иногда встречается программист на Си, пишущий что-то типа if((0==strlen(x)), помещая константу слева от ==. Это очень хороший признак, означающий, что он уже столько раз попадался на путанице между = и ==, что выработал в себе привычку, исключающую подобное. Хорошие программисты думают перед тем, как писать программу, особенно если в коде используются указатели. Например, если нужно перевернуть связный список, хороший кандидат непременно нарисует сбоку, откуда и куда идут указатели. Он просто вынужден это сделать, ибо человек не в силах написать код, переворачивающий связный список, не нарисовав маленькие квадратики со стрелочками между ними. Плохой программист начнет писать сразу. Скорее всего, в их коде будут ошибки. И тут мы подходим к вопросу номер 5: Нравится ли вам ваш код? Альтернативный вариант: «Ну, и где здесь ошибка?» Типичный Вопрос С Открытым Концом. Все программисты ошибаются, в этом нет ничего особенного, но нужно уметь находить свои ошибки. При работе с текстами очень часто забывают завершить новую строку нулем. Почти всегда легко ошибиться на единицу при подсчетах индексов. Иногда забывают точку с запятой, или функции работают некорректно со строкой нулевой длины или вызывают GPF при неудачном обращении к malloc... Очень, очень редко попадается кандидат, с первого раза не сделавший ни одной ошибки. В этом случае все еще забавнее. «У вас тут ошибка!» — после чего он внимательно изучает написанное, а вы смотрите, может ли он мягко и дипломатично заявить, что его код абсолютно верен. В общем, всегда полезно спросить кандидата, доволен ли он своей программой, прежде чем двинуться дальше. Далее, номер 6: вопрос по дизайну. Попросите кандидата что-нибудь спроектировать. Джейб Блюменталь (Jabe Blumenthal), первый дизайнер Excel'я, любил просить кандидатов спроектировать домик. Он говорил, что встречались кандидаты, немедленно рисующие квадрат. Квадрат! Это были явные кандидаты на отсев. Что, собственно, нам нужно от этого вопроса? Что приводит нас к номеру 7, вопросу-провокации. В процессе интервью нужно дождаться, пока кандидат не скажет что-нибудь абсолютно, бесспорно верное. Тут надо сказать «минуточку, минуточку» и пару минут поиграть в адвоката дьявола. Поспорьте с ним, твердо зная, что он прав. Получается довольно забавно. Известно, что во время интервью стороны находятся в неравном положении. Есть риск, что кандидат просто не отважится спорить с вами. Но хорошие кандидаты, как правило, мгновенно «заводятся» и забывают, что они на интервью. Они непременно постараются вас переубедить. Это и есть люди, которые нам нужны. Последний вопрос к кандидату — есть ли у него вопросы. Некоторые пытаются посмотреть, насколько умны вопросы, задаваемые кандидатом. Это стандартная техника из руководства по проведению интервью. Для меня его вопросы не имеют значения. Во-первых, к этому моменту я уже принял решение. Во-вторых, за день кандидат должен поговорить с 5-6 людьми, и трудно задать 5-6 людям разные умные вопросы. Так что если у кандидата нет вопросов, это хорошо. В конце интервью я обязательно оставляю пять минут на рекламу нашей фирмы. Это очень важно, даже если вы не собираетесь брать этого человека на работу. Если вам повезло найти действительно хорошего кандидата, следует сделать все возможное, чтобы он захотел работать в Fog Creek. Если же это плохой кандидат, нужно, чтобы он ушел в восторге от компании. Смотрите на это так: те, кого вы интервьюируете, — не только потенциальные сотрудники, но и клиенты. Они — ваши потенциальные рекрутеры. Если они сочтут вашу компанию классным местом, то приведут к вам своих друзей. Да, я обещал дать вам примеры плохих вопросов. Прежде всего, исключите запрещенные вопросы. Все, связанное с расой, религией, полом, страной происхождения, возрастом, военной обязанностью, статусом ветерана войны, сексуальной ориентацией или физическим состоянием, является противозаконным. Если в резюме кандидата написано, что он в 1990-м году служил в армии, не нужно — даже для поддержания разговора — спрашивать, участвовал ли он в "Буре в Пустыне". Это противозаконно. Если в резюме сказано, что кандидат учился в Хайфском Технионе, не нужно — даже мимоходом — интересоваться, израильтянин ли ваш собеседник. Это противозаконно. Довольно интересное обсуждение запрещенных вопросов можно найти (все остальные вопросы на этом сайте на редкость неудачные). Далее, старайтесь избегать любых вопросов, создающих впечатление дискриминации по тому или иному признаку или повышенного внимания к тому или иному признаку. Вот хороший пример: если вы спросите, замужем ли ваша собеседница и есть ли у нее дети, у нее может создаться ошибочное впечатление, что в вашей компании косо смотрят на семейных сотрудников, особенно женщин, так как они якобы уделяют меньше времени работе и в любой момент могут уйти в декретный отпуск. И последнее: не задавайте голововоломных вопросов, например, как сложить 4 равносторонних треугольника из 6 спичек. Знает кандидат верный ответ или нет — вы все равно ничего не узнаете о его умственных или деловых качествах. Интервью — это скорее искусство, чем наука, но если держать в голове принцип «знает свое дело и умеет его делать», все упрощается. Если получится, поговорите со своими коллегами об их любимых вопросах и об ответах, которые они ожидают услышать. В кафетерии 16-го корпуса в Редмонде это уже много лет любимая тема для обеденных разговоров. Примечания переводчика. Примечания редактора. В английском оригинале статья называется | |||||
Джоель Спольски - основатель , небольшой компании по разработке программного обеспечения, расположенной в Нью-Йорке. Окончил Йельский Университет, работал программистом и управляющим в Microsoft, Viacom и Juno. |
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |