Плохой код на маленькой задаче становится риском бизнеса

Разработчик внес изменение в форму заказа. Проверил на маленьком объеме - всё открылось, кнопки нажались, задача ушла как выполненная.

Когда пользователи открыли реальные заказы, всё начало тормозить. У всех. Процесс пришлось срочно откатывать.

Проблема была не в умении писать код. Человек проверил решение как учебную задачу, а не как часть производственного контура. На маленьком объеме ошибка выглядела безобидно. На реальном - остановила работу людей.

После этого я перестал тратить длинное собеседование на то, что можно увидеть за час.

Кому давал тестовое и зачем

Тестовые задания я давал не всем.

В основном - middle и senior-разработчикам на 1С, Python/SQL, если роль была связана с остатками, заказами, кассами, обменами и управленческой отчетностью.

Задача - примерно на час. Маленькая. Почти детская. Но такая, где почти невозможно спрятать способ мышления.

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

Меня интересовала не только цифра в ответе. Иногда я брал людей с неправильной цифрой - если логика была здравая, ошибку можно было разобрать.

Самое показательное решение

Самое эпичное решение, которое я видел, - через декартово произведение каждой секунды за 10 дней.

Человек разложил период на секунды и считал остаток на каждом шаге.

На тестовом хлебе это выполнится. На реальной сети - нет.

Если перенести такую логику в боевой контур, начинается другая история. Ночной расчет не успевает закончиться до открытия магазинов. Остатки считаются неверно. Заказы формируются с ошибками. Где-то появляется пустая полка при наличии товара «по системе». Где-то заказывается лишнее. Операционный директор перестает верить отчету.

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

Почему разговор на собеседовании не всегда помогает

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

На задачах с данными ошибка редко выглядит как «система упала». Чаще она тише: отчет сошелся, но неправильно; остаток есть, но на полке пусто; заказ сформировался, но не туда; управленческий отчет вышел утром, но доверия к нему уже нет.

Сбой видно. Плохую логику в данных часто видно только через последствия.

Почему 80% не доходили до собеседования

Примерно 80% кандидатов после тестового до собеседования не доходили. Я давал обратную связь почему.

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

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

Разработчик может не знать всю розницу. Но senior на задачах с данными должен чувствовать масштаб и последствия своей логики.

Почему неправильная цифра не всегда отказ

Иногда я брал людей с неправильной цифрой.

Был кандидат, который допустил минусовые остатки. Формально ответ неправильный. Но алгоритм решения был сильным: человек видел структуру задачи, масштабирование, проверку данных, отделял расчет от представления и быстро понял, где нужна бизнес-оговорка.

Такого кандидата можно брать.

Ошибка в тестовом - это еще не провал. Провал - когда человек не понимает, почему это ошибка, и не видит, как его решение поведет себя на масштабе.

Неправильная цифра - повод разобраться. Декартово произведение секунд для senior-роли на задачах с данными - автоотказ.

Цена ошибки найма

Бизнес платит дважды.

Первый раз - ФОТ разработчика, который не подошел. Для Middle по рынку это 134-229 тыс. руб. в месяц. За 6-9 месяцев до момента, когда стало понятно, что человек не тот - 800К-1,5М руб. только в зарплате. Плюс время тимлида на онбординг, разбор кода, объяснение контура.

Второй раз - изменения в ИС, которые бизнес за эти месяцы не получил.

Автоматизация заказов, которую ждал операционный директор. Корректные остатки, по которым категорийный менеджер принимал решения вручную. Кассовая аналитика, которой не было. Управленческая отчетность, которую собирали в Excel.

За эти месяцы решения принимались по неверным данным или не принимались вообще.

Тот кандидат с секундами прошел бы в найм - и эти 6-9 месяцев бизнес ждал бы корректного ночного расчета. Дождался бы остановки магазинов в день запуска.

Испытательный срок этого не страхует. Разработчик выходит на полную продуктивность за 6-9 месяцев. Плохое решение в данных обычно выглядит нормально - до первого реального масштаба.

Где тестовое уместно

Тестовое не нужно всем и всегда.

Джуну чаще нужна другая точка проверки: обучаемость, базовая логика, внимательность, способность принимать обратную связь.

Задача на 8 часов и задача, которая по факту является бесплатным куском продукта, дискредитируют инструмент. Обратная связь после тестового обязательна - без нее у компании нет морального права тратить время кандидата.

Но короткая задача на 30-60 минут для middle или senior-разработчика, который пойдет в данные, остатки, заказы, кассы или управленческую отчетность, честнее длинного разговора. Она показывает не презентацию опыта, а рабочий способ мышления.

Пример тестовой задачи

На утро 1-го числа на остатке было 10 булок хлеба.

Спрос по дням:

Поставки приходят к началу рабочего дня:

Задача:

1. Посчитать остаток хлеба на конец 10-го дня.
2. Вывести таблицу остатков на конец каждого дня.
3. Предоставить код.

Задача намеренно простая. В ней проверяется не знание редкого алгоритма, а базовая инженерная дисциплина: учет событий по времени, проверка результата, работа с отрицательными остатками, масштабируемость решения - и понимание того, что за таблицей стоит реальный операционный контур.

Чем тестовое отличается от кейса для руководителя

С руководителями и руководителями проектов логика другая. Там нет кода.

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

С разработчиком на данных другой фокус: думает ли он о масштабе последствий, проверяет ли логику на граничных условиях, понимает ли, что таблица - часть производственного контура.

Вывод для CEO

Тестовое задание само по себе не хорошее и не плохое.

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

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

Плохой код редко остается в коде. На масштабе он приходит в P&L через пустую полку, лишний заказ, ручной обход и отчет, которому бизнес больше не верит.