Немного о собеседованиях

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

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

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

Я не готовил софт специально для собеседований. Наоборот, я делал его потому, что мне самому не хватало удобного и достаточно строгого процесса разработки с ИИ. Но на собеседованиях произошло неожиданное: рассказ о моём опыте занимал 20 минут, а затем мы переходили к софту, который я написал, и, на его примере, остальное время обсуждали подходы и решения.

Почему так?

Когда резюме уже недостаточно

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

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

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

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

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

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

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

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

Сам по себе COSMIC не ответит на все эти вопросы и не превратит функциональный размер в точный прогноз сроков. Но он даёт основу, на которой можно строить дальнейшую модель оценки. А это уже гораздо интереснее, чем просто попросить нейросеть прикинуть, сколько времени займёт разработка.

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

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

Собственный инструмент как продолжение инженерного опыта

Я уже писал в статье о SpecaFlow, что начал заниматься им из-за ограничений вайбкоддинга и обычного Spec-Driven Development. Мне хотелось получить не просто генерацию кода по описанию, а последовательный процесс, в котором есть формализованные требования, планирование, проверяемость результата и контроль изменений.

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

Потом появились tests first, deviations, паспорта этапов и механизм извлечения уроков из каждой фичи. Каждое из этих решений возникало не потому, что мне хотелось добавить в продукт ещё одну возможность. Я сталкивался с конкретной проблемой, искал её причину и пытался изменить сам процесс, чтобы проблема не повторялась при следующем цикле разработки.

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

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

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

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

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

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

А причём здесь управление командой?

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

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

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

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

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

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

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

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

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

ИИ изменил не только разработку

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

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

Теперь, после собеседований, я увидел ещё одну сторону этой же истории.

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

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

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

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

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

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

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

Вместо заключения

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

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

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

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

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

Спасибо за внимание! Успешных вам проектов!