[Перевод] Как НЕ надо нанимать разработчика софта
Я не специалист по подбору персонала для крупных компаний, но имею большой опыт работы с небольшими компаниями и немного здравого смысла.
Еще в 2013 году я провел очень успешную компанию по найму на AboutEcho.com, которая привела к найму девяти инженеров высшего звена. Мои русскоязычные читатели могли прочитать об этом здесь.
Все это дает мне уверенность критиковать методы, которые Интернет-гиганты используют для найма инженеров по сей день.
Не стремитесь к лучшему решению
Когда вы прибываете на собеседование, интервьюер ставит вам проблему и ожидает решения через 0–2 минуты. Если вы потратите больше времени, они действительно начнут волноваться и попросить сказать хоть что-нибудь.
Это можно понять — в конце концов, у них есть только 45 минут, и они хотят обсудить с вами много вещей.
Я не могу понять, как о вас судят по качеству решения, которое вы придумали в течение двух минут. Потому что человеческое творчество работает не так. Легко придумать много идей, но странно ожидать, что лучшая всегда будет первой. Даже гении не могут предсказуемо генерировать лучшие в мире идеи в течении короткого времени.
Творчество — это способность оценивать и фильтровать поток идей, которые вы придумываете. Если вам это действительно интересно, почему бы вам не попросить собеседника сравнить и оценить несколько идей? Проверить, может ли человек оценить свойства предлагаемого решения? Если он четко видит все за и против?
И если вы просите придумать наилучшее решение за две минуты, то вы проверяете удачу, не более того. Вы занимаетесь наймом удачливых сотрудников? Или способных?
Не задавайте головоломок
Как проверить, есть ли в связанном списке цикл? Помещается ли одна N-мерная коробка в другую N-мерную коробку? Можете ли вы поменять местами две переменные без третьей? Как найти кратчайшее расстояние между двумя движущимися кораблями? Найти все перестановки из N элементов, выполнив только N-1 перестановок?
Об этих головоломках интересно рассказывать, и их решения могут быть очень полезными. В детстве я любил, чтобы многие из них читали «Математические развлечения и эссе». Не поймите меня неправильно, они веселые.
Однако какими бы забавными они ни были, это всего лишь анекдоты. Свойство головоломки в том, что вы либо знаете ответ на нее, либо нет. Больше это вам ни о чем не говорит. Это не имеет ничего общего с будущими показателями, умением, способностями или чем-то еще. Знание конкретного ответа не означает, что у вас есть аппарат для решения реальных проблем общим и предсказуемым образом. Единственное, о чем это вам говорит, это то, что человек был в этой ситуации и кто-то поделился с ним решением. Ни больше ни меньше. Просто остановитесь уже.
Как спаситись, до того как свеча пережгет веревку?
Будьте открыты для альтернатив
Это отчасти ожидаемо, но крупные компании, похоже, все еще заваливаются на этом. Если собеседник предлагает альтернативное решение, у вас как у интервьюера есть шанс чему-то научиться. Это также хороший шанс для более глубокого обсуждения, если предложенное решение окажется невозможным или плохим.
Тем не менее, меня уволили за то, что я однажды предложил альтернативное решение такой же сложности (и меня обременяли лекцией об «единственном истинном подходе к этой проблеме»), а в другой раз я строго привел к конкретному решению. В последнем случае интервьюер очень хотел игнорировать все мои опасения и хотел обсудить только то, что он видел в качестве решения проблемы, а позже оставил обо мне «не впечатляющий» отзыв.
Никто не знает всего. Будьте открыты. Слушать. Размышляйте. Да, даже если вы интервьюируете кого-то.
Будьте терпимы к недостаткам
Единичные ошибки широко признаны одной из самых сложных проблем в CS не зря — их делают все. Ошибки — это часть жизни программиста, а не то, от чего можно избавиться. Хороший программист просто знает, что с этим делать. Качество программиста НЕ определяется тем, насколько мало ошибок он делает.
Теперь, если вы выберете только людей, которые не ошиблись во время собеседования, вы волшебным образом не получите команду программистов, которые всегда пишут безупречный код. Вы просто не знаете, как они будут себя вести, когда они неизбежно совершают ошибки.
Так что ошибки на самом деле — хорошо, потому что вы узнаете, как этот человек их исправляет. Не судите об ошибках, оцените, как собеседник их обрабатывает:
- простой код,
- разделяй и властвуй,
- самопроверки,
- инварианты,
- утверждение,
- компиляция и запуск,
- тестирование.
Ой, извините за последние два. Я забыл, что вы не позволяете им запускать свои программы. Ну, а чего вы тогда ожидали?
Позвольте мне проверить!
Серьезно, а что такое написание программы на маркерной доске?
Я имею в виду, что счастлив обсуждать алгоритмы — так как обсуждение абстрактных вещей более эффективно.
Но писать программы, настоящим программистам в блокноте? Даже не запустив их? В чем смысл? Получение первого черновика кода составляет лишь одну десятую всего процесса, за которым следует компиляция, проверка, настройка, тестирование, проверка и т. д. Кого мы обманываем? Это основные части рабочего процесса любого программиста. На код полезно смотреть только тогда, когда он уже прошел все это, а не раньше.
Это все равно, что попросить художника нарисовать лошадь, а затем остановить его на полпути во время самого первого наброска, когда вы видите четыре вертикальные линии ног и судите об этом. Как много вы о ней узнаете?
Изучайте глубже
Пять коротких интервью? Или два длинных?
С пятью вы получите пять независимых мнений, что лучше, чем два. Но насколько глубоко вы можете погрузиться за 45 минут? Практика показывает, что достаточно написать 20–30 строк кода и задать пару действительно простых вопросов (в чем сложность? Как тестировать?).
Следующий интервьюер просто повторяет тот же процесс, доходя до предыдущего. Что недолго. Совсем недолго.
Почему бы не сделать их двумя и сделать их действительно основательными? Например, один до обеда и один после? Три часа — тоже немного, но, по крайней мере, у вас есть шанс увидеть, как человек тестирует код, как он его изменяет, как он работает с требованиями — все в рамках уже установленного контекста, без сброса и запуска с нуля каждые 45 минут.
С таким количеством времени вы даже можете попросить его написать код, как если бы он был частью системы, а не просто абстрактной алгоритмической задачей в вакууме, и узнать еще кое-что о ее реальных характеристиках.
А если хотите больше мнений? Посадите в комнату несколько интервьюеров, чтобы они потом спорили.
Изучите предысторию
У меня четырнадцать лет опыта (на момнт написания статьи, 2019). Я был бы счастлив поговорить о функциональном программировании, распределенных системах, консенсусе, репликации, совместном редактировании текста, CRDT, параллельных архитектурах, фреймворках пользовательского интерфейса, командных процессах, дизайне продукта, пользовательском опыте. У меня есть практический и исследовательский опыт во всех этих областях. Все они представляют прямой интерес для более или менее любых интернет-гигантов, у которых я брал интервью.
Меня когда-нибудь спрашивали об этом? Нет.
Я получаю: «Представьте, что у вас есть функция, которая принимает список…» пять раз подряд. Пять задач школьного уровня должны дать вам адекватное представление, о чем? Насколько внимательно я читал Кормена и др.? Честно говоря, о них тоже редко спрашивают.
Вместо этого настройте собеседование с учетом опыта кандидата. Поговорите о том, в чем он хорош. У вас будет возможность задать глубокие вопросы и узнать больше об уровне опыта и преимуществах, которые она принесет вашей компании.
Сделайте процесс плавным
Неправильное направление? Задержанные билеты? Анкета, требующая установки оригинального Adobe Reader специально? Дешевый ультрабук с незнакомой раскладкой клавиатуры и плохим веб-редактором без каких-либо ярлыков, который тормозит даже на локальной машине? Извините, я нахожусь в офисе самой способной IT-компании в мире, не так ли?
В моем случае один рекрутер устраивал пять собеседований в день. Пять человек каждый день. Умноженное на количество рекрутеров в этой компании. Представьте себе, что все эти кандидаты слегка разочарованы процессом. Каждый день. Год за годом.
Вы можете подумать, что это не имеет значения. Смотря как. Был эпизод телешоу «Луи», где на его двери написано название комикса. Поэтому он утверждал: да, эту ошибку легко сделать, но ее также легко исправить. Неважно, это всего на один день, если вы хоть немного беспокоитесь, пожалуйста, сделайте это правильно.
Да, я считаю, что любой может добиться большего.
В заключение
Если вы нанимаете инженеров-программистов, то практики крупных компаний вам не друзья. А здравый смысл, справедливость, терпимость, настоящий интерес и непредубежденность — друзья.
Хорошего найма!
