В последнее время у меня ощущение, что на рынке разработки что-то «сломалось»
Нанимают как будто бы только сеньоров. Требования на сеньора ниже, чем на джуна, с учетом конкуренции. Из-за этого опыт начинают крутить почти все новички: те, кто не делает этого сразу, часто не находят работу и в итоге приходят к тому же.
Можно представить, что это новая система сдержек и противовесов, где все врут, знают об этом, и в итоге оцениваются реальные знания. Но нет: оценивается только умение себя подать, подстроиться под все искусственные барьеры, не связанные с реальностью.
Моя интуиция подсказывает, что есть ребята с небольшим опытом, но умеющие писать код и справляться с большинством задач. Я начал думать, как можно объективно оценить умение программировать.
Но для начала нужно было определиться: кто вообще нужен?
Мне ни разу за 7,5 лет не приходилось писать сортировку в блокноте. Зато постоянно приходилось разбираться в чужом legacy-коде, вносить небольшие, но опасные изменения, чинить интеграции, вытаскивать вменяемую структуру из монолитов и по мере необходимости решать инфраструктурные задачи. Архитектурные проблемы в реальной работе почти никогда не выглядят как олимпиадная задача. Обычно это что-то вроде: “вот старый сервис, вот бизнес-требование, вот ограничения по времени, нужно сделать так, чтобы не развалилось”.
Ситуацию дополнительно меняет то, что нейросети уже заметно обесценили часть “лобовых” знаний и сильно ускорили написание кода. Но это не означает, что инженерное мышление стало неважным. Скорее наоборот: теперь особенно важно отличать человека, который осознанно использует AI как инструмент, от человека, который просто генерирует красивый код без понимания границ решения, рисков и компромиссов.
Я не придумал ничего лучше тестового задания. Но тестовое хотелось сделать не учебным, а максимально приближенным к тому, что реально встречается в работе backend-разработчика.
Почему именно рефакторинг, а не задача "с нуля"
Давать абстрактную задачу на алгоритмы мне не хотелось. В реальной жизни backend-разработчик гораздо чаще не проектирует идеальную систему на белом листе, а приходит в уже существующий проект и начинает его постепенно приводить в порядок.
Поэтому я сделал тестовое в формате рефакторинга. Исходной точкой был намеренно плохо спроектированный монолит интернет-магазина на Django. Я специально сделал его “неровным”: с плотной связностью компонентов, смешением бизнес-логики и HTTP-слоя, спорными зависимостями между модулями и местами, где легко наделать ошибок в согласованности данных.
Задача кандидата была не просто “переписать Django на FastAPI”, а декомпозировать этот монолит в вменяемый backend-проект с понятной структурой и современными практиками разработки.
Минимально я ожидал от решения следующие вещи:
перенос ключевой бизнес-логики из монолита в новый сервис;
нормальную структуру проекта, где HTTP-слой не смешан с доменной логикой;
работу с БД через явный слой доступа, а не хаотичные запросы из обработчиков;
валидацию входных данных;
понятную обработку ошибок;
запуск проекта одной командой;
конфигурацию через переменные окружения;
хотя бы базовую контейнеризацию;
использование кеширования и очередей обработки там, где это действительно имеет смысл.
Но основное, что я хотел проверить с помощью тестового - это как мыслит человек, его подход к работе. Выбор конкретной архитектуры и подходов был за кандидатом. Какая архитектура, что покрыть тестами, использовать ли SAGA, как организовать авторизацию и тд - полная свобода творчества. Так же с помощью этого проверяется ответственность за свое решение - нужно было все же сохранить бизнес логику и сделать так чтобы это все работало без критических багов.
То есть сначала я оценивал так как будет оценивать заказчик - все ли работает так как задумано со стороны клиента. Потом как инженер - на сколько поддерживаемо и оправно решение.
Так же важным этапом было суметь объяснить написанное и обосновать выбор тех или иных решений, предложить как можно дальше развивать проект.
Меньше чем через неделю я получил первые ответы по тестовому
Честно, я не ожидал, что код вообще запустится или будет состоять не только из багов, но, к моему удивлению, все проекты запустились, и где-то треть была сделана без критических ошибок. Встречались, конечно, и грубые недоработки, типа полностью открытых методов, отсутствия согласованности данных и т. д.
Но были и правда отличные решения: например, когда человек использовал API Gateway с проверкой токенов, хотя напрямую об этом не было сказано, использовал чистую архитектуру, грамотно построил взаимодействие с Kafka.
Что же насчет собеседований? Тут я был просто уверен, что большинство не сможет и пары слов связать в ответ на вопрос, что же это такое было навайбкожено. Особенно в случаях, когда решения выглядят слишком уж вылизанно.
Как ни странно, я получил абсолютно обратный эффект: кандидаты в большинстве случаев адекватно объяснили, что и как они делали.
Еще удивительнее было то, что опыт в разработке тут вообще не сыграл никакой роли. Лучшее решение, которое я упоминал вскользь, предоставил студент без какого-либо коммерческого опыта. Также он хорошо объяснил, как устроен проект, как он поэтапно, где-то советуясь с нейронкой, создал этот проект.
Что в итоге?
Я убедился в том, что критерии, на которые сейчас опирается найм, и то, что реально нужно от кандидата, — совершенно не связанные вещи.
Убедился, что есть множество людей, которые умеют работать, но не могут найти работу, потому что не накрутили себе еще 5+ лет опыта.
Да, с оговорками: я бы не отдал джунам строить архитектуру и решать по‑настоящему сеньорские задачи. Но, может, раз 90% задач по силам многим, то пусть сеньоры займутся именно тем, где они действительно нужны.
Раз я нашел людей, которые могут работать дешевле рынка раза в два, то ищу для этих людей проект. Да, я планирую открыть еще одну галеру, но, может быть, она хоть немного починит найм.