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

От автора статьи. Мне нравится подход Егора Бугаенко к разработке софта и организации связанных с этим процессов. Я конспектирую некоторые его видео-доклады на своем блоге, и этот (Мой опыт проведения 1000 интервью / Егор Бугаенко (Zerocracy)) я публикую здесь с разрешения Егора. По ходу текста я даю свои комментарии к его словам, используя наклонный шрифт. Текст написан от третьего лица, но иногда перехожу на повествование от первого.

Грехи интервью

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

1. Гордыня (arrogance)

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

Оценку технических навыков специалиста стоит поручить соответствующим сертифицирующим центрам типа Microsoft и Oracle. Любой программист за приемлемые для себя деньги может пройти сертфикацию и показывать его интервьюерам. Это позволит сэкономить время обоим сторонам интервью. Центров сертификации много, и они есть для почти каждого языка программирования. В целом Егор считает, что

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

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

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

2. Доверчивость (credulity)

Здесь Егор имеет в виду доверчивость к резюме. Обычно кандидат приходит на интервью и начинает разговор с последнего места работы. Ты ему вопрос "какой ты программист", а он в ответ начинает рассказывать о том, где он работал: как в яндексе занимался проблемами поиска в интернете, в газпроме — обеспечением поддержки нефтяных вышек, а в сбербанке — проблемами обслуживания кредитной системы. Но по факту и там, и там, и там человек занимался рефакторингом какого-то Java-кода, написанном до него. Мы доверяем громким словам кандидата, но по сути его уровень может быть не так высок, как он сам считает. Для Егора предыдуще места работы ничего не значат. А верит Егор следующей информации:

Open source contribution

Егор уже неоднократно говорил, что если разработчик считает себя хорошим программистом, заинтересованным в своей карьере, а не отсиживающем в офисе с девяти до пяти, то он должен делать вклад в open source. Либо это будет вклад в собственные проекты, либо в открытые продукты других авторов. А если кандидат говорит, что отработал 10 лет в нескольких банках, а еще у него жена и ребенок и поэтому он не делает вклад в open source, то это для Егора — один из звоночков. Человек за 10 лет работы не нашел ничего, что можно было бы улучшить и выложить в открытый доступ, и это показывает Егору, что перед ним слабый специалист.

По мнению Егора, люди, у которых есть вклад в open source, должны получать больше, потому что они нашли в себе смелость, время и энтузиазм довести до состояния продукта какой-то кусок кода, который они написали в XXX-банке и выложить его в open source. И Егор просит не упоминать NDA, потому что написанный в стенах работодателя код, который сортирует коллекцию более эффективно, чем стандартные методы языка, не покрывается NDA. NDA — это о неразглашении информации о самом работодателе, его сотрудниках, структуры компании и прочей конфиденциальной информации, касающейся непосредственно работодателя. Java-код уж точно не покрывается NDA.

Сертификаты

О сертификатах Егор уже упоминал выше.

Community

Егору интересно, кто из программистов знает кандидата. Не предыдущие работодатели, а именно технические специалисты. Какое влияние оказывает конкретный кандидат на комьюнити. Блог, open source продукт, доклады на митапах или даже организация этих митапов. Мало кто может похвастаться тем, что другие программисты следуют за ним.

Pet-проекты

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

Stackoverflow

Этот сайт вопросов и ответов вытеснил собой все программистские форумы, считает Егор. Если кандидат говорит, что использует stackoverflow не только в readonly-режиме, то Егор ценит такого кандидата выше. Даже вопрос задать нужно уметь задать правильно, что уж там говорить об ответах. Егор советует всем просто попробовать оформить хотя бы вопрос так, чтобы его поняли, разобрались и помогли ответом. Это не так легко, считает Егор. Что уж говорить об ответах: нужно успеть отправить ответ быстрее остальных, и ответ должен быть правильным и оформлен так, чтобы его поняли многие.

Егор обращает внимание только на эти 5 пунктов резюме. Доверять словам, что кандидат работал 7 лет в банках и только поэтому он является хорошим программистом, глупо, говорит Егор. Факт, что человек просидел в банке, это месседж о том, что его просто не могли оттуда уволить.

Мнение редактора. Согласен почти по всем пунктам, но признаю, что следовать им всем действительно очень тяжело. Одни ответы на stackoverflow чего стоят: ты должен успеть написать правильный ответ, да еще и так, чтобы его можно было бы взять и перенести себе в код. Мне кажется, что чтобы делать так, нужно действительно проводить "на пульсе" много времени в stackoverflow. Лично для себя я не вижу такое.

3. Эгоцентризм (self-obsession)

Компании при найме сотрудников считают, что они нанимают только идеально подходящих работников среди всех кандидатов. В пример Егор приводит твит Макса Ховела (Max Howell) — автора программы Homebrew — где он сетует на Гугл: Гугл отказал в найме Максу из-за того, что он не сумел инвертировать бинарное дерево на доске, даже несмотря на то, что 90% разработчиков Гугла пользуются программой Homebrew.

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

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

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

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

Егор рассказал еще историю, что когда-то услышал вопрос от кандидата "Чему я могу у вас научиться?" Работодатели должны не кандидатов подстраивать под пайплайн и нанимать именно тех, кто смог адаптироваться, а искать тех, кто яркий сам по себе. Егор советует компаниям оставить на технические вопросы 5-10 минут, а затем спросить кандидата "а что в тебе такого интересного?" Если в ответ кандидат говорит, что в нем нет ничего интересного и что он просто Java-программист, то это — одна категория, а если он начинает рассказывать, что пишет собственный open-source фреймворк, который решает такие-то вот проблемы, не решенные в аналогах, то это — другая совершенно категория людей.

4. Неопределенность (vagueness)

Очень часто Егор видит, что многочасовые интервью заканчиваются вердиктом "Good guy!". Это — нечеткий, субъективный результат интервью, который нельзя перепроверить даже спустя 2 недели. Егор же заканчивает свои интервью таблицей с баллами. Что за критерии в таблице, Егор специально не показал. После интервью у него есть некая объективная оценка, по которой он может уже сравнивать кандидатов на позицию. В противном случае, когда у нас есть только вердикты "Good guy!" и "Bad guy!", мы не можем оценить ретроспективно кандидатов и нанимаем на эмоциональном ощущении. Это, считает Егор, непрофессионально. Интервьюер в таких случаях просто не умеет выразить свои ощущения в цифрах и выдать метрику, что конкретный кандидат нравится ему потому-то и потому-то в 5.5/10 баллах. Во "внешний мир" интервьюер может выдать вердикт в виде только лишь "Good guy!", однако для себя он уже понимает почему так и насколько "сильно" хорош кандидат.

5. Враждебность (hostility)

Егор часто видит, как интервьюеры считают, что они самые умные, ведь они уже сидят в этой компании и теперь их задача на собеседовании — не кандидата раскрыть и понять его уровень, а себя показать. Такие интервьюеры задают вопросы надменно и высокомерно, "пугая" кандидатов. Это тоже непрофессионально. Интервьюер должен раскрывать кандидата и ни в коем случае не показывать свои эмоции насчет его ответов. Что бы кандидат не говорил, какие бы "глупости" по мнению интервьюера не озвучивал, это мнение кандидата и хорошо, что он это рассказывает на интервью. Уже после собеседования интервьюер может обсуждать услышанное с коллегами и "высмеивать" в случае, если кандидат нес чушь.

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

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

Жесткость только мешает, она приводит к потере информации.

Мнение редактора. Я видел такое много раз. Когда-то на моем собеседовании интервьюер просто вставал и ушел. Кстати, меня он "валил" как раз вопросами по алгоритмам и коллекциям. Я тоже далек от алгоритмов и прямо об этом сказал на собеседовании. Я не сильно рефлексировал по этому поводу, потому что знаю, что алгоритмы — не мое, и просто "забыл" об этом интервью. Сейчас же после просмотра доклада я понял, что я просто не подходил под требования компании и это не значит, что я был плохим специалистом.

6. Эмоции (emotions)

Люди проявляют эмоции, и многие могут сказать, почему бы не проверить эмоциональню составляющую кандидата: поведение в стрессовых ситуациях, например. Некоторые даже называют это soft skills. Егор не сторонник такого интервью и считает, что soft skills точно не об этом: soft skills не про эмоции. Soft skills — это те навыки, которые напрямую не относятся к программированию, но тесно связаны с ним:

• Branching — умение работать в нескольких ветках, даже одновременно. Это умение разбивать большую таску на множество мелких и даже параллельных, а также умение быстро переключаться между контекстами.
• Drawing — умение доносить свои мысли через диаграммы. Даже обычные квадраты и стрелки вместо UML лучше, чем ничего.
• Writing — умение писать документацию и выражать свои мысли письменно. Не только джуны должны уметь писать документацию.
• Intriguing (интриги) — умение понимать и вести политику в офисе. Это тоже важный навык, хотя многие считают, что "они просто программисты". Нужно уметь понимать, кому написанный код нужен, а кому — мешает.
• Testing — умение построить систему тестирования, написать правильные юниттесты.
• Reporting. Многие умеют кодить, но написать об этом не могут. Вроде и накодил, и протестировал, и задеплоил, но написать об этом не сумел, что перечеркивает труд за всю предыдущую неделю.
• Volunteering — умение участвовать в активностях, за которые не платят. Если их делать, то карьера будет расти: помощь в организации профессиональных митапов, выступлений и тд.
• Delivering. Многие программисты не понимают, как код с их лэптопа попадает на продакшн. Нужно уметь понимать это.
• Tweeting — умение работать с социальными сетями. Если вы считаете, что соц.сети — не про вас, то вы просто ретроград. Когда-то и про мобильные телефоны говорили "зачем эти мобильные телефоны? На работе есть телефон, дома тоже". Нужно уметь представлять себя в соц.сетях правильно. Если кандидат говорит, что у него нет профиля в инстаграме, то это — ретроград, который не умеет им пользоваться. Лучше сразу иметь дело с тем, кто понимает, что соц.сети — зло, если пользоваться ими 8 часов в день, если вступать в дискуссии в твиттере, если в инстаграмме лайкать все подряд. Соц.сети тоже можно превратить в инструмент для работы.
• Relaxing. Если человек ничего не может сказать насчет того, как он отдыхает, то лучше не работать с такими людьми. Если человек не умеет отдыхать, то у него будет низкая производительность.
• Charging. Многие не умеют брать деньги за свою работу и не могут сказать, сколько они стоят. Умение торговаться, умение понять условия и посчитать стоимость этих условий.
• Asking — умение правильно задавать вопросы.

7. Загадочность (mistery)

Загадочность после интервью и отсутствие обратной связи кандидату. Причин может быть много: NDA, "Good guy"-фидбек или иные подобные. Важно оставить кандидата с хорошим впечатлением о компании, особенно когда мы отказываем кандидату. Человек должен уйти с каким-то конструктивом. Егор сам грешит этим, и если только если кандидат спрашивает об обратной связи, тогда он ее и дает. "Мы с вами свяжемся" — это ни о чем, кандидат понимает, что перед ним — непрофессионалы.

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

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

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

Вопросы из зала

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

Я действительно ценю тех разработчиков, которые больше зарабатывают (для компании — прим.ред.), которые закрывают больше тикетов. Хороший программист — тот, кто коммитит больше всего кода в репозиторий, но это определяется только через время. Но момент проведения интервью я не могу об этом судить, ведь я не знаю человека и стоит ли ему вообще давать тикеты. По опыту могу сказать, что нанимая человека с блогом, выступлениями и гитхаб-аккаунтом, я получаю шансов больше на то, что он будет коммитить больше, чем тот, кто не медиен. А вот когда человек приходит совершенно без ничего и говорит, что "я проработал в банке 10 лет и я обязательно буду закрывать задачи", то закрывать задачи он не будет, потому что он не умеет многие вещи.

Центры сертификации не отражают навыки, потому что ответы на вопросы уже есть в интернете. Заучил — и прошел сертификацию успешно. Разве сертификат может объективно оценить программиста?

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

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

Вы можете подумать, что сделать доклад так легко. Ну выйдете на сцену и сделайте доклад по Java, и мы посмотрим как у вас это получится. Для того, чтобы это сделать, нужно пройти длинный путь: подготовить доклад, пройти отбор программного комитета, подготовиться к выступлению. Конечно, если человек медиен тем, что постит котят и репостит мемы про Java, то это одна медийность. А если человеку есть что сказать на митапе, то это уже другая категория медийности.

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

Мнение редактора. Ощущение, что Егора очень нервирует этот вопрос. Явно ему уже не раз задавали его, и он очень бурно на него реагирует. Впрочем, этот ответ перекликается под озвученный тезис в докладе о том, что нужно не искать людей, подходящих под определенный стандартный пайплайн, а спрашивать кандидатов, в чем они сильны. Один — в алгоритмах, другой — в problem-solving-навыках. Так что вопрос из зала в этом контексте звучит так, как будто Егор не смог донести свою мысль, и его раздражительность объяснима.

Ты немного упоминал про soft-skills, но ты понимаешь, что человек груб/токсичен и не совсем подходит под команду. Как ты скажешь ему "нет"?

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

Егор также решил рассказать историю о ненайме одного сотрудника в Нидерландах. Егор занимался интервьюированием кандидатов в команду, которая исторически сложилась только лишь из белых молодых мужчин. Собеседование Егор проводил для индуса средних лет, и специалист показал себя неплохо. Егор после интервью сомневался, то индуса возьмут именно из-за того, что он отличается от остальных участников команды. Он передал менеджеру свой фидбек, а менеджер сказал "Not a good fit" без объяснения причин. Егор до сих пор не знает, правильно ли сделал менеджер или нет.

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

Что делать, если идеального кандидата нет, а проект надо запускать едва ли не сегодня?

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

На поиск идеального кандидата может уйти вся жизнь.

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

Мой начальник хочет очень качественной технической части интервью, иначе, говорит он, "мы берем кота в мешке". Что делать?

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

Егор, ты даешь код кандидату на проверку. А что делать, если кандидат говорит, что "все нужно переписать"? Это признак яркости или, наоборот, ему не интересно разбираться в прежнем коде.

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

Профессионал, открыв код и увидев, что его нужно переписать, закрывает код и говорит остальным: "а давайте пойдем на курсы" или "а давайте я расскажу вам что такое юниттестирование" или "а давайте мы UML изучим". Вот это — профессиональный подход.

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

Если с разработчиками разобрались, то что вы скажете насчет интервью тестеров или бизнес-аналитиков?

Егор признался, что у него мало опыта в этом и поэтому он не стал отвечать на вопрос.

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

Возможно, Егор действительно просто не дождался, и подстраиваться только лишь под него — слишком дорого для Амазона. Поэтому и его пустили по пайплайну. Доклад не об этом, и Егор как раз и говорит о том, что такой пайплайн не всегда приносит профиты. Именно в таких пайплайнах могут потеряться интересные люди, а проходят как раз те, кто учится проходить стандартные интервью только лишь для того, чтобы сесть в Google или Amazon.

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

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

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