Эти токсичные, токсичные собеседования

Всё началось, когда автор Ruby on Rails признался миру:

К нему присоединились и другие разработчики:

Один из самых старших инженеров Google сказал, что ни черта не помнит как работает квиксорт:

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

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

Как появилась эта статья

Для меня, как и для многих других, собеседования регулярно были болью. (А когда-то мне ещё и страшно было на них ходить.)

Я написал этот программный материал прежде всего из собственного опыта: приходилось много собеседоваться в своей жизни (стартапы, переезды). В процессе подготовки статьи много спорил с самыми разными разработчиками по обе стороны баррикад — как с кандидатами, так и интервьюерами. Сейчас я в том числе уже сам собеседую других людей в свои проекты и применяю полученный опыт. У меня сформировалась определённая позиция в этом вопросе, которой я хочу поделиться.

О каких именно собеседованиях речь

• викторины («Какая функция библиотеки X обладает особенностью Y?»)
• головоломки («Вас уменьшили до размеров 5-центовой монеты и бросили в блендер. Ваш вес уменьшился так, что плотность вашего тела осталась прежней. Лезвия начнут вращаться через 60 секунд. Ваши действия?»)
• вайтбоардинг («whiteboarding» — когда код требуется писать на маркерной доске)
• алгоритмические («Разверните бинарное дерево на бумажке»)

Чем вредны подобные собеседования

Проверяют в условиях стресса людей, специальность которых не предполагает работать в условиях стресса

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

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

Самые замечательные разработчики, которых я встречал — нёрды и гики. Им нужны спокойные условия. Им нужно состояние потока. В лучшие свои времена такой человек за день закодит вам сложнейшую задачу. Если вы всё ещё хотите проверять его на стрессоустойчивость, может, стоит вместо того задуматься, как убрать стресс из своих процессов? (Это даст существенно больше профита.)

Не коррелируют с разработкой

Невероятно, но сами Google признали, что нет корреляции между тем, как кандидат показал себя на собеседовании, и тем, как он прошёл затем перформанс-ревью в процессе работы.

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

Предположим, вы очень неплохо знаете некоторую тему, и вдруг по ней всплывает какой-то викторинный вопрос. Ответа вы не знаете. Люди замечают это, и, как правило, предполагают, что вы не знаете ничего по всей теме. (Много хуже, если вы поймали не один неудачный викторинный вопрос, а сразу несколько.)

Или, скажем, вы пишете код на доске, а синтаксис вылетел из головы. Как это будет выглядеть со стороны — проблема с памятью или с навыками? Неизвестно.

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

Порождают ненужные элитизм и дедовщину

Айти как сфера деятельности по своей природе невероятно подвержена ряду дуростей:

• культ сложности (Если решение недостаточно сложное или мне было недостаточно тяжело, то что-то не так)
• элитизм (Я лучше них, я лучше них, я прошёл все искусственные барьеры!)
• дедовщина (Меня гнобили, и я буду)

Причины здесь разные, и про них можно поспорить. Я рискну сказать, что дедовщина растёт из психологии, культ сложности — из инженерного характера нашего ремесла, элитизм же у айтишников исторический для стран СНГ. Всё это плохие штуки, ведущие к плохим решениям, значит, их стоит выдавливать из себя по капле.

Основные аргументы сторонников Google-style собеседований

«Ведь нужно проверять фундаментальные знания»

Вы так в этом уверены? Кому именно нужно? Здесь всё же не кафедра университета и не олимпиадный кружок, предлагаю вспомнить, зачем вы вообще ищете человека. Правильно. Писать API, проектировать инфраструктуру, рисовать кнопки, чинить баги, понимать задачу из общения с бизнесом, делать продукт дороже и круче. И делать всё это в срок и за деньги.

Способность разворачивать деревья на бумажке никак не поможет ни в одной из этих вещей (даже, собственно, может помешать: уведёт фокус с продукта на «божечки-кошечки, мы потратили неделю и сделали кастомный JSON-парсер, он на 7% быстрее». Я работал с такими людьми.).

«Вообще-то это требуется на практике»

Неа, не требуется. Более того: если я как тимлид увижу в репозитории мёрдж-реквест с наколеночным обходом графа или кастомной реализацией квиксорта, я с вероятностью 95% отклоню такой реквест с пометкой чувак, найди готовую библиотеку. Не говоря уже об истовом стремлении написать свою СУБД.

Что же касается каких-то особенностей языка или фреймворка, документация всегда к вашим услугам. (Для поездок на Кубу давно придумали Zeal/Dash).

Далее должна следовать обязательная ремарка про людей, пишущих поисковое ядро Google / Yandex. Но ваши разработчики в их число не входят (You Are Not Google), и прекрасно смогут прочитать про сложный алгоритм в момент, когда он действительно потребуется. Всё даже ещё интересней: в подобных хардкорных командах часто есть такой специальный парень с PhD по математике, который помогает разработчикам с алгоритмами.

«Если разработчик чего-то стоит, он это умеет»

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

В минуту уныния рекомендую вспомнить Дэна Абрамова, который в своё время не прошёл во Вконтакте:

и сотни других подобных примеров (флешмоб #меняневзяли в фейcбуке).

Что важнее, все ваши суждения правильный разработчик должен знать XYZ, скорее всего, являются иллюстрацией ошибки выжившего:

«Нам тут не тупо кнопки по вьюшке двигать»

Понимаю. Нам тоже. Но вы действительно переоцениваете значимость и уникальность ваших задач. (Я утверждаю это, даже не зная вашей компании: почти все переоценивают.)

«В нашей компании всё часто меняется, поэтому проверяем универсально»

Давайте будем честны: проверить человека универсально невозможно. (IQ-тест был красивой идеей, но провалился). И знание алгоритмов тут тоже слабо помогает.

Насколько часто и насколько сильно у вас всё меняется? Если ваши сотрудники регулярно и кардинально меняют специализацию, то либо вам это зачем-то требуется (допустим), либо стоит задуматься над процессами. В обоих случаях имеет смысл проверять людей на требуемые навыки, а не на абстрактные. (Если iOS-разработчик вдруг стал секретарём, ничего страшного — проверите его на скорость печати.)

Если же изменения не такие значительные и не такие частые — ну, делов-то, выучит человек новый фреймворк. Он же уже доказал вам за это время, что способен работать и учиться.

«У нас такой поток желающих на трудоустройство, что нужны серьёзные фильтры»

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

«Ты же сеешь невежество! Наверное, это из-за того, что ты не осилил алгоритмы!»

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

«Но так было всегда»

… и это ещё вовсе не означает, что существующий порядок вещей правилен.

«Я влёт считаю O(f(n)) и с удовольствием рисую графы на доске. Что же, всё это зря?»

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

«Но ведь в Google/Facebook/Zalando продолжают так собеседовать, как же туда пройти?»

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

«А что же тогда спрашивать?»

Now we're talkin'! Всё просто: спрашивайте те вещи, которые кандидату придётся у вас делать. Попросите разработчика спроектировать тиндер или убер. Обсудите с ним частые проблемы в работе с очередями, сериализацией, сокетами. Разрешите ему при этом использовать те инструменты, которые он привык использовать.

И обязательно смотрите и обсуждайте код, будь то GitHub или нечто, написанное в процессе собеседования.

Кстати, можете добавлять и головоломок/алгоритмов, если очень хочется. Просто учитывайте всё, что написано в данной статье.

Как всё обстоит в EXANTE

Когда я только сюда устраивался, разработчики пригласили меня на продолжительный диалог. Угостили колой, обсудили мои прошлые проекты, подробно рассказали, чем занимается компания. Я задал ряд вопросов по технической части. Было много дебатов на тему «почему в данном случае было такое решение, а не иное». В том числе получил пару вопросов по моему коду в открытом доступе. В конце мне дали задачку из разряда «Как бы вы запроектировали X». Ещё мы периодически смотрели код на лаптопах.

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

Как видите, никакого стресса и полная возможность показать знания-навыки.

Кстати, мы регулярно ищем людей: hh.ru/employer/597423. А ещё стараемся не терять их из виду, даже если не можем взять прямо сейчас. И можем по-дружески указать на пробелы, а затем пригласить спустя несколько месяцев.

Менять мир нелегко, но необходимо

Даже когда мы обсуждали проблему в твиттере, среди русскоязычной ветки диалога идея данной статьи была в меньшинстве: на её защиту встали лишь я и ещё один финский CTO. (Новые концепции вообще долетают до СНГ с традиционным запозданием.)

Был такой замечательный венгерский врач-акушер Игнац Филипп Земмельвайс. Ему первому пришла в голову мысль, что 30-50% смертность при родах вызвана инфекциями с немытых рук врачей. И он не просто не нашёл признания: его цензурировали, осмеивали, поместили в психушку. Он умер от избиений. Сейчас же Земмельвайс известен как основоположник асептики и «спаситель матерей».

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

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

Материалы для размышления

• В айти господствует мнение, что уровень программиста характеризуется его техническими навыками
• Как мы проводим собеседования в Pivotal
• Why I Don't Talk to Google Recruiters
• Embrace How Random the Programming Interview Is
• The Programming Interview from Hell
• What if companies interviewed translators the way they interview coders?
• Eric Schmidt struggled to answer a Google interview question
• When your entire knowledge gets judged because you didn't know that one random fact
• /g/ has an interview
• Most companies value code cleanness over deep knowledge

Автор: nazarov_tech

Источник