Много лет назад я работал в Датаарте, писал код на Питоне. В какой-то момент мне доверили собеседовать кандидатов, и я заинтересовался темой. Смотрел видео, читал материалы и писал в блог по тегу interview. Считал, что хорошо разбираюсь в собеседованиях и все такое.

В выходом на удаленку я перестал собеседовать. Так складывается, что я пишу код, а решения о найме принимают другие люди. К тому же со временем мои взгляды на собеседование сильно изменились. Ниже — мысли о том, как я вижу собеседование сегодня. Как бы я собеседовал кандидата в свою воображаемую фирму, которой, конечно, у меня нет и вряд ли когда-то будет.

Итак, цель собеседования в том, чтобы определить, подходит кандидат или нет. Однако редко кто из собеседующих понимает суть процесса. Кандидату задают расплывчатые вопросы, ответы на которые прикидывают “на глазок”. Часто бывает, что один неудачный ответ затмевает остальные и собеседующий помнит только его. Или наоборот: кандидат не умеет писать код, но понравился эйчару манерой общения.

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

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

На последнем собеседовании спросили, какую проблему в айти я бы решил, если б имел неограниченные ресурсы. Тоже наплел ахинею про зависимости, пакеты и прочее. Прошел, вот сижу и пишу на Кложе. Спрашивается, если бы не наплел, хуже бы тогда писал?

Еще одна категория вопросов, которые не стоит задавать — это родимые травмы языков. Например, что получится, если сложить объект и массив в Javascript? Не заглядывая в консоль Хрома, подумайте и объясните, какой будет результат и почему не иначе:

{} + {}

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

Приведу пример из Python, который задавал всем кандидатам на этот язык. Предположим, нужна холостая лямбда, которая не делает ничего. Можно ли описать ее как в коде ниже и что случиться, если его запустить?

nope = lambda: pass

Другой вариант этой задачи: лямбда, которая всегда бросает исключения:

riser = lambda x: raise Exception(x)

Прежде чем читать далее, предлагаю подумать и вам.

Ответ: код не запустится из-за ошибки синтаксиса. Анонимная функция в Питоне устроена так, что в теле может быть только выражение. В нашем случае pass и raise — это операторы, а не выражения, отсюда ошибка компиляции. Чтобы первая лямбда работала, нужно заменить pass на None.

Разумеется, ни один кандидат не ответил без подсказок, а я гордился, что знаю такое поведение. Хотя очевидно, это бред: что мешает поправить компилятор так, чтобы pass в лямбде возвращал None? Это дело нескольких строк, просто никому нет дела. Поэтому не парьте мозги окружающим.

В крупные компании, куда стоят толпы народу, практикуют метод “нам не нужны неудачники” из известного анекдота. Не смог перестроить красно-чёрное дерево на бумаге? Пошел вон. И неважно, что в будущем будешь перекладывать протобуфы из Кафки в базу — нужно как-то отсеять желающих. Эйчаров на всех не хватает, а искусственный интеллект, как обычно, заработает не сейчас, а в скором будущем (сейчас он работает, но неправильно: выбирает белых образованных мужчин).

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

Знакомый собеседовался в Яндекс на высокую должность. Архимаг по алгоритмам дал задачу на поиск строки с мудреными ограничениями. Главный критерий был в том, чтобы решить за O(N), а все очевидные решения давали квадрат. Эту задачу мы решали всем чатом, но так и не нашли ответа с O(N). Должности в Яндексе знакомый не получил.

Оглядываясь на этот эпизод, пытаюсь понять, какой в этом смысл? Зачем мучить человека одной задачей в течение часа? Разве сотрудник Яндекса работает в таких же условиях? — его заводят в комнату на час, и если он не найдет алгоритм, увольняют? Уж наверное он общается с коллегами, ходит в курилку и все такое. Почему кандидат, который был в шаге от решения, не имел возможности даже пройтись по комнате? Все тот же критерий неудачника.

Требовать от кандидата решить задачу на время значит поставить его в неудобное положение. Каждому известно, что мозг работает в двух режимах: сфокусированном и рассеянном. Их комбинация и продолжительность зависят от генетики. Возможно, кандидат нашел решение сразу после ответа “мы вам перезвоним”. Может быть, ему нужно сходить до туалета, чтобы смочить лицо. Или в магазин за молоком. Может, его знакомый уже решал такую задачу и может за пять минут поделиться опытом. Но собеседующего это не волнует: часы затрекал, таску закрыл.

Бинарная оценка — решил/не решил — по своей сути не отличается от оценки по размеру груди, знаку зодиака или цвету волос кандидата. Так можно, если вы условный Яндекс. Но важно понимать, что в основе этой градации лежит дурацкий принцип и пренебрежение к людям.

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

На роль усложняемой задачи подходит всем известный FizzBuzz. И хотя многие о нем слышали, редкий кандидат решит его без ошибок. Подвох FizzBuzz в том, что, как правило, кандидат пишет логику как слышит, то есть проверяет сперва на 3, потом на 5, а затем на оба числа:

for x in range(1, 101):
    elif x % 3 == 0:
        print("Fizz")
    elif x % 5 == 0:
        print("Buzz")
    if x % 3 == 0 and x % 5 == 0:
        print("FizzBuzz")
    else:
        print(x)

Первое же число, которое делится на 3 и 5 — это 15 — даст сбой: для него сработает первая ветка, и вместо FizzBuzz получим Fizz. В этом нет ничего страшного, гораздо важнее, как довести ошибку до кандидата и оценить его действия.

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

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

Дополнительно можно спросить про SQL и оператор JOIN. Если кандидат выбрал пользователей и профили одним запросом с LEFT JOIN, это вообще круто. Отпадают все сомнения.

Если FizzBuzz приелся, замените его на другое задание с подвохом — факториал. Написать его можно сотней способов — apply, loop, recur — и каждый дает пищу для размышлений (например, хвостовая рекурсия: что такое, примеры). Подвох в том, что факториал нуля равен единице, и редкий кандидат помнит об этом. Как и в случае с FizzBuzz, предложите найти ошибку. Как будет лучше ее исправить? Добавить if/else или вести счетчик от нуля? Поправить аккумулятор? И конечно, написать и запустить тесты.

В таких заданиях я смотрю не столько на решение, сколько на принцип работы кандидата. Настроена ли у него среда разработки? Если он претендует на Кложу, а пишет код в блокноте, мягко говоря, это сомнительно. Как он работает с REPL-ом? Как выполняет код из редактора? Как запускает тесты — и пишет ли их в принципе? Простой FizzBuzz даст на порядки больше информации, чем зубодробилка с O(N).

Если вам интересно, моя градация следующая. Не смог написать FizzBuzz или факториал — извини, к нам еще рано. Если смог и исправил ошибку — джун. То же самое плюс варианты решений — мидл. Смог тесты — заявка на сеньора. Смог SQL — дай тебя поцелую!

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

В заключение — краткие тезисы.

  • От кандидата вас интересует его последний год. Прерывайте, если он рассказывает, как заводил Doom на утюге в 11 лет. Это никому не интересно.
  • Программиста берут, чтобы он писал код и тесты. Еще до собеседования попросите кандидата поделиться кодом. Подойдут гитхаб или приватные гисты. Если кода нет вообще никакого, это странно.
  • Дайте простую задачу, в которой, тем не менее, легко ошибиться. Оцените, как кандидат найдет ошибку и исправит ее.
  • Считаю, что тесты обязательны. Программист, который с ними не знаком, претендует в лучшем случае на мидла.
  • Полезно узнать навыки SQL. База встречается почти в каждом проекте, чего не скажешь про Кафки-Редисы. Эти опционально.

Как-то так.

← Аватар 2

Спасибо, что →