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

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

Поэтому ценность разработчика сегодня не просто в умении писать код или знать правильные паттерны. Она в способности доводить задачи до рабочего результата.

Как нанимающий менеджер, я стараюсь находить и продвигать именно таких людей. 

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

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

Это, конечно, не стопроцентная гарантия. Но корреляция оказалась удивительно высокой.

Эти вопросы не про синтаксис и не про правильные формулировки. Их нельзя выучить за вечер перед интервью.

1. Кто отвечает за задачу?  

2. Пишете ли вы unit-тесты?

На первый взгляд — простые вопросы.  

На практике — это быстрый способ понять уровень инженерного мышления.

Вопрос №1. Кто отвечает за задачу?

Как-то я наблюдал две очень похожие ситуации в одной большой компании.

Ситуация №1.

Огромный проект. Много команд: мобильные, бэкенд, инфраструктура, поддержка, аналитики, тестирование. Каждый отвечает за свой кусок.

Пользователь пишет в поддержку: в мобильном приложении не обновляются данные. Поддержка отправляет тикет мобильной команде. Мобильный разработчик пересылает его на бэкенд: «Похоже, бэк не присылает данные», а тот отвечает: «Мы всё отправили в WebSocket, у нас всё нормально». Потом вспоминают, что вебсокет-сервером занимается инфраструктура. Инфраструктура проверяет и говорит, что сервер работает как положено.

Тикет по кругу проходит несколько команд. У каждой со своей стороны всё выглядит нормально. Никто не попытался пройтись по логам, воспроизвести сценарий, решить проблему, все просто закрыли свою задачу с формулировкой: «Проблема не у нас».

Но у пользователя данные всё так же не обновляются.

Ситуация №2.

Та же компания и проект, но другая команда.

Приходит тикет: на форме некорректно работает валидация поля. Бэкенд-разработчик начинает разбираться, что происходит. Смотрит, какой паттерн отправляется с сервера и как он используется. Выясняется, что с бэкенда всё приходит корректно, но на фронте на этой форме используются свои правила валидации. Он объясняет фронтенду, где именно возникает проблема. Параллельно заводит тикет в техдолг: перевести платёжные формы на валидацию с бэкенда. И передает его продукту, чтобы задачу включили в работу.

В обеих историях — опытные бэкенд-разработчики. Давно в компании, сильные технически, работают в похожих условиях. Но одна история заканчивается тем, что тикет просто гуляет между командами. А другая — тем, что проблему всё-таки закрывают.

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

Кто отвечает за задачу?

Ответы почти всегда укладываются в две модели мышления.

Первая модель звучит просто: «Я».

И дело не в красивой формулировке. Важно, как человек это произносит и что стоит за этим ответом.

Обычно за таким «я» скрывается позиция владельца результата. Такой разработчик не ждёт идеального ТЗ. Он уточняет требования, если видит пробелы. Поднимает риски, если что-то выглядит хрупким. Спрашивает «а что будет, если…», прежде чем писать код. Проверяет свою функциональность сам, а не перекладывает это целиком на QA. Думает не только о том, чтобы задача закрылась в трекере, а о том, чтобы она продолжала работать после релиза.

Такие инженеры сильнее всего выделяются на фоне остальных. Их компании стараются нанимать и удерживать. И когда начинаются сокращения, именно они обычно остаются последними в списках на выход.

Именно такая проактивность сегодня даёт разработчику большое преимущество перед AI: код он уже умеет генерировать неплохо, но ответственность за результат всё равно остаётся на инженере.

Есть и другая модель.

Человек начинает делить ответственность по ролям: «Я отвечаю за код, дальше — QA», «За требования отвечает аналитик», «Инфраструктура — это не ко мне». Формально всё корректно. В зрелых процессах зоны ответственности действительно распределены.

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

Именно поэтому этот вопрос для меня не про «хороший или плохой». Он про модель ответственности.

Если зона ответственности заканчивается на коммите, в продакшене неизбежно появляются «ничьи» проблемы. А пользователю всё равно, где именно сбой — на клиенте, в инфраструктуре или на бэкенде. Ему важно, чтобы работало.

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

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

Вопрос №2. Пишете ли вы unit-тесты?

Это не про догму «все обязаны писать тесты», а про отношение к коду и к тому, как он будет жить вдолгую.

Разницу в этом отношении я особенно отчётливо увидел несколько лет назад, когда собирал команду разработки в Самаре для локальной компании. Формат — офис, рынок — ограниченный. Очереди из разработчиков с серьёзным enterprise-опытом не было. Зато было много кандидатов с базовыми техническими знаниями, но глубины и системного опыта часто не хватало.

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

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

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

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

«Пишете ли вы unit-тесты?»

Он почти всегда вскрывает несколько слоёв мышления.

• Отношение к качеству.

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

• Способ проектирования.  

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

• Отношение к изменениям.  

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

• Инженерная культура.  

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

Поэтому этот вопрос для меня — не про тесты, а про опыт работы с изменяющейся и сложной системой.

А что если эти вопросы задать тимлиду?

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

Вопрос №1. Кто отвечает за задачу?

Ответ на него для разработчика и тимлида оказывается разным.

Для разработчика ответ «я» — сильный сигнал. Для тимлида — уже не всегда.

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

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

Проблемы проявились постепенно. Большинство решений проходило через него: архитектура, сложные баги, приоритизация. Если что-то было непонятно — шли к нему. Ключевые задачи он всё чаще брал на себя. Стоило ему уйти в отпуск — и система начинала скрипеть. Нагрузка на него росла, он начал выгорать. И со временем стало очевидно: без него система не работает.

В итоге роли просто перераспределились. Он ушёл в архитектурную позицию, где мог сосредоточиться на системе и сложных технических решениях. А роль тимлида взял на себя другой человек — тот, кто строил работу команды иначе, распределяя ответственность и решения внутри команды. И довольно быстро стало заметно, что система перестала зависеть от одного человека.

И вот здесь вопрос начинает звучать иначе.

Для разработчика концентрация ответственности — это сила. Для тимлида она легко превращается в узкое место системы. Это не значит, что тимлид не отвечает за результат. Но его ответственность — не в том, чтобы сделать задачу самому, а в том, чтобы команда могла её решить.

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

Хороший разработчик говорит: «Я отвечаю за задачу».

Хороший тимлид отвечает иначе: «У задачи есть конкретный ответственный. Команда отвечает за результат. А роль тимлида — сделать так, чтобы команда могла его добиться».

Поэтому, когда я задаю тимлиду вопрос «кто отвечает за задачу?», я слушаю не готовность подставить плечо. Я слушаю, умеет ли он строить систему ответственности — или собирается стать её единственной точкой опоры.

Вопрос №2. Пишете ли вы unit-тесты?

Вторая история — из начала моей карьеры.

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

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

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

Ownership был, делегирование — тоже. Не хватало инженерного понимания.

И вот здесь второй вопрос становится критичным. Для тимлида недостаточно просто распределять ответственность. Важно понимать инженерную реальность системы — её ограничения, риски и последствия решений. Поэтому вопрос про unit-тесты для тимлида — это не про количество тестов, а про понимание архитектуры, рисков и долгосрочной устойчивости системы.

У роли тимлида, конечно, свой набор требований и ожиданий. Но показательно, что те же два простых вопроса работают и для разработчиков, и для лидов — меняется не вопрос, а смысл ответа.

Почему я вообще верю в эти два вопроса?

Они про отношение к ответственности и к качеству — а это меняется гораздо медленнее, чем технологии.

Если после публикации этой статьи кто-то начнёт отвечать «правильно» — это отличный исход. Значит, эти вопросы уже начали работать.

Но выучить формулировку проще, чем рассказать реальную историю о том, как вы разбирались с инцидентом в ситуации, где формально «это не мы», но у пользователя не работает. Как доводили задачу до рабочего состояния? Как поддерживали систему спустя год после релиза?

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

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

Совет для соискателей

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

1. Научитесь писать тесты, если никогда этого не делали. Даже базовый опыт работы с unit-тестами уже сильно меняет мышление разработчика. Если такой опыт есть — не стесняйтесь явно указывать его в резюме.

2. Если вас просят прислать пример кода или выполнить тестовое задание — добавьте тесты. Покажите не только решение задачи, но и то, как вы проверяете его корректность. Пара юнит- или приёмочных тестов часто говорит о подходе разработчика больше, чем сам код.

3. Делайте акцент в резюме не на технологиях, а на решённых задачах. Не просто «работал с Java и Spring», а «оптимизировал систему расчёта тарифов, что сократило время обработки заказов в два раза» или «переписал модуль интеграции с платёжным провайдером и снизил количество ошибок».

Компании платят разработчикам не за код — они платят за решение своих проблем.

Поэтому в эпоху AI всё больше ценится не способность написать функцию, а способность взять ответственность за результат и довести систему до рабочего состояния. Пока AI остаётся инструментом, ответственность за результат всё равно лежит на инженере.

В условиях высокой конкуренции выигрывают те, кто показывает, какую бизнес-ценность они приносят, а не просто как хорошо умеют программировать.

Разумеется, у каждой команды свой процесс найма. Где-то важнее алгоритмы, где-то архитектура, где-то продуктовый опыт. Эти два вопроса просто оказались теми, которые лучше всего работают в моей практике. Если бы вам разрешили задать кандидату всего два вопроса — какие бы это были?