AndrewKozlov
New member
Помню свой самый болезненный найм за последние годы. Кандидат на позицию бэкенд-разработчика отщёлкал на созвоне три задачи про деревья и динамическое программирование быстрее, чем я успевал дописать условие второй. Мы оба остались довольны друг другом, оффер ушёл в тот же вечер, а через полтора месяца я сидел и разбирал его пул-реквест, где на сорок строк логики приходилось триста строк копипасты, а тестов не было вообще. Тогда я понял простую вещь: я проверял не то, что мне на самом деле нужно.
Проблема не в том, что алгоритмы бесполезны. Она в том, что рынок научился готовиться к ним массово. Есть горы задачников, есть расписанные по шагам разборы, есть десятки часов видео, где за тебя проговаривают ход мысли. Человек может честно выучить этот жанр и всё равно развалиться на первой же задаче, где условие сформулировано нечётко, а исходный код написан пять лет назад и никем не документирован. Собеседование на алгоритмы проверяет способность тренироваться к собеседованиям на алгоритмы. Замкнутый круг, и он мне дорого обошёлся.
Поэтому я перестал изобретать и стал показывать реальность. Даю кандидату небольшой фрагмент нашего настоящего кода, вырезанный из живого сервиса, с настоящими странностями внутри. Прошу найти баг, который привёл к инциденту на прошлой неделе, и рассказать, как он рассуждает. Никакого таймера, никакого редактора по памяти, интернет разрешён, документация разрешена, спросить меня тоже можно. Мне интересно не «решил или нет», а как человек ориентируется в чужом коде и что он делает, когда застревает.
Второй мой инструмент — короткое оплачиваемое тестовое на пару часов. Мы платим за него по нашему же часовому рейту, потому что уважаем время человека, и результат остаётся у него. Задача формулируется как настоящая рабочая: добавить небольшую функцию, не сломав существующее поведение, и объяснить, какие решения он принял и почему. Меня там больше всего интересуют даже не сами решения, а то, что лежит рядом: названия, разбиение на функции, обработка ошибок, наличие хотя бы одного теста, аккуратный коммит с внятным сообщением. По этим мелочам навык виден куда честнее, чем по скорости вычисления сложности алгоритма.
Ещё я спрашиваю про свои проекты и про боль. Прошу рассказать о самом неприятном баге, который он ловил, и о том, что он сделал, чтобы такое не повторилось. Прошу объяснить чужое решение, которое ему кажется плохим, и предложить альтернативу с плюсами и минусами, а не с одним «так правильнее». Хорошие разработчики в такие моменты начинают рассуждать, уточнять условия и признавать, что не знают. Плохие — выдают гладкий ответ без единого сомнения. Уверенное незнание с честным «я бы проверил вот это» стоит для команды гораздо дороже, чем отрепетированный рассказ о том, как устроен красно-чёрный лес.
Отдельно скажу про процесс, потому что тут легко скатиться в самодурство. Заранее скажите кандидату, что именно будет на этапах и сколько времени это займёт. Не давайте тестовое на выходные без оплаты и не просите бесплатно сделать «мини-проект на недельку». Не устраивайте допрос у доски, если ваш продукт пишется не у доски. Не превращайте этап в проверку стрессоустойчивости — на реальной работе стресс приходит от инцидентов, а не от интервьюера, который перебивает и посматривает в телефон. И обязательно дайте нормальный фидбек тем, кто дошёл до финала: рынок маленький, а репутация компании живёт дольше, чем закрытая вакансия.
Итог за несколько лет такой практики простой. Инженерное интервью стоит строить вокруг того, что человек будет делать каждый день: читать чужой код, принимать решения в условиях неполной информации, объяснять свои мысли коллегам и оставлять после себя понятные следы. Алгоритмы оставьте как один из инструментов, а не как вступительный экзамен в профессию. У меня с тех пор ни один такой найм не развалился в первые полгода, а пара кандидатов, которых я когда-то забраковал за неидеальную сложность решения, потом сами сказали, что ценили именно честность процесса. Это, если хотите, и есть главный аргумент.
А теперь вопрос к вам, коллеги. Какой самый неожиданный и при этом полезный тест вы давали кандидату? Может, это была задача про чтение логов, разбор чужого коммита или что-то совсем нестандартное вроде объяснения архитектуры своему будущему тимлиду? Поделитесь, что реально помогло вам отличать крепкого инженера от отлично натренированного соискателя — уверен, у каждого на форуме найдётся история, которая сэкономит коллегам месяц нервов и денег.
Проблема не в том, что алгоритмы бесполезны. Она в том, что рынок научился готовиться к ним массово. Есть горы задачников, есть расписанные по шагам разборы, есть десятки часов видео, где за тебя проговаривают ход мысли. Человек может честно выучить этот жанр и всё равно развалиться на первой же задаче, где условие сформулировано нечётко, а исходный код написан пять лет назад и никем не документирован. Собеседование на алгоритмы проверяет способность тренироваться к собеседованиям на алгоритмы. Замкнутый круг, и он мне дорого обошёлся.
Поэтому я перестал изобретать и стал показывать реальность. Даю кандидату небольшой фрагмент нашего настоящего кода, вырезанный из живого сервиса, с настоящими странностями внутри. Прошу найти баг, который привёл к инциденту на прошлой неделе, и рассказать, как он рассуждает. Никакого таймера, никакого редактора по памяти, интернет разрешён, документация разрешена, спросить меня тоже можно. Мне интересно не «решил или нет», а как человек ориентируется в чужом коде и что он делает, когда застревает.
Второй мой инструмент — короткое оплачиваемое тестовое на пару часов. Мы платим за него по нашему же часовому рейту, потому что уважаем время человека, и результат остаётся у него. Задача формулируется как настоящая рабочая: добавить небольшую функцию, не сломав существующее поведение, и объяснить, какие решения он принял и почему. Меня там больше всего интересуют даже не сами решения, а то, что лежит рядом: названия, разбиение на функции, обработка ошибок, наличие хотя бы одного теста, аккуратный коммит с внятным сообщением. По этим мелочам навык виден куда честнее, чем по скорости вычисления сложности алгоритма.
Ещё я спрашиваю про свои проекты и про боль. Прошу рассказать о самом неприятном баге, который он ловил, и о том, что он сделал, чтобы такое не повторилось. Прошу объяснить чужое решение, которое ему кажется плохим, и предложить альтернативу с плюсами и минусами, а не с одним «так правильнее». Хорошие разработчики в такие моменты начинают рассуждать, уточнять условия и признавать, что не знают. Плохие — выдают гладкий ответ без единого сомнения. Уверенное незнание с честным «я бы проверил вот это» стоит для команды гораздо дороже, чем отрепетированный рассказ о том, как устроен красно-чёрный лес.
Отдельно скажу про процесс, потому что тут легко скатиться в самодурство. Заранее скажите кандидату, что именно будет на этапах и сколько времени это займёт. Не давайте тестовое на выходные без оплаты и не просите бесплатно сделать «мини-проект на недельку». Не устраивайте допрос у доски, если ваш продукт пишется не у доски. Не превращайте этап в проверку стрессоустойчивости — на реальной работе стресс приходит от инцидентов, а не от интервьюера, который перебивает и посматривает в телефон. И обязательно дайте нормальный фидбек тем, кто дошёл до финала: рынок маленький, а репутация компании живёт дольше, чем закрытая вакансия.
Итог за несколько лет такой практики простой. Инженерное интервью стоит строить вокруг того, что человек будет делать каждый день: читать чужой код, принимать решения в условиях неполной информации, объяснять свои мысли коллегам и оставлять после себя понятные следы. Алгоритмы оставьте как один из инструментов, а не как вступительный экзамен в профессию. У меня с тех пор ни один такой найм не развалился в первые полгода, а пара кандидатов, которых я когда-то забраковал за неидеальную сложность решения, потом сами сказали, что ценили именно честность процесса. Это, если хотите, и есть главный аргумент.
А теперь вопрос к вам, коллеги. Какой самый неожиданный и при этом полезный тест вы давали кандидату? Может, это была задача про чтение логов, разбор чужого коммита или что-то совсем нестандартное вроде объяснения архитектуры своему будущему тимлиду? Поделитесь, что реально помогло вам отличать крепкого инженера от отлично натренированного соискателя — уверен, у каждого на форуме найдётся история, которая сэкономит коллегам месяц нервов и денег.