Найти тему
КОСМОС

Секретный код собеседования, который означает, что вы провалились

Оглавление

Я далеко не совершенен.

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

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

«Мне интересно, почему…»

Как только эта фраза произносится, шансов на успешное собеседование уже нет.

Вот что происходит, почему я в недоумении, что это допускается на собеседованиях, и в конце предложу свое решение.

Ситуация

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

-2

Возьмем мои техтесты, которые я делал несколько лет назад, когда был менее опытен (так что, пожалуйста, не судите меня строго).

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

Я понял, что это просто потому, что на тот момент я был немного "зеленым". То, что я не закрывал свойства, показывало, что при первом написании кода я просто хотел, чтобы он работал, а уже потом думал о таких вещах, как контроль доступа, как о чем-то «желательном». Поэтому я исправлял это в конце разработки, и иногда мог пропустить один или два класса в своей сдаче. [Примечание: сегодня я могу находить такие ошибки с помощью ИИ в своем коде, и я также изменил свой стиль работы, так что не волнуйтесь].

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

Техническое собеседование

На техсобеседовании происходит одно из двух:

  1. Интервьюер не замечает этих мелких ошибок.
  2. Интервьюер замечает ошибку, и у вас больше нет шансов пройти собеседование.
-3

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

Второй случай — когда интервьюер останавливается и спрашивает:

«Мне интересно, почему эти свойства доступны извне класса.»

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

Как только вам задают вопрос «Мне интересно, почему…», собеседование закончено.

Проблема

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

-4

В приведенном выше примере с контролем доступа неправильно делать свойства доступными извне, если их можно сделать приватными. Но код работает, и это та мелкая ошибка, которую можно было бы найти на кодревью. Все совершают ошибки, и в 1000 строк кода, написанных после работы, сколько таких ошибок допустимо? Если ответ — ноль, зачем нам кодревью?

Это означает, что один член команды «пропустил» код и кандидата на следующий этап, но затем другой член команды снова проверил код и «провалил» его.

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

Моя любимая обратная связь: «Не знает достаточно о хороших практиках разработки программного обеспечения.»

Вздох. Просто скажите, что я делаю слишком много ошибок.

Решение

Почему нет человека, который контролирует процесс от начала до конца?

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

Вопрос: где в этом процессе HR?

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

Заключение

Сейчас я работаю над методами, чтобы не делать ошибок в техтестах. Конечно, это означает использование ИИ и привлечение людей для проверки моей работы.

Я бы хотел, чтобы собеседования были больше похожи на мою повседневную работу. Почему бы, например, не разрешить использовать ИИ на собеседованиях?