Перевод статьи «Let’s talk about whiteboarding interviews and the possible alternatives».
Многие разработчики просто ненавидят решать задачи на белой доске на собеседованиях.
В Twitter, Medium, LinkedIn вы легко найдете множество постов, в которых люди дают волю чувствам. И фраза «процесс найма сломан» встречается в этих постах так часто, что уже набила оскомину.
К сожалению, по большей части это просто глас вопиющего в пустыне.
Несмотря на массовое недовольство, «вайтбоардинг» (от англ. white board — «белая доска») по-прежнему является главной составляющей в собеседованиях программистов. Дело в том, что разработчики охотно выражают свое возмущение этой практикой, но не спешат предложить что-нибудь взамен.
Есть ли лучшие варианты?
Я сам недавно задумался над этим вопросом. Четыре недели назад я получил свою первую работу в роли разработчика. Естественно, пока что меня не привлекают к процессу найма других разработчиков, но когда-нибудь точно начнут.
Когда я искал работу и проходил собеседования, я осознал, насколько неточными могут быть их результаты. Но когда придет мой черед задавать вопросы, я хотел бы оценивать своих потенциальных коллег максимально точно и честно.
Все эти размышления привели меня к двум основным вопросам:
- Являются ли интервью с применением белой доски наилучшим вариантом?
- Если нет — каковы лучшие альтернативы?
В своей статье я попытаюсь ответить на эти вопросы. Имейте в виду, что все это мое личное мнение, сформированное на основе собственного опыта прохождения собеседований.
Я постараюсь быть как можно объективнее и подойти к задаче, как настоящий инженер: изучить все варианты и взвесить их плюсы и минусы.
Действительно ли нет ничего хуже белой доски?
Для начала давайте взвесим достоинства и недостатки вайтбоардинга.
Плюсы
- Не требует много времени и сил
- Не зависит от языка и сферы деятельности
- Вы знаете, чего ждать (в целом)
- Поддержка сообщества (Glassdoor, LeetCode, Pramp и т. д.)
Минусы
- Очень многое зависит от удачи (алгоритмическая лотерея)
- Не всегда позволяет оценить инженерные способности кандидата
- Ставит в более выгодное положение молодых инженеров и недавних выпускников
Если компании нужны разработчики, имеющие хорошее понимание основ информатики, знающие низкоуровневые алгоритмы и умеющие писать код, не пользуясь библиотеками, — интервью с белой доской им идеально подойдет для отбора.
SpaceX, MacOS/Windows и React были созданы инженерами, имеющими именно такие навыки. И если вы хотите попасть в одну из подобных компаний, логично ожидать вайтбоардинг на собеседовании.
Лично мне (как кандидату) очень нравятся собеседования с решением задач на доске. Я знаю, чего ждать. Большинство алгоритмических задач можно распределить по следующим темам:
- массивы и строки
- двоичные деревья
- связные списки
- поиск с глубину и поиск в ширину
- поиск с возвратом (бэктрекинг)
- динамическое программирование
Зная заранее, что будут спрашивать, можно подготовиться и выучить нужное. Для этого можно воспользоваться целым рядом специальных инструментов и ресурсов. Подготовка к техническим собеседованиями — это целая отдельная индустрия.
И именно по этой причине решение задач на белой доске не для каждой компании является наилучшим вариантом интервью. При таком отборе побеждает тот, кому повезло получить знакомую задачу, у кого хорошая память и кто мог себе позволить долго тренироваться в решении подобных задач.
Но не каждый может выделить много времени на освоение алгоритмов.
Мне повезло, я обошел других кандидатов на собеседовании. Но можно ли сказать, что как разработчик я лучше, чем все они? Возможно. Но я не уверен, что решение задачи на белой доске позволяет это оценить.
А если мы сомневаемся, что вайтбоардинг — наилучший инструмент для отбора, то какие еще есть варианты?
Давайте рассмотрим парочку.
Решение задач на программирование на компьютере
Плюсы
- Среднему программисту привычнее пользоваться компьютером и знакомой средой разработки, чем писать код от руки на доске
- Собеседование можно проводить дистанционно, путем расшаривания экрана
- Сохраняются все преимущества решения задачи на доске
Минусы
- Большая строгость в отношении синтаксиса и работоспособности кода
- Большое значение могут иметь среда программирования и плагины
- Сохраняются недостатки решения задачи на доске
Задачи на программирование с написанием кода в ноутбуке — менее суровый вариант интервью у доски.
Кандидаты могут пользоваться собственными компьютерами, а это уже преимущество. Собеседование можно проводить удаленно, в том числе в среде для парного программирования.
Я также заметил, что обычно задачи для решения на компьютере бывают попроще, чем задачи для решения на доске. Большинство вопросов, которые мне попадались, касались работы со строками. Также встречались простенькие алгоритмы, с которыми справится любой опытный разработчик (т. е. справится без специальной подготовки к собеседованию).
Но есть и обратная сторона: куда больший упор на функциональность.
В ходе поиска работы мне дважды попалась задача Coin Change (определение наименьшего количества монет для выдачи сдачи). Один раз мне нужно было решить ее на белой доске, а второй раз — в редакторе кода.
Решая задачу на доске, я отделался простым объяснением своего решения. Но при пользовании ноутбуком от меня ожидалось написание тестов для крайних случаев и гарантированно рабочий код.
Одна из причин, почему мне нравится вайтбоардинг, — большая снисходительность. Функцию, которую вы пишете на белой доске, никто не будет запускать через компилятор. Если интервьюеру понятен ход вашей мысли, а написание кода выглядит неплохо, вы имеете все шансы успешно пройти собеседование.
Но с задачами на программирование дело обстоит несколько иначе.
Кто-то может возразить, что упор на функциональность лучше, потому что в конечном итоге нам платят за рабочий код. Да, это так, но нам не платят за то, чтобы мы писали этот рабочий код спринтами по 30-45 минут.
Предположим, что вы при прохождении собеседования спокойны, как удав. Но один маленький баг, из-за которого провалятся тесты, отберет у вас несколько минут на отладку. А это в конечном итоге может изменить вашу оценку с «сильный кандидат» на «не прошел».
Задачи на программирование страдают той же предсказуемостью, что и задачи для решения на доске. В конечном счете они тоже крутятся вокруг алгоритмов.
Но когда на вас давит необходимость сделать код функциональным, решить задачу в редакторе может быть труднее, чем на доске. Даже несмотря на более привычную среду. Если вы в принципе не любите алгоритмические задачи, смена белой доски на редактор вас не спасет.
Тестовые задания
Плюсы
- Можно работать в пижаме
- Обычно выдаются на неделю
- Можно пользоваться привычным редактором и средой разработки
- Выполненное задание может стать пополнением вашего портфолио
- Обычно это интереснее, чем вайтбоардинг
Минусы
- Уровень сложности может быть совершенно разным
- Вам придется потратить куда больше сил и времени, чем на решение задач
- Может быть привязано к сфере деятельности компании
- Не отражает ту работу, которой вы на самом деле будете заниматься
Многие разработчики предпочитают тестовые задания. Времени на их выполнение обычно выделяют достаточно, к тому же кандидат пишет настоящий код. Не удивительно, что программисты охотно берутся за тестовое — лишь бы не стоять у белой доски, где интервьюеры молча оценивают каждое действие.
Но тестовые задания имеют существенные недостатки.
Во-первых, можно сжульничать.
Многие компании размещают свои тестовые задания на GitHub. Введите в строке поиска на GitHub слова «Challenge» или «Test» — и получите множество результатов. У смышленого кандидата есть куча времени, чтобы заранее поискать задачи.
Чтоб вы понимали, я не жалуюсь, а скорее совет даю.
Но проблема в том, что разработчику довольно просто найти не только сами задачи, но и решения других людей (и скопировать их). Многие программисты сохраняют свои решения тестовых заданий в своих профилях на GitHub.
Можете проверить сами. Введите в строке поиска на GitHub «<название-компании> Challenge» — и увидите, что вылезет.
Я живу в Бруклине, рядом с главным офисом Etsy. Мне стало любопытно, смогу ли я найти ответы на некоторые из их тестов. Поиск по «Etsy Challenge» дал мне четыре варианта. А поискав «Etsy Test», я нашел еще больше.
Да, компании могут менять свои задания. Но даже если менять процедуру собеседования каждые пару месяцев, сложно предотвратить утечку информации.
Во-вторых, уровень сложности тестовых заданий и время на их выполнение очень сильно варьируются.
В поисках работы я брался за четыре тестовых задания. Три компании утверждали, что выполнение их заданий должно занять всего 3-5 часов.
Но на каждое из них ушло несколько дней.
Основная причина этого в том, что тестовые задания часто «доменоспецифичны». Несколько часов потребуется только на изучение документации API и незнакомых технологий.
Четвертая компания дала мне задание, которое легко могло бы занять неделю, но времени дали два дня. Мне нужно было построить рабочее приложение-чат с поддержкой slash-команд.
Это был увлекательный, интересный проект. Но мне пришлось бросить все другие дела и два дня заниматься исключительно этим приложением.
Если кандидат достаточно везуч, чтобы его позвали на собеседование несколько компаний одновременно, выполнение тестовых заданий само по себе потянет на работу на полную ставку.
Кроме того, профессиональным разработчикам приходится работать с унаследованными кодовыми базами и в условиях дедлайнов. Создание проекта с нуля не демонстрирует способность кандидата работать в быстро меняющемся окружении.
Лично мне тестовые задания нравятся — как начальная проверка способностей кандидата. Но эти задания должны быть как-то связаны с работой, которую будет выполнять программист, если его возьмут в штат, и не должны занимать много времени.
Контракт на испытательный срок или на время работы над конкретным проектом
Плюсы
- Шанс поработать с командой
- Зарплата
- Работа над реальными проектами
- Можно оценить, насколько хорошо кандидат вписывается в команду и насколько хорошо умеет писать рабочий код
Минусы
- Такая проверка способностей отнимет много времени
- Работа без гарантии трудоустройства
- Контрактор не пользуется льготами, которые имеют постоянные сотрудники (страховки и т. п.)
- Это может поставить кандидата в невыгодную позицию при обсуждении условий найма и зарплаты
- Есть привязка к языку программирования
Случаи, когда для проверки кандидата с ним заключают контракт, довольно редки. Но некоторые компании это практикуют, например Basecamp и Automatic. И я могу их понять.
Такие «собеседования», вероятно, самый точный способ оценить чьи-то навыки и умение работать в команде. Компания имеет возможность посмотреть на кандидата в деле и понаблюдать, как он справляется с рабочими задачами.
Кандидат тоже имеет возможность оценить компанию и понять, хочет ли он работать в таком окружении.
Ситуация win-win. Ну, по крайней мере так кажется.
Мне ни разу не случилось проходить подобную проверку. Дело в том, что недостатки этого подхода слишком перевешивают достоинства.
Пара первых месяцев — самые тяжелые на любой работе. Вам нужно освоиться в новой команде, культуре, кодовой базе. А представьте, что вы работаете над проектом, не будучи уверенным, что в итоге вас наймут.
Один мой хороший товарищ недавно собеседовался в Automatic и подтвердил, что ситуация очень стрессовая. Оценивается все: от взаимодействия с коллегами до вопросов, которые вы задаете. Говорят, такого понятия как «глупый вопрос» не существует. Так вот: в таком положении оно есть.
А хуже всего то, что по истечении трехмесячного контракта его так и не наняли. К счастью, он не позволил этому повлиять на свою самооценку. Он знает свои способности и движется вперед. Но я не уверен, что другим разработчикам (например мне) это далось бы так легко.
Кроме того, контракты ставят кандидатов в очень невыгодное положение в торгах. Единственный действенный рычаг кандидата при обсуждении условий работы — его готовность развернуться и уйти.
Но к концу испытательного срока у кандидата не остается никаких козырей. Других предложений у него нет, он уже вложил в проекты этой компании десятки (если не сотни) часов.
У кандидата появляется стимул принять оффер, даже если в других условиях он бы его не принял. Альтернатива — вернуться на рынок труда и начать поиски с нуля.
Да, собеседования с решением задач на доске не идеальны. Но я предпочел бы пройти сотню сеансов вайтбоардинга, но не заключать контракт на испытательный срок.
Итак, какой же вариант — самый лучший?
Наверняка вы угадали: это зависит от обстоятельств.
Основной компромисс здесь между скоростью (+потраченными усилиями) и точностью. Каждый метод жертвует одним ради другого. И каждая компания сама выбирает, чем она готова пожертвовать. Скорее всего, процедура собеседований в SpaceX будет отличаться от процедуры небольшого стартапа в Нью-Йорке.
Но когда в SaaS-компании разработчиков на собеседовании просят писать алгоритмы динамического программирования, это должно быть для определения их инженерных навыков. Не просто потому, что так делает Google.
Если бы я разрабатывал процедуру собеседований для своей команды в DigitalOcean, я бы использовал смесь тестовых заданий и задач на программирование. А понимание распределенных систем я бы оценивал при помощи сессий вопросов и ответов, а также задач по дизайну систем.
Но моя команда и так все это делает. Жесткий, но справедливый процесс собеседований в DigitalOcean стал одной из причин, по которой я принял их оффер. Я увидел, что они уже прошли стадию становления и определились, как им справедливо оценивать своих кандидатов.
Наконец, обращаюсь ко всем коллегам-разработчикам, которые хотят изменений в процедурах собеседований. Начинайте предлагать идеи. Очень многие программисты ворчат по поводу собеседований с вайтбоардингом, но когда попадают в штат компании, продолжают эту практику, потому что ее изменение требует усилий.
Не надо так. Прекратите жаловаться. Ищите решения.
А какой метод проведения собеседований вы предпочитаете? Белая доска, задачи на программирование, выполняемые на компьютере, тестовые задания, испытательный срок? Может, у вас есть свои оригинальные идеи? Поделитесь в комментариях!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]