Джун, который знает всё, или почему Senior пишет простой код: как я пишу ВКР по грейдированию программистов

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

Этот вопрос стал основой моей ВКР на тему «Разработка методики определения квалификационного уровня программиста на основе мультимодального анализа».

Вместо того чтобы гадать, я решила довериться данным. Я собрала датасет из 721 вакансии стека C#/.NET и 16 различных репозиториев, прогнала их через LLM (Saiga Llama 3) и нейросеть GraphCodeBERT, чтобы найти объективные метрики «сеньорности».

По моей задумке (и уже работающему прототипу), методика позволит оценивать грейд не по лайв-кодингу, а по «цифровому следу» программиста — его репозиторию. Цель этой статьи — показать «внутреннюю кухню» исследования, поделиться первыми инсайтами о том, как нейросети видят наш код, и получить вашу обратную связь, чтобы подготовиться к главному вопросу на защите: «А зачем всё это надо?».

«Кто ты, воин?» или Кризис идентификации

С чего началась моя магистерская? С наблюдения, которое в научной литературе называют «кризисом идентификации». Грейд — это абстракция, которая должна упрощать жизнь, но на практике она её усложняет. Требования к Middle в одном стартапе могут перекрывать требования к Senior в легаси-энтерпрайзе, а появление промежуточных сущностей вроде Junior+ или Pre-Senior лишь подчеркивает: старые линейки измерения больше не работают.

• Отсутствие стандартов: Классические модели (вроде шкалы Дрейфусов или стандарта SWECOM) слишком статичны и не успевают за появлением новых фреймворков.

• Семантический разрыв: Существует фундаментальная проблема, описанная в исследованиях MSR (Mining Software Repositories) — разрыв между декларативными требованиями в вакансии («знать микросервисы») и процедурной реальностью («править баги в монолите»).

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

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

Холодная война: Соискатели vs HR (Инфляция грейдов)

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

• Феномен «Входного перенасыщения» (для Junior)

График когнитивной нагрузки (количество технологий в одной вакансии) показал странную вещь: требования к кандидатам без опыта часто включают максимально широкий стек (медиана — 9 единиц!). HR-ы и нанимающие менеджеры, страхуясь, вписывают в вакансии джунов Microservices, Highload и Kubernetes как «желаемые». В итоге мы видим вакансии для новичков с требованиями, которые не всегда предъявляют даже мидлам.

• Эффект «Инструментального плато» (для Middle/Senior)

Вторая находка — линейного роста требований не существует. Мой регрессионный анализ показал, что количественное насыщение стека происходит к 3–5 годам стажа (уровень Middle). После этого наступает «инструментальное плато»: количество требуемых библиотек перестает расти.

Что это значит для рынка?

Рынок находится в состоянии замкнутого круга:

• HR выставляют «вишлист» вместо реальных требований (потому что не могут формализовать архитектурные навыки).

• Соискатели (особенно студенты, которых на курсах учат «пиши всё, о чем слышал») в ответ накачивают резюме ключевыми словами, чтобы пройти фильтры.

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

Почему текущие методы — это (часто) самообман

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

• Алгоритмическое тестирование (HackerRank, LeetCode)

Самый популярный метод, который… почти не работает. Исследования (например, Ford D. et al., на которые я опиралась в обзоре) показывают, что корреляция между рейтингом на алгоритмических платформах и успешностью прохождения Code Review в реальных проектах составляет всего 0.18.

Почему? Потому что это синтетические задачи. Они проверяют знание алгоритмов сортировки, но игнорируют то, что реально отличает сеньора: поддерживаемость кода и архитектурное видение. Плюс, условия таймера вызывают когнитивный стресс, снижающий результаты даже у крутых инженеров на 15–20%.

• Статический анализ (SonarQube, PVS-Studio)

Казалось бы, почему не довериться автоматике? Проблема в контексте. AST-анализ (анализ синтаксического дерева) отлично находит пропущенные запятые, но имеет уровень ложноположительных срабатываний (False Positives) до 30–35%. Линтер может сказать, что код «чистый», но он не поймет, что бизнес-логика реализована абсурдно. Он проверяет как написано, но не что и зачем.

• Анализ активности (GitHub-профиль)

«Покажи мне свой GitHub, и я скажу, кто ты». Звучит красиво, но на практике метрики активности (частота коммитов, количество строк кода) уязвимы к «эффекту Гудхарта». Как только метрика становится целью, люди начинают её накручивать: дробить коммиты и имитировать бурную деятельность. А «сухой» просмотр кода глазами интервьюера — это снова субъективизм, который не масштабируется.

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

Моя гипотеза: Two-Tower Model и «Структурный парадокс»

Чтобы уйти от субъективности, я предложила объединить анализ «ожиданий» (вакансии) и «реальности» (код) в едином векторном пространстве. В машинном обучении этот подход известен как Two-Tower Architecture (Bi-Encoder).

Решение состоит из трех этапов, каждый из которых принес свои инсайты.

Этап 1. Башня требований (Анализ рынка)

Здесь я решала задачу формализации хаоса. С помощью LLM Saiga Llama 3 я извлекла сущности из сотен вакансий C#/.NET и векторизовала их. Это позволило создать «эталонные векторы» требований для каждого грейда, очищенные от HR-шума.

Этап 2. Башня навыков (Анализ кода и Структурный парадокс)

Самая интересная часть. Чтобы оценить код, обычных метрик (вроде количества строк) мало. Я использовала модель GraphCodeBERT, которая учитывает не только синтаксис, но и граф потока данных (Data Flow Graph).

В ходе анализа репозиториев разной зрелости я обнаружила и математически обосновала «Структурный парадокс мастерства»:

Код Senior-разработчика алгоритмически проще, но архитектурно сложнее.

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

Этап 3. Симбиоз

Левая башня принимает описание вакансии или список навыков и выдает вектор требований. Правая башня принимает репозиторий кандидата, прогоняет через GraphCodeBERT и выдает вектор навыков. Система считает косинусное сходство (Cosine Similarity) между векторами.

Такой результат позволяет ответить на вопрос не «знает ли кандидат C#?», а «соответствует ли топология его мышления (через код) уровню задач, описанных в вакансии?». Если кандидат заявляет Senior-уровень, но его код имеет структуру «джуниорского клубка», дистанция между векторами будет огромной.

Зачем это нужно?

Эта методика — не просто академическое упражнение. Она решает конкретные «боли» трех ключевых участников процесса:

• Для Бизнеса и HR: Детектор «Инфляции грейдов»

Главная фишка системы — способность видеть сквозь «накрученные» резюме. Если кандидат просит зарплату Сеньора, но GraphCodeBERT показывает, что его код структурно идентичен коду Джуна (высокая энтропия, низкая связность), система подсветит этот риск. Это экономия миллионов на найме «не тех» людей. Плюс, возможность кастомизации: компания может загрузить свои критерии грейда и искать людей, согласно их взгляду на стек и грейд.

• Для Разработчика: Объективное зеркало

Никакого синдрома самозванца!

Система дает беспристрастную оценку: «Ты круто знаешь синтаксис (как Мидл), но твоя архитектура всё ещё монолитна (как у Джуна)». Это готовая карта развития, основанная на данных, а не на настроении тимлида.

• Для Тимлидов: Автоматизированный аудит

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

Ограничения и «подводные камни»

Но все это не панацея, и у методики есть строгие границы применимости, которые видно уже сейчас:

• Слепая зона Soft Skills: Это главное ограничение. Моя модель анализирует Hard Skills (код и знания). Но Сеньор — это часто про коммуникацию, менторство и умение договариваться. Эти материи GraphCodeBERT (пока) не видит.

• Проблема авторства: Методика идеально работает на пет-проектах одного автора. Если скормить ей рабочий репозиторий, где код писала команда из 10 человек, результат будет «средней температурой по больнице».

• Стек-зависимость: Пока модель обучена на C#/.NET. Перенос на динамически типизированные языки (Python, JS) потребует пересборки датасетов и переобучения, так как там паттерны «сеньорности» могут выглядеть иначе.

• Декларативность вакансий: Мы анализируем то, что HR пишут в вакансиях. Если рынок массово начнет врать в описаниях (еще больше, чем сейчас), «Башня требований» в моей архитектуре начнет выдавать смещенные векторы.

Поделитесь вашими мыслями и опытом: будет ли такая система работать? Как можно ее доработать и улучшить? Или вся эта идея лишь исследование, которое вряд ли получит дальнейшее развития из-за практической неприменимости?)