После технического интервью на позицию Go-разработчика я попросил более подробную обратную связь.
Начиналась она вполне позитивно:
У тебя сильная техническая база и хороший hands-on опыт с Go, инфраструктурой, БД.
Но буквально через несколько предложений:
Остались вопросы к глубине в отдельных технических областях, в частности, к пониманию конкурентности в Go и самостоятельной эксплуатации production-инфраструктуры и мониторинга.
Некоторые выводы плохо стыковались и с самим интервью, и с тем опытом, который мы на нём обсуждали.
Мне стало интересно, как вообще из разговора получился именно такой итоговый фидбек.
С одним пунктом я согласен
Для роли был важен опыт самостоятельной работы с заказчиком: понять потребность, предложить решение, провести исследование задачи ещё до разработки.
Здесь замечание справедливое.
Я много раз сам инициировал инженерные изменения, проектировал системы, предлагал архитектурные решения, переписывал устаревшие части продуктов, улучшал процессы разработки. Но это происходило в основном внутри инженерных команд.
Регулярного опыта, когда я сам работаю с внешним заказчиком, выясняю его потребность и дальше веду решение от этой потребности, у меня действительно было мало.
С таким выводом я спорить не собирался.
Дальше начинались более интересные вещи.
От одного эпизода до оценки всей конкурентности в Go
Во время технического интервью был разбор кода.
Я нашёл в предложенной функции несколько проблем, но не сразу заметил проблему с конкурентным доступом. После дополнительного вопроса интервьюера увидел её и объяснил.
Это нормальный отрицательный сигнал. Я действительно пропустил ошибку при первом просмотре.
Но итоговая формулировка была значительно шире:
вопросы к глубине понимания конкурентности в Go.
Конкурентность в Go не сводится к способности мгновенно заметить одну проблему в одном фрагменте кода.
Отдельной проверки этой области на интервью не было. Не было разбора каналов, примитивов синхронизации, атомарных операций, модели памяти, отмены операций, взаимных блокировок и других тем, по которым можно было бы судить о глубине понимания конкурентности.
На интервью произошло следующее: в одном примере я не сразу заметил проблему с конкурентным выполнением.
В итоговой оценке уже появились вопросы к глубине понимания целой области.
Такой вывод может оказаться верным. Но проведённое интервью само по себе его не подтверждает.
Самый странный пункт: эксплуатация инфраструктуры
Сильнее всего меня удивило замечание про:
самостоятельную эксплуатацию production-инфраструктуры и мониторинга.
С эксплуатацией у меня как раз большой практический опыт.
Я самостоятельно поднимал Kubernetes-кластеры.
Сам разворачивал тестовые и промышленные окружения своих проектов.
Сам деплоил приложения.
Работал в команде облачной платформы и занимался сервисом управляемого Kubernetes.
Проектировал инфраструктурные компоненты Kubernetes, в том числе отказоустойчивую схему с несколькими управляющими узлами.
Участвовал в дежурствах.
Работал с метриками и сам добавлял их в сервисы.
Работал с алертами и реагировал на них.
Разбирал логи.
Участвовал в разборе инцидентов в промышленной среде.
Значительная часть этого опыта обсуждалась на интервью.
И на этом фоне особенно интересно смотрятся две фразы из одного сообщения:
сильная техническая база и хороший hands-on опыт с Go, инфраструктурой, БД;
и:
вопросы к самостоятельной эксплуатации production-инфраструктуры и мониторинга.
Если под вторым пунктом подразумевался какой-то более высокий или специфический уровень ответственности, это можно было сформулировать точнее.
Например:
Опыт эксплуатации есть, но нам не хватило подтверждений того уровня самостоятельности, который требуется в нашей команде.
Это уже понятная оценка.
Но в полученном фидбеке сама эксплуатация и мониторинг оказались среди зон, к которым остались вопросы.
При этом отдельного глубокого блока по эксплуатации на интервью не было.
Получилась странная ситуация: в разговоре были прямые подтверждения опыта, область подробно не проверялась, но итоговая формулировка всё равно оказалась отрицательной именно по этой области.
С Python и фронтендом ситуация похожая
Ещё один фрагмент фидбека:
Python и frontend тоже есть в опыте, но сейчас это не выглядит как сильная регулярная практика, а у нас они входят в ключевой стек проекта.
И здесь важен контекст: сама вакансия была на позицию Go-разработчика.
Мой основной промышленный стек сейчас действительно Go. При этом опыт с Python и фронтендом у меня не сводится к нескольким учебным проектам или редким правкам чужого кода.
Я писал на React. Самостоятельно реализовывал собственное виртуальное дерево на JavaScript.
Был и более показательный проект. Изначально это было приложение на старом Go-фреймворке, где клиентская и серверная части жили вместе. Я полностью переработал его архитектуру: вынес фронтенд в отдельное приложение и сделал отдельную серверную часть на Go.
То есть речь не о нескольких правках интерфейса. Я самостоятельно разделил приложение на клиентскую и серверную части и переписал фронтенд.
С Python тоже был практический опыт разработки. Я помогал другим разработчикам с Python, занимался наставничеством и продолжаю использовать его в задачах, связанных с анализом данных и машинным обучением.
Я вообще достаточно много переключался между технологиями. Писал плагины для JetBrains на Kotlin, инструменты на Python, фронтенд на JavaScript и React. Основной промышленный бэкенд сейчас пишу на Go.
На самом интервью Python и фронтенд практически не проверялись.
Не было задачи на Python.
Не было вопросов по Python.
Не было задачи по фронтенду.
Не было разбора фронтенд-кода.
Не проверялось, насколько быстро я могу разобраться с существующим проектом на этих технологиях.
Зато в итоговом фидбеке появился довольно конкретный вывод о том, насколько сильной и регулярной является моя текущая практика.
Откуда именно он был получен, мне непонятно.
Насколько вообще важна «регулярная практика» конкретного языка в 2026 году
Свежий опыт конкретного стека имеет значение. Человек, который несколько лет каждый день пишет на Python, лучше знаком с текущими библиотеками, экосистемой, принятыми подходами и характерными проблемами.
Но регулярность использования конкретного языка и способность эффективно решать на нём задачи уже не настолько тесно связаны, как раньше.
В разработке появились агентные инструменты, которые могут изучать кодовую базу, находить нужные места, разбираться с используемыми библиотеками, вносить изменения, запускать тесты и помогать проверять результат.
Переключаться между языками и фреймворками стало проще.
Для опытного инженера большую роль играют общая техническая база, понимание архитектуры, способность читать чужой код, быстро разбираться в системе и проверять результат работы агента.
Хорошее знание конкретного стека всё ещё даёт преимущество. Но отсутствие ежедневной практики уже намного меньше говорит о том, сможет ли разработчик эффективно выполнять на нём задачи.
У меня такой режим работы давно стал обычным. Если мне нужно решить задачу на Python или внести изменения во фронтенд, мне не требуется сначала несколько месяцев регулярно писать на этой технологии.
Поэтому требование компании:
Нам нужен человек со свежим регулярным опытом Python и frontend.
вполне понятно.
Но на интервью этот параметр не проверяли. Фактически из того, что мой основной стек сейчас Go, появился вывод о силе моей текущей практики в других технологиях.
Для вакансии Go-разработчика это выглядит особенно спорно: дополнительные технологии действительно могли быть важны для проекта, но оценивать их как существенную слабую сторону без проверки самих навыков довольно странно.
Откуда вообще мог получиться такой фидбек
После этого я задумался, как формировался итоговый текст.
Я не знаю, использовала ли компания нейросеть при обработке интервью. Доказательств этого у меня нет.
Но сам результат похож на то, что можно получить, если последовательно прогонять информацию через несколько стадий.
Есть требования вакансии.
Есть разговор с кандидатом и заметки после него.
Из разговора выделяются сильные стороны.
Затем тот же материал сопоставляется с требованиями роли.
По каждому требованию ищутся пробелы.
После этого всё собирается в итоговый фидбек.
Получается примерно такая цепочка:
Интервью
→ заметки
→ краткое содержание
→ требования роли
→ оценка по критериям
→ сильные стороны и недостатки
→ итоговый фидбек
Такой процесс совершенно необязательно должен быть автоматическим. Его могут полностью выполнять люди.
Нейросеть здесь просто добавляет ещё один возможный слой обработки: она хорошо умеет брать неполные данные и собирать из них связный вывод.
Как «не проверяли» превращается в «не умеет»
Возьмём самостоятельную эксплуатацию инфраструктуры.
В разговоре есть Kubernetes, деплои, метрики, дежурства, работа с промышленными системами.
Но никто подробно не проверял границы этого опыта.
Корректный вывод:
Мы не выяснили эту область достаточно глубоко.
Можно сформулировать чуть сильнее:
Нам не хватило данных, чтобы подтвердить нужный нам уровень самостоятельности.
Но после нескольких этапов обработки эта мысль легко превращается в:
Остались вопросы к самостоятельной эксплуатации production-инфраструктуры и мониторинга.
Формулировки похожи, а смысл уже изменился.
Сначала речь шла о том, чего не удалось установить на интервью.
В конце получается характеристика кандидата.
Один эпизод начинает характеризовать целую область
С конкурентностью механизм ещё проще.
Есть конкретное наблюдение:
не сразу заметил конкурентную ошибку.
Есть требование:
глубокое понимание конкурентности в Go.
Если напрямую связать одно с другим, получается:
вопросы к глубине понимания конкурентности.
Основание у вывода есть.
Но один эпизод и оценка целой области имеют разный масштаб.
Именно так можно получить убедительный фидбек, где практически у каждого тезиса есть какое-то основание, но сами выводы оказываются шире тех данных, из которых они появились.
Сильные стороны и недостатки начинают плохо стыковаться
В моём фидбеке сначала говорится:
хороший hands-on опыт с инфраструктурой.
А затем:
вопросы к самостоятельной эксплуатации production-инфраструктуры и мониторинга.
У этих утверждений может быть нормальное объяснение.
Например, компания считает мой инфраструктурный опыт хорошим, но ищет человека с гораздо большей эксплуатационной ответственностью.
Тогда это различие стоит обозначить.
Без такого объяснения две части одного фидбека выглядят плохо согласованными.
Подобное легко получить, если сильные стороны и недостатки определять отдельно.
Сначала из разговора извлекается: Kubernetes, инфраструктура, деплои, промышленный опыт. Получается сильная сторона.
Потом отдельно проверяется конкретное требование. Явного подтверждения нужного уровня самостоятельности недостаточно. Появляется сомнение.
Каждый вывод сам по себе выглядит нормально.
Несостыковка становится заметна только тогда, когда их ставишь рядом.
А если никакой нейросети не было?
Тот же результат можно получить полностью вручную.
У интервьюеров есть список критериев.
После собеседования они его заполняют.
Один формулирует сомнение, второй соглашается.
Рекрутер позже превращает внутренние комментарии в короткое сообщение кандидату.
При таком пересказе тоже теряются детали, а частные наблюдения превращаются в более широкие оценки.
Поэтому вопрос о том, использовалась ли в этой конкретной компании нейросеть, для меня вторичен.
Интереснее качество самой оценки.
Если написано:
вопросы к самостоятельной эксплуатации инфраструктуры,
должно быть понятно, какие конкретно ответы привели к этому выводу.
Если написано:
вопросы к глубине понимания конкурентности,
хочется понимать, какая проверка позволила распространить один эпизод на целую область.
Если написано:
нет сильной регулярной практики Python и frontend,
интересно, откуда взялся этот вывод, если сами навыки и регулярность их использования на интервью практически не проверялись.
Иначе фидбек превращается в набор правдоподобно звучащих характеристик, происхождение которых невозможно восстановить.
Что меня в итоге зацепило
Компания могла обоснованно решить, что ей нужен другой кандидат.
По работе с заказчиком я сам согласен с замечанием.
По конкурентности был конкретный эпизод, который можно считать отрицательным сигналом.
Мой основной рабочий стек сейчас действительно Go.
Но итоговые утверждения местами заметно сильнее тех данных, которые были получены на интервью.
«Не сразу заметил одну конкурентную проблему» не равно «недостаточно глубокое понимание конкурентности».
То, что основной стек разработчика сейчас Go, само по себе не определяет его способность эффективно писать на Python или заниматься фронтендом, особенно если это вообще не проверялось.
А замечание про самостоятельную эксплуатацию инфраструктуры особенно трудно совместить с опытом, где я сам поднимал Kubernetes-кластеры, разворачивал окружения, деплоил сервисы, работал с метриками и алертами, участвовал в дежурствах и разбирал производственные инциденты.
Поэтому у меня остался простой вопрос:
как именно из того, что происходило на интервью, были получены эти утверждения?
С нейросетью такой процесс становится ещё интереснее, потому что она умеет превращать неполный набор фактов в связный и уверенно звучащий текст.
Но проблема существует и без неё.
«Мы не получили подтверждения» и «у кандидата этого нет» означают разные вещи.
Хороший процесс найма не должен терять эту разницу.
ссылка на оригинал статьи https://habr.com/ru/articles/1089344/