В последнее время у меня ощущение, что на рынке разработки что-то «сломалось»

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

Моя интуиция подсказывает, что есть ребята с небольшим опытом, но умеющие писать код и справляться с большинством задач. Я начал думать, как можно объективно оценить умение программировать.

Но для начала нужно было определиться: кто вообще нужен?

Мне ни разу за 7,5 лет не приходилось писать сортировку в блокноте. Зато постоянно приходилось разбираться в чужом legacy-коде, вносить небольшие, но опасные изменения, чинить интеграции, вытаскивать вменяемую структуру из монолитов и по мере необходимости решать инфраструктурные задачи. Архитектурные проблемы в реальной работе почти никогда не выглядят как олимпиадная задача. Обычно это что-то вроде: “вот старый сервис, вот бизнес-требование, вот ограничения по времени, нужно сделать так, чтобы не развалилось”.

Ситуацию дополнительно меняет то, что нейросети уже заметно обесценили часть “лобовых” знаний и сильно ускорили написание кода. Но это не означает, что инженерное мышление стало неважным. Скорее наоборот: теперь особенно важно отличать человека, который осознанно использует AI как инструмент, от человека, который просто генерирует красивый код без понимания границ решения, рисков и компромиссов.

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

Почему именно рефакторинг, а не задача «с нуля»

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

Поэтому я сделал тестовое в формате рефакторинга. Исходной точкой был намеренно плохо спроектированный монолит интернет-магазина на Django. Я специально сделал его “неровным”: с плотной связностью компонентов, смешением бизнес-логики и HTTP-слоя, спорными зависимостями между модулями и местами, где легко наделать ошибок в согласованности данных.

Задача кандидата была не просто “переписать Django на FastAPI”, а декомпозировать этот монолит в вменяемый backend-проект с понятной структурой и современными практиками разработки.

Минимально я ожидал от решения следующие вещи:

• перенос ключевой бизнес-логики из монолита в новый сервис;

• нормальную структуру проекта, где HTTP-слой не смешан с доменной логикой;

• работу с БД через явный слой доступа, а не хаотичные запросы из обработчиков;

• валидацию входных данных;

• понятную обработку ошибок;

• запуск проекта одной командой;

• конфигурацию через переменные окружения;

• хотя бы базовую контейнеризацию;

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

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

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

Меньше чем через неделю я получил первые ответы по тестовому

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

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

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

Как ни странно, я получил абсолютно обратный эффект: кандидаты в большинстве случаев адекватно объяснили, что и как они делали.

Еще удивительнее было то, что опыт в разработке тут вообще не сыграл никакой роли. Лучшее решение, которое я упоминал вскользь, предоставил студент без какого-либо коммерческого опыта. Также он хорошо объяснил, как устроен проект, как он поэтапно, где-то советуясь с нейронкой, создал этот проект.

Что в итоге?

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

Убедился, что есть множество людей, которые умеют работать, но не могут найти работу, потому что не накрутили себе еще 5+ лет опыта.

Да, с оговорками: я бы не отдал джунам строить архитектуру и решать по‑настоящему сеньорские задачи. Но, может, раз 90% задач по силам многим, то пусть сеньоры займутся именно тем, где они действительно нужны.

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