Найм в 2к26. Что меня удивило больше всего

Я нанял 6 программистов в 2026 году и сделал страшные выводы... 

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

За первые два дня после публикации вакансии пришло более 400 откликов. 

За первые 2 дня — это сумасшедшая цифра... 

Ладно, собрался, отфильтровал, осталось около 300. 

Заметка: Я принципиально не использую ИИ для отбора резюме. Каждое открываю и просматриваю сам. Возможно, это занимает больше времени, но пока мне важно самостоятельно понимать, кто именно приходит на собеседование.

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

Глубина знаний

Я практически никогда не спрашиваю то, что не понадобится в работе.

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

Усредненный кандидат: 3 — 5 лет работы с go, столько же с pgsql. 

Вопрос который ставит многих в тупик: Как перехватывается panic и как работает defer?

Рассуждения: Примерно 9 из 10 кандидатов не могут дать полный ответ.

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

defer, panic и recover — это не вопросы уровня знаний внутреннего устройства языка. Это функции, с которыми разработчик сталкивается очень часто. 

Рано или поздно почти каждый пишет go‑рутину, внутри которой возникает panic, после чего неожиданно падает весь сервис. Всегда начинаешь разбираться, почему так произошло, в каком порядке вызываются defer, как работает recover и почему он не сработал с функции инициировавшей go‑рутину (если таковой там имелся). 

Аналогично defer встречается в каждом проекте: закрытие файлов, работа с БД, работа с пакетом net, освобождение ресурсов, работа с мьютексами. Это один из самых часто используемых механизмов языка.

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

Не менее удивительной оказалась ситуация с PgSQL.

Я не спрашиваю про тонкости MVCC, внутреннее устройство планировщика запросов или нюансы WAL (хотя с одним из 20+ кандидатов мы дошли до обсуждения и таких моментов).

Но если в резюме написано: несколько лет ежедневно работал с PgSQL, я ожидаю уверенное понимание вещей, без которых сложно представить разработку любого продукта:

• Работа со стандартными запросами CURD 

• JOIN механизмы

• CTE запросы

• Понимание транзакций

И именно здесь меня снова ждал сюрприз. Даже на эти вопросы не всегда удавалось получить ответы.

Чтобы не создавалось впечатление, что все кандидаты такие, сразу скажу: нет.

Среди кандидатов были сильные разработчики. Были люди, которые признавали пробелы в знаниях, но спустя какое то время начинали рассуждать. Да, рассуждениями тонкости языка вряд ли получится узнать, но всё таки.

И именно это сегодня я ценю выше всего в подобных ответах, что кандидат не сдается.

Отношение к работе

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

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

• Вовлеченности в проект

• Участия в технических обсуждениях

• Желания разобраться в существующей архитектуре

• Стремления выполнять задачи в срок (при этом я никогда не ставлю заведомо нереалистичные сроки и всегда готов обсуждать их заранее)

• Максимально качественного кода на текущем уровне знаний

Показать максимум, чтобы закрепиться на новом месте.

К сожалению, все чаще я сталкиваюсь с обратными показателями:

• Плохое качество выполнения базовых задач

• Повсеместное использование ИИ‑агентов

• Желания понять продукт, архитектуру или причины тех или иных решений практически нет

• А спустя некоторое время становится очевидно, что собеседование прошло успешнее, чем реальная работа: знания и самостоятельность оказываются заметно ниже, чем казалось на собеседовании

И, пожалуй, именно последний пункт меня расстраивает больше всего. Не потому, что человек чего‑то не знает. А потому, что желание разобраться и вырасти оказывается слабее желания просто закрыть задачу любым способом…

ИИ — агенты

Рынок диктует: используй ИИ для увеличения своей продуктивности, кто не использует ИИ отстал от современных стандартов разработки. И это действительно так, не использование помощника (который зачастую дается бесплатно для разработчика) не оправданное опущение. 

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

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

В результате получается довольно странная цепочка. 

• Включил агента

• Скопировал задачу и сгенерировал код

• Написал тесты через агента на написанный агентом код 

• Сдаешь тестировщику, который в свою очередь также может использовать ИИ для тестирования. 

Когда вскроется, что код работает с багами зависит от задачи. И кто в этой цепочке действительно понимает, что именно происходит?

С точки зрения разработчика задача закрыта, кто будет проверять мержи сгенерированные агентом? Никто, только такой же агент. 

Именно это меня беспокоит больше всего. Не использование ИИ. А постепенная потеря привычки думать самостоятельно.

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

Эпилог

Я люблю число 3 и остановлюсь именно на этих трёх пунктах, но тенденция меня пугает. 

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

ИИ постепенно развращает и новых, и опытных разработчиков. Он мотивирует не брать на себя ответственность за принятые решения, не искать информацию самостоятельно, не пытаться понять, почему решение работает именно так. 

Но я до сих пор не могу понять: в какой момент произошла деградация обучения?

Ведь тот же ИИ открывает огромные возможности для саморазвития. Да, он может ошибаться. Точно так же когда‑то ошибались статьи, ответы на форумах и случайные советы из интернета от «рандомного индуса» (это интернет‑мем, а не отсылка к национальности).

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

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

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

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

Будем честны, не только программисты идут по этому пути.

Но именно в разработке цена такого подхода может оказаться особенно высокой.