План адаптации

Ответы моделей

1. Claude FableОтвет получен через APIСредняя оценка: 9.8

   План адаптации junior-разработчика: первые 2 недели

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

   ---

   До первого дня (ответственный — HR + тимлид)

   • Наставник назначен заранее, а не в день выхода. Критерий выбора: не самый загруженный сеньор, а тот, кто умеет объяснять и имеет 3–4 часа в неделю.
   • Ноутбук с предустановленным окружением, аккаунты (почта, мессенджер, Git, таск-трекер) созданы. Джун в первый день пишет код, а не ждёт админа.
   • Наставник выбирает 3–5 задач из бэклога заранее: мелкие баги, правки в тестах, задачи с понятным «definition of done». Помечены как onboarding-задачи.
   • В командный чат — короткое сообщение: кто выходит, чем будет заниматься, кто наставник.

   День 1:人 и железо

   • Утро: встреча с HR (30 мин) — оргвопросы, зарплатные даты, отпуска, больничные. Один документ-шпаргалка со ссылками вместо часовой презентации.
   • Экскурсия по людям, не по офису: тимлид представляет джуна лично каждому в команде разработки + смежникам (продакт, QA, дизайнер), с одной фразой «к нему идёшь, когда…». В компании до 50 человек это реально сделать за час.
   • Настройка рабочего места вместе с наставником: клонирование репозиториев, запуск проекта локально, первый прогон тестов. Цель дня — проект собирается и запускается на машине джуна. Все грабли, на которые наступили, джун записывает — это будет его первый вклад в документацию.
   • Обед с командой — не опционально, тимлид организует.

   День 2: контекст продукта

   • Демо продукта от продакта или тимлида (1 час): что делаем, кто платит, какие метрики важны. Джун должен уметь объяснить продукт своими словами.
   • Доступ к документации: наставник даёт маршрут чтения — не «вот вики, разбирайся», а конкретный порядок: архитектурная схема → соглашения по коду → процесс ревью → как деплоим. На чтение — полдня, не больше.
   • Первый коммит: правка тех самых граблей из дня 1 в onboarding-доку. Джун проходит полный цикл: ветка → PR → ревью → мёрж. На игрушечной задаче, без страха что-то сломать.

   Дни 3–5: первые боевые задачи

   • Наставник выдаёт первую задачу из заготовленного списка. Правило: задача на 0,5–1 день, с ревью от наставника в тот же день.
   • Ежедневный чекин с наставником — 15 минут в конце дня: что сделал, где застрял, что непонятно. Не статус-репорт, а разбор.
   • Джун участвует во всех командных ритуалах (стендап, планирование) с первого дня. На стендапе говорит сам, наставник не отвечает за него.
   • Пятница: встреча с тимлидом (30 мин). Первые впечатления, что мешает, что удивило. Тимлид фиксирует проблемы онбординга — они системные, не личные.

   Неделя 2: рост самостоятельности

   • Задачи укрупняются: 1–2 дня на задачу, наставник смотрит результат, а не процесс. Чекины сокращаются до 3 раз в неделю.
   • Джун делает первое ревью чужого PR (небольшого, вместе с наставником). Это быстрее всего учит стандартам кода и снимает страх перед ревью собственного.
   • Одна встреча со смежником: час с QA или девопсом — как тестируем, как катим релизы. Бесплатно, а даёт больше, чем курс.
   • Среда: встреча наставник + тимлид без джуна (15 мин): темп нормальный? нужна ли коррекция задач?

   Конец недели 2: контрольная точка

   • Ретро адаптации (тимлид + наставник + джун, 45 мин):
   • Джун показывает, что сделал за 2 недели — сам, как мини-демо.
   • Обратная связь в обе стороны: не только «как он», но и «что в нашем онбординге сломано».
   • План на следующий месяц: какие типы задач берёт, какая зона кода становится «его».
   • Критерии успеха двух недель: проект запускает и деплоит сам; закрыл минимум 3 задачи; знает, к кому идти по продукту, инфре и процессам; задаёт вопросы в общем канале, а не только наставнику в личку.

   ---

   Красный флаг для HR BP: если к концу недели 1 у джуна нет ни одного смёрженного PR — проблема не в джуне, а в подготовке окружения или занятости наставника. Разбирать сразу, не ждать конца адаптации.

   Разница между оценками судей: недоступна: учтена оценка только одного судьи.

   Комментарии судей

   • ChatGPT Sol: 9.75 — План логично разбит по дням и этапам, содержит сроки, ответственных, длительность встреч, измеримые результаты и все обязательные элементы. Реалистичность немного снижена из-за требования самостоятельно деплоить уже через 2 недели: в некоторых командах junior не получит доступ к деплою так быстро. Также в заголовке дня 1 есть случайный символ 人.
     • Структура: 10 из 10
     • Конкретность: 10 из 10
     • Реалистичность: 9 из 10
     • Полнота: 10 из 10
2. ChatGPT SolОтвет получен через APIСредняя оценка: 9.5

   Цель адаптации

   К концу 2-й недели junior-разработчик:

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

   До первого рабочего дня

   HR:

   • отправить расписание первой недели и контакты наставника;
   • подготовить договоры, пропуск и технику;
   • назначить 30-минутные знакомства с командой, не больше 2 встреч в день.

   Наставник:

   • выбрать первую задачу объёмом до 4 часов;
   • подготовить вторую задачу на 1–2 дня;
   • проверить актуальность README и инструкции запуска;
   • открыть доступ к репозиторию, таск-трекеру, корпоративному чату, базе знаний и тестовому окружению.

   Неделя 1 — разобраться в продукте и сделать первый PR

   День 1. Команда и рабочее место

   • HR проводит 30-минутную встречу: структура компании, рабочий график, зарплатные и административные вопросы.
   • Руководитель за 45 минут объясняет продукт: кто пользователь, какую проблему решаем, на чём компания зарабатывает.
   • Разработчик знакомится со своей командой на общем созвоне. Каждый участник называет свою зону ответственности и примеры вопросов, с которыми к нему можно обращаться.
   • Наставник помогает настроить IDE, Git, менеджер пакетов, локальные переменные окружения и доступ к тестовым сервисам.
   • Разработчик клонирует проект, запускает его и выполняет тестовый сценарий пользователя.
   • Итог дня: проект работает локально, все доступы проверены по чек-листу, блокеры записаны.

   День 2. Кодовая база и процесс разработки

   • Наставник показывает основные модули проекта, точки входа, структуру тестов и движение данных по одному реальному пользовательскому сценарию.
   • Разработчик читает только обязательный минимум документации: README, правила Git, описание архитектуры, Definition of Done и инструкцию по выпуску изменений.
   • Вместе с наставником проходит путь существующей задачи: карточка → ветка → код → тест → PR → ревью → релиз.
   • Первая задача: исправить текст, тестовые данные, небольшую вёрстку или локальную ошибку без изменения бизнес-логики.
   • Итог дня: создан первый PR с описанием проверки.

   День 3. Первый цикл ревью

   • Наставник разбирает PR голосом или парным программированием: что изменить и почему.
   • Разработчик самостоятельно вносит правки и повторно запускает проверки.
   • Короткое знакомство с QA или человеком, который проверяет релизы: какие дефекты критичны и как описывать шаги воспроизведения.
   • Встреча с наставником — 20 минут: что уже понятно, где документация не помогла, какие доступы ещё отсутствуют.
   • Итог дня: первый PR принят или доведён до состояния, в котором остались только конкретные правки.

   День 4. Задача с небольшой логикой

   • Разработчик получает задачу на 1–2 дня: простая валидация, небольшое изменение API, обработка состояния интерфейса или добавление теста.
   • Перед кодом он формулирует наставнику план из 3–5 шагов и критерии готовности.
   • Наставник проверяет направление, но не диктует реализацию.
   • Разработчик добавляет или обновляет тест, затем пишет код.
   • Итог дня: рабочее решение запущено локально; оставшиеся вопросы записаны в карточке задачи.

   День 5. Завершение первой недели

   • Разработчик заканчивает задачу, открывает PR и прикладывает результаты тестирования.
   • Наставник проводит 30-минутное ревью недели: где потребовалась помощь, какие ошибки повторялись, что изучить на следующей неделе.
   • Разработчик дополняет документацию, если обнаружил устаревший шаг настройки или запуска.
   • Руководитель подтверждает задачу на 2-ю неделю и объясняет её пользу для пользователя.
   • Итог недели: минимум 1 принятый PR, 1 содержательный PR на ревью, список пробелов в знаниях и план их закрытия.

   Неделя 2 — выполнить самостоятельную задачу

   День 6. Постановка задачи

   • Разработчик получает задачу объёмом 2–3 дня с ограниченным влиянием на продукт.
   • Самостоятельно изучает связанный код и документацию.
   • Пишет короткий план решения, риски и список вопросов.
   • Наставник за 20 минут проверяет план и помогает сузить задачу, если она разрослась.
   • Итог дня: согласованы границы задачи и критерии приёмки.

   День 7. Самостоятельная разработка

   • Основная работа над задачей без постоянного присутствия наставника.
   • Вопросы собираются списком; срочные задаются сразу, остальные обсуждаются на ежедневной 15-минутной встрече.
   • Разработчик показывает промежуточный результат локально.
   • Итог дня: работает основной сценарий, тесты покрывают ключевое изменение.

   День 8. Проверка качества

   • Разработчик проверяет крайние случаи и ошибки ввода.
   • Запускает линтер, тесты и ручной пользовательский сценарий.
   • Самостоятельно проводит ревью своего diff: удаляет отладочный код, проверяет названия и обработку ошибок.
   • Открывает PR с описанием причины изменения, способа проверки и известных ограничений.
   • Итог дня: PR готов к полноценному ревью.

   День 9. Ревью и выпуск

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

   День 10. Итоги и план роста

   • Разработчик демонстрирует задачу команде за 10 минут: проблема, решение, проверка, чему научился.
   • Наставник даёт обратную связь по 3 пунктам: техническая работа, самостоятельность, коммуникация.
   • Разработчик оценивает адаптацию: какие инструкции помогли, где потерял время, чего не хватило.
   • Руководитель и разработчик выбирают 2 цели на следующий месяц: одну техническую и одну рабочую, с измеримым результатом.
   • Итог дня: зафиксированы цели на 30 дней, регулярность встреч с наставником и задачи следующего уровня сложности.

   Режим работы с наставником

   • Ежедневно в первую неделю — 20 минут.
   • Во вторую неделю — 15 минут через день плюс вопросы по блокерам.
   • На вопрос junior сначала пишет: что хотел получить, что сделал, что произошло и что уже проверил.
   • Наставник не забирает задачу себе: показывает следующий шаг или разбирает решение совместно.
   • Если блокер не сдвинулся за 30–40 минут, разработчик обращается за помощью, а не сжигает полдня из принципа.

   Минимальный набор документации

   • инструкция локального запуска;
   • схема основных компонентов проекта;
   • правила веток, коммитов и PR;
   • Definition of Done;
   • порядок тестирования и выпуска;
   • список владельцев систем и зон ответственности;
   • FAQ по типовым ошибкам настройки.

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

   Задача закрыта. Если следующая несвязанная — открой новый чат.

   Разница между оценками судей: недоступна: учтена оценка только одного судьи.

   Комментарии судей

   • Claude Opus: 9.5 — Чёткая иерархия: цель, преднастройка, две недели по дням, режим наставника, минимум документации — читается как готовый чек-лист. Конкретика на месте: тайминги встреч (30/45/20/15 мин), объёмы задач в часах и днях, полный цикл задачи (карточка → код → тест → PR → ревью → релиз), формат вопроса к наставнику. Реалистично для стартапа до 50 человек с минимальным бюджетом и упором на менторство: нагрузка нарастает от правки текста к самостоятельной задаче, есть правило эскалации блокера через 30–40 минут. Все требования задания закрыты — знакомство с командой, настройка рабочего места, первые задачи, встречи с наставником, доступ к документации, плюс метрики результата и цели на 30 дней. Клише почти отсутствуют, требование владельца и даты у каждого документа — сильная деталь. Мелкий минус по конкретности/реалистичности: нет привязки к конкретному стеку и ролям (кто именно руководитель, есть ли QA как отдельная роль в компании до 50 человек), из-за чего часть шагов остаётся шаблонной.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 9 из 10
     • Полнота: 10 из 10
3. ChatGPT TerraОтвет получен через APIСредняя оценка: 9.5

   До выхода

   • Наставник готовит рабочее место: доступы в GitHub/GitLab, трекер задач, корпоративный чат, VPN, почту, репозитории, тестовый контур.
   • В календаре стоят: вводная с HR/руководителем, знакомство с командой, ежедневные 15-минутные слоты с наставником на первую неделю.
   • Собран стартовый пакет: схема продукта, README проектов, правила разработки, гайд по запуску локальной среды, список людей и зон ответственности.

   День 1 — контекст и рабочая среда

   • Встреча с руководителем: чем зарабатывает компания, кто клиенты, как работа разработчика влияет на продукт.
   • Знакомство с командой: каждый кратко объясняет, за что отвечает и когда к нему обращаться.
   • Настройка ноутбука и окружения вместе с наставником: репозиторий, зависимости, локальный запуск, тесты, линтеры.
   • Проверка всех доступов на практике: открыть задачу в трекере, создать ветку, запустить проект, написать в командный чат.
   • В конце дня — 20 минут с наставником: что заработало, что заблокировано, какие термины и части системы непонятны.

   День 2 — кодовая база и правила работы

   • Наставник проводит 45-минутный разбор: структура репозитория, точки входа, основные модули, путь запроса от UI до данных.
   • Новичок читает обязательную документацию: README, правила веток и PR, соглашения по коду, процесс ревью, описание окружений.
   • Выполняет техническую стартовую задачу: поправить документацию, добавить недостающий локальный конфиг без секретов или устранить маленькую воспроизводимую проблему.
   • Создаёт первый PR. Наставник объясняет комментарии в ревью, а не переписывает код молча.
   • Встреча с наставником: сверка понимания процесса от задачи до выкладки.

   День 3–4 — первая продуктовая задача

   • Руководитель и наставник выбирают задачу на 1–2 дня: без критичного риска, но затрагивающую реальный продукт.
   • Перед началом новичок своими словами фиксирует: что меняется, как проверить результат, какие части кода затрагиваются.
   • Наставник помогает разбить задачу на шаги и согласовать критерии готовности.
   • Ежедневный короткий синк: прогресс, блокеры, следующий конкретный шаг.
   • Первый полноценный PR проходит обычное ревью команды; наставник отвечает за скорость обратной связи.

   День 5 — итог первой недели

   • Демонстрация результата команде: 5–10 минут, что было сделано, что оказалось сложным, что осталось непонятным.
   • Встреча junior + наставник + руководитель на 30 минут:
   • что уже получается самостоятельно;
   • где требуется поддержка;
   • какая зона продукта будет изучаться на второй неделе.
   • Наставник обновляет список документации: что прочитать дальше и чего в ней не хватает.
   • Новичок формулирует 2–3 личные цели на вторую неделю: например, самостоятельно провести PR, разобраться с тестами конкретного модуля, закрыть небольшую задачу без постоянных подсказок.

   Неделя 2 — самостоятельность с контролем

   Дни 6–7

   • Новичок берёт задачу немного шире первой: небольшой баг или ограниченная часть фичи.
   • До разработки проводит 20-минутный разбор решения с наставником: варианты, риски, тестирование.
   • Сам находит релевантные документы и владельцев компонентов; наставник подключается, если поиск зашёл в тупик.
   • Добавляет или обновляет тесты вместе с изменением кода.

   Дни 8–9

   • Участвует в командном планировании, стендапе и хотя бы одном ревью чужого PR: оставляет вопросы или комментарии по понятным участкам.
   • Проводит короткий walkthrough своего решения наставнику до отправки PR.
   • Исправляет замечания ревью самостоятельно; просит помощь с конкретным вопросом, а не с формулировкой «не работает».
   • Дополняет документацию, если во время работы обнаружил отсутствующий шаг или устаревшую инструкцию.

   День 10 — закрепление адаптации

   • Закрывает вторую задачу или показывает понятный промежуточный результат с дальнейшим планом.
   • Проводит ретро на 30 минут с наставником и руководителем:
   • какие процессы понятны;
   • какие доступы или документы всё ещё мешают;
   • как часто нужны синки с наставником дальше;
   • какая следующая задача даст рост без перегруза.
   • Фиксируется план на следующие 30 дней: 1 продуктовая зона, 1 технический навык, 1 измеримый результат.

   Ритм поддержки

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

   Задача закрыта. Если следующая несвязанная — открой новый чат.

   Разница между оценками судей: недоступна: учтена оценка только одного судьи.

   Комментарии судей

   • Claude Opus: 9.5 — Сильный ответ. Структура образцовая: подготовка до выхода, разбивка по дням с осмысленными фазами (контекст → кодовая база → первая задача → итог недели → самостоятельность), отдельный блок про ритм поддержки. Конкретность высокая — реальные инструменты (GitHub/GitLab, VPN, трекер, линтеры), тайминги встреч (15/20/30/45 мин), понятные типы стартовых задач (поправить доку, добавить локальный конфиг без секретов, воспроизводимый баг). Клише почти нет, есть здравые детали вроде «наставник объясняет комментарии в ревью, а не переписывает молча» и «просит помощь с конкретным вопросом, а не с формулировкой не работает». Реалистично для стартапа до 50 человек с упором на наставничество и минимальным бюджетом: нагрузка растёт постепенно, junior не брошен и не перегружен. Полнота: закрыты все требования задания (знакомство с командой, настройка рабочего места, первые задачи, встречи с наставником, доступ к документации), сверх того — план на 30 дней и явная роль руководителя. Минусы мелкие: нет упоминания неформальной социализации/онбординга вне работы и метрик успеха адаптации кроме личных целей.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 9 из 10
     • Полнота: 10 из 10
4. ChatGPT LunaОтвет получен через APIСредняя оценка: 9.3

   Цель на 2 недели

   К концу периода junior-разработчик должен:

   • понимать продукт, команду и рабочие правила;
   • иметь настроенное окружение и доступы;
   • самостоятельно запускать проект локально;
   • выполнить 1–2 небольшие задачи через обычный процесс code review;
   • знать, где искать документацию и к кому обращаться.

   До первого дня

   • Назначить наставника на первые 2 недели.
   • Подготовить ноутбук, корпоративную почту, мессенджер, репозитории, трекер задач и тестовые стенды.
   • Создать короткий onboarding-документ: структура команды, ссылки на репозитории, инструкции запуска, правила веток и pull request.
   • Выбрать 2–3 задачи низкого риска: исправление документации, небольшой UI-баг, простой технический долг.
   • Забронировать встречи с наставником на 30 минут в конце каждого рабочего дня.

   Неделя 1

   День 1. Вход в компанию и контекст

   • HR BP: рассказать о формате работы, графике, правилах коммуникации и порядке получения помощи.
   • Руководитель разработки: объяснить продукт, текущие приоритеты и место команды в бизнесе.
   • Наставник: провести экскурсию по репозиториям, трекеру и каналам коммуникации.
   • Команда: короткое знакомство по схеме «роль — зона ответственности — как со мной работать».
   • Новичок: зафиксировать вопросы и составить список недостающих доступов.

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

   День 2. Настройка рабочего места

   • Установить нужную версию Node.js/Python, IDE, Docker, Git и проектные утилиты.
   • Получить доступ к репозиториям, CI, тестовым окружениям, логам и внутренней документации.
   • Запустить проект локально по инструкции.
   • Вместе с наставником пройти основной пользовательский сценарий продукта.
   • Сделать маленькое изменение в отдельной ветке и открыть пробный pull request.

   Результат: проект запускается локально, доступы проверены, базовый Git-процесс понятен.

   День 3. Архитектура и правила разработки

   • Наставник объясняет структуру приложения, основные модули и точки интеграции.
   • Разобрать один недавно выполненный pull request: постановка задачи, код, тесты, ревью.
   • Прочитать обязательные документы: README, правила разработки, описание окружений, FAQ по частым ошибкам.
   • Выбрать первую рабочую задачу и уточнить критерии готовности.
   • В конце дня обсудить с наставником возникшие сложности.

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

   День 4. Первая задача

   • Разбить задачу на шаги вместе с наставником.
   • Самостоятельно реализовать изменение.
   • Добавить или обновить тесты, если это предусмотрено проектом.
   • Открыть pull request с кратким описанием: что изменено, как проверено, где нужна помощь.
   • Пройти ревью с наставником, не ограничиваясь исправлением замечаний: обсудить причины решений.

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

   День 5. Закрепление процесса

   • Довести первую задачу до merge либо зафиксировать конкретный план завершения.
   • Посетить командную встречу: планирование, синхронизацию или разбор текущих проблем.
   • Провести 30-минутную встречу с руководителем разработки:
   • что стало понятнее;
   • где не хватает документации;
   • какие задачи подходят для следующей недели.
   • Наставник даёт обратную связь по коммуникации, оценке сроков и работе с ревью.
   • Новичок дополняет onboarding-документ найденными пробелами.

   Результат: понятен рабочий цикл от задачи до merge, выявлены риски на следующую неделю.

   Неделя 2

   День 6. Вторая задача и самостоятельная работа

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

   Результат: новичок начинает работать не только по пошаговой инструкции.

   День 7. Парное программирование

   • Провести 60–90 минут парной работы с наставником на реальной задаче.
   • Обсудить:
   • как искать нужный код;
   • как проверять гипотезы;
   • какие решения команда считает нежелательными;
   • когда пора просить помощи.
   • Продолжить самостоятельную реализацию второй задачи.

   Результат: освоены практические приёмы навигации по незнакомому коду.

   День 8. Проверка качества

   • Запустить локальные тесты, линтер и сборку.
   • Проверить изменение вручную в тестовом окружении, если это возможно.
   • Открыть pull request и самостоятельно описать риски изменения.
   • Получить ревью минимум от наставника и ещё одного участника команды.
   • Исправить замечания и уточнить непонятные комментарии.

   Результат: новичок умеет подготовить изменение к командной проверке.

   День 9. Командные связи и документация

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

   Результат: понятны границы ответственности и маршруты решения проблем.

   День 10. Итоги и план развития

   • Довести вторую задачу до merge либо зафиксировать следующий технический шаг.
   • Встреча с руководителем разработки и HR BP:
   • выполненные задачи;
   • что получилось самостоятельно;
   • где требуется помощь;
   • какие ожидания на первый месяц.
   • Наставник оценивает по четырём критериям:
   • рабочее окружение;
   • понимание кодовой базы;
   • качество коммуникации;
   • способность доводить небольшую задачу до результата.
   • Составить план на следующие 30 дней: 2–3 технические темы, тип задач и регулярность встреч.

   Ритм сопровождения

   • Ежедневно: 15 минут с наставником утром и 30 минут в конце дня.
   • 2 раза в неделю: короткая синхронизация с руководителем разработки.
   • 1 раз в неделю: командная встреча без отдельного доклада новичка.
   • Вопросы задавать в общем канале, если ответ может быть полезен другим; личные вопросы — наставнику.
   • Вести список вопросов и решений, чтобы не возвращаться к одной проблеме несколько раз.

   Контрольные результаты к концу 2 недель

   • Все необходимые доступы получены.
   • Проект запускается локально по инструкции.
   • Выполнены или начаты 2 небольшие задачи.
   • Открыт минимум 1 pull request и пройден цикл ревью.
   • Новичок знает, где искать документацию и к кому обращаться по типовым вопросам.
   • Зафиксированы пробелы в onboarding и план развития на первый месяц.

   Разница между оценками судей: недоступна: учтена оценка только одного судьи.

   Комментарии судей

   • Claude Opus: 9.25 — Сильная структура: цель, преддень, разбивка по дням с результатом на каждый день, ритм сопровождения и контрольные итоги — все требования задания (знакомство, рабочее место, первые задачи, встречи с наставником, доступ к документации) закрыты. Конкретика хорошая: реальные инструменты (Node.js/Python, Docker, CI), тип первых задач (доки, UI-баг, техдолг), разбор чужого PR, парное программирование, критерии оценки. Клише почти нет. По реализму минус: график плотный — ежедневно 15 мин утром + 30 мин вечером с наставником плюс 2 синка с руководителем в неделю для команды до 50 человек с минимальным бюджетом времени тяжеловат, и ожидание, что junior к дню 4 сам реализует изменение и доведёт две задачи до merge за 2 недели, оптимистично. Но в целом достижимо. Не хватает лёгкого буфера на срывы сроков и явного плана Б, если новичок отстаёт.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 8 из 10
     • Полнота: 10 из 10
5. MiniMax M3Ответ получен через APIСредняя оценка: 9.1

   План адаптации Junior-разработчика

   Длительность: 10 рабочих дней (2 недели) Ключевая фигура: наставник (Senior/Middle) — основной контакт на весь период, минимум 30% его времени на этой роли Артефакт на выходе: Junior самостоятельно делает PR с фичей в основной репозиторий и проходит code review

   ---

   1. До выхода (за 1–2 дня)

   Что делает HR/основатель:

   • Присылает письмо-приветствие: имя наставника, расписание первой недели, ссылка на Notion/Confluence с базой знаний
   • Создаёт учётки заранее: Git (GitHub/GitLab), таск-трекер (Linear/Jira), Slack, 1Password, VPN, корпоративная почта
   • Готовит ноутбук: ОС настроена, установлены IDE, Git, Docker, Node/Python/Java (зависит от стека), VS Code/IntelliJ с конфигом команды

   Что делает наставник:

   • Выбирает 2–3 «good first issues» в репозитории под Junior-уровень
   • Бронирует слоты в календаре на все 1:1 встречи на 2 недели вперёд

   ---

   2. День 1 — Ориентация

   Утро (до начала работы):

   • Рабочее место проверено заранее: монитор, периферия, доступ к Wi-Fi, гарнитура для звонков
   • Наставник встречает у входа/в Zoom, помогает с логинами и 2FA

   До обеда:

   • HR-встреча (60 мин): структура компании, кто product owner, кто tech lead, кто делает что, ближайшие релизы и OKR
   • Офис-тур или виртуальный тур по каналам в Slack: кто за что отвечает, какие каналы рабочие, какие — для оффтопа

   После обеда:

   • Обед с наставником + 1–2 разработчиками (не собеседование, неформальный разговор)
   • Техническая сессия с наставником (90 мин): клонирование репо, запуск проекта локально, прохождение README, объяснение архитектуры на верхнем уровне (диаграмма из Notion)

   Конец дня:

   • Junior пишет в Slack краткое саммари: что настроил, что получилось, где застрял (нормализация «не знаю» с первого дня)

   ---

   3. Дни 2–3 — Инструменты и процессы

   Фокус: не код, а инженерная гигиена

   • Code style и линтеры: наставник показывает настройки в репо, объясняет почему именно так
   • Git-flow команды: как именуются ветки, формат commit message, шаблон PR, требования к reviewers
   • Таск-трекер: как читать тикет, что означают статусы, как оценивать время, как задавать уточняющие вопросы (в тикете, а не в личке)
   • Документация: экскурсия по Notion — где архитектурные ADR, где runbook'и, где контакты по сервисам
   • Практика: Junior открывает учебный PR — фикс опечатки в README или обновление комментария в коде. Цель — пройти полный цикл: branch → commit → push → PR → review → merge

   1:1 с наставником: 30 мин в конце каждого дня, без повестки — что непонятно, что мешает

   ---

   4. Дни 4–5 — Погружение в код

   • Junior читает 2–3 ключевых модуля, к которым будет относиться первая задача. Наставник заранее делает «карту»: какие файлы смотреть, какие — игнорировать
   • Парное программирование (2 часа): наставник и Junior вместе пишут кусок кода, наставник комментирует решения вслух
   • Junior наблюдает за 1–2 code review на PR коллег (только читает, не комментирует)
   • Знакомство со смежными командами: 20-минутные встречи с QA, дизайнером, product owner (без слайдов — просто «чем ты занимаешься и как мы пересекаемся»)

   ---

   5. Неделя 2 — Первая боевая задача

   Дни 6–7:

   • Наставник выбирает тикет из backlog: ограниченный scope, чёткие acceptance criteria, затрагивает 1–2 модуля
   • Junior декомпозирует задачу сам, присылает план наставнику на согласование (не код — план)
   • Встреча с tech lead (30 мин): зачем эта задача нужна продукту, какие edge cases возможны

   Дни 8–9:

   • Реализация. Наставник доступен в Slack в течение дня, но не сидит рядом — Junior учится задавать вопросы письменно (это тренируется сразу)
   • Mid-week check-in с наставником (45 мин): прогресс, блокеры, корректировка scope при необходимости

   День 10:

   • PR открыт, наставник делает подробный review (не «ок, мерж», а построчно с пояснениями)
   • Junior отвечает на комментарии, вносит правки
   • Финальная встреча с наставником + tech lead (45 мин): ретро двух недель — что сработало, что изменить в процессе

   ---

   6. Встречи с наставником — регулярный ритм

   Структурированный ответ модели

   День	Формат	Длительность
   Ежедневно (дни 1–5)	1:1 без повестки	30 мин
   Дни 6, 8	Рабочий синк по задаче	45 мин
   День 10	Ретро + feedback	45 мин

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

   ---

   7. Доступ к документации (минимум, без перегруза)

   Junior получает в первый день ссылки только на эти материалы (остальное — по запросу, чтобы не утонуть):

   • 📄 README основного репозитория
   • 📄 Архитектурная диаграмма (1 страница в Notion)
   • 📄 ADR (Architecture Decision Records) — последние 3–5
   • 📄 Code style guide + PR template
   • 📄 Runbook по локальной разработке
   • 📄 Контакты по сервисам (к кому идти, если упал API X)

   Через неделю, когда Junior начнёт работать с задачей, добавляются:

   • API-спецификация релевантного сервиса
   • Документация по фреймворку/библиотеке, с которой предстоит работать

   ---

   8. Что фиксируется по итогам 2 недель

   Для Junior:

   • Понимает, как поднять проект, открыть PR и пройти review
   • Знает, у кого спрашивать про каждый сервис
   • Имеет merged PR в основной репозиторий

   Для компании:

   • Заполненный чек-лист адаптации (HR)
   • Обратная связь от Junior: что в процессе мешало (анонимная форма в Notion)
   • Решение: оставляем ли наставника на 3-ю неделю в режиме «по запросу» или переключаем на обычный ритм

   Разница между оценками судей: 0.3

   Комментарии судей

   • Claude Opus: 9.25 — Отличная структура: подзаголовки, разбивка по дням, таблица ритма встреч, чёткий артефакт на выходе (merged PR). Конкретика сильная — названы инструменты (Notion, Linear, 1Password), длительности встреч, форматы, состав документации по фазам; клише почти нет. Полнота идеальная: закрыты все требования ТЗ (знакомство с командой, настройка места, первые задачи, встречи с наставником, доступ к докам) плюс pre-onboarding, ретро и обратная связь. Реалистичность чуть ниже: 30% времени senior-наставника на 2 недели — дорого для стартапа до 50 человек с 'минимальным бюджетом', а merged PR с фичей в основной репо к 10-му дню для junior — амбициозно, зависит от удачно подобранного тикета. В остальном темп адекватный.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 8 из 10
     • Полнота: 10 из 10
   • ChatGPT Sol: 9 — План хорошо разбит по дням, содержит ответственных, длительность встреч, конкретные действия, результаты и обязательные элементы задания. Снижают реалистичность резервирование минимум 30% времени наставника для стартапа до 50 человек, перегруженный первый день и ожидание обязательного merged PR с боевой фичей ровно к 10-му дню. Для полноты не хватает явных критериев успешности первой задачи, плана действий при задержке доступов или PR и короткой проверки самочувствия и интеграции Junior со стороны HR.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 8 из 10
     • Полнота: 9 из 10
6. Claude OpusОтвет получен через APIСредняя оценка: 9.0

   Держи план. Сразу оговорюсь: он рассчитан на реального junior-а, а не на идеального студента из вакансии — значит, темп щадящий, но с первого дня есть код в проде.

   Адаптация junior-разработчика: 2 недели

   День 0 (за день до выхода) — подготовка, чтобы новичок не сидел в вакууме

   • Наставник заранее закреплён и предупреждён: это не «в нагрузку», а часть его нагрузки на 2 недели (заложи ему ~2 ч/день).
   • Созданы все доступы: репозиторий, CI, таск-трекер, мессенджер, почта, VPN, доступ к стейджингу. Junior не должен первый день писать в чат «а дайте доступ к…».
   • В таск-трекере уже висит его первая задача (см. День 2) и заведён эпик «Онбординг: <Имя>» с этим планом как чек-листом.
   • В личку отправлено короткое сообщение: во сколько прийти/подключиться, к кому подойти первым, ссылка на канал команды.

   Дни 1–2 — рабочее место, люди, первый коммит

   Настройка окружения

   • Наставник садится рядом (или в общий звонок с расшаренным экраном) и проходит README по сборке проекта вместе. Цель дня 1 — локально поднятый проект и зелёные тесты. Если README врёт или устарел — junior прямо по ходу правит его и делает первый PR (идеальная нулевая задача).
   • Заводим git по конвенциям команды: подпись коммитов, формат сообщений, ветки. Показать на живом примере, не ссылкой на вики.

   Знакомство с командой

   • Не общий митинг «поприветствуем нового», а 3–4 личных созвона по 20 минут с ключевыми людьми: тимлид, наставник, QA/тестировщик, продакт или тот, кто ставит задачи. Каждый рассказывает, за что отвечает и когда к нему идти.
   • Дать явную карту: «вопрос по коду → наставник, вопрос по задаче → продакт, сломался стейджинг → вот этот человек».

   Первый коммит в первый день

   • Мелкая реальная правка: опечатка в UI, устаревшая строка в доке, флаки-тест. Провести через полный цикл: ветка → PR → ревью → мёрдж. Смысл — не польза правки, а пройти весь пайплайн один раз, пока рядом есть наставник.

   Дни 3–5 — первая настоящая задача и погружение в код

   Первая задача

   • Выбрать баг или маленькую фичу, ограниченную одним модулем, с понятным «как проверить, что готово». Не архитектура, не то, что трогает пол-кодбазы.
   • Наставник декомпозирует её вместе с junior-ом на подшаги — это учит разбивать задачи, а не только их делать.
   • Договорённость по времени: застрял больше 30–40 минут — пиши наставнику. Это не слабость, это правило. Junior-ы тонут молча, если им не разрешить спрашивать.

   Работа с документацией

   • Не «прочитай всю вики». Дать 2–3 конкретных документа под текущую задачу: как устроен модуль, который он трогает; схема данных; как гоняются тесты.
   • Всё, чего не хватило в доке по ходу задачи, junior дописывает. К концу двух недель у тебя обновлённая дока и человек, который её понимает.

   Наставничество

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

   Дни 6–8 — довести задачу до прода, разобрать ревью

   • Первая задача уходит в прод (или на стейджинг по вашему процессу). Junior сам наблюдает за деплоем и проверяет результат — не «отдал и забыл».
   • Разбор код-ревью: наставник проходит по своим комментариям к PR и объясняет почему, а не только «поменяй здесь». Это главный обучающий момент всей адаптации.
   • Junior проводит своё первое (учебное) ревью чужого небольшого PR вместе с наставником — учится читать чужой код, а не только писать свой.

   Дни 9–12 — вторая задача, больше самостоятельности

   • Вторая задача — чуть сложнее и в соседнем модуле, чтобы расширить карту кодбазы. Декомпозицию junior пробует сам, наставник проверяет и корректирует.
   • Наставник переключается с «сидим рядом» на «доступен по запросу». Синки остаются, но junior сам ведёт задачу.
   • Подключить к рабочим ритуалам команды как полноценного участника: стендап, планирование, ретро. Не наблюдателем — с правом голоса. Открытость, которую ценит компания, проверяется именно здесь.

   Дни 13–14 — обратная связь в обе стороны и план на месяц

   Встреча-ретро по адаптации

   • Наставник + тимлид дают junior-у конкретную обратную связь: что уже хорошо, над чем работать. Без общих слов «молодец, расти дальше» — на примерах его PR.
   • Junior даёт обратную связь по онбордингу: что было непонятно, где дока подвела, чего не хватило. Ты как HR это собираешь и правишь процесс для следующего.

   План на 30–60 дней

   • Совместно наметить 2–3 зоны роста и один заметный кусок работы на следующий месяц, за который junior отвечает сам.
   • Зафиксировать, кто остаётся его точкой опоры после формального онбординга (обычно тот же наставник, но с меньшей нагрузкой).

   ---

   Что заложено под твои вводные:

   • Бюджет ~0 — обучение идёт через реальные задачи и наставника, без курсов и платных платформ.
   • Упор на наставничество — один закреплённый человек, ежедневные синки, разбор ревью как главный инструмент.
   • Открытость и быстрый рост — код в прод с первого дня, право голоса на ритуалах со второй недели, обратная связь в обе стороны.
   • Junior, а не middle — явное разрешение спрашивать, декомпозиция задач вместе, темп по нарастающей.

   Один нюанс: план живёт только если у наставника реально освобождено время. Если ему не срезать его собственные задачи на эти 2 недели — онбординг превратится в «разберёшься сам», и весь план ляжет. Это твоя зона ответственности как HR BP — договориться с тимлидом заранее.

   Задача закрыта. Если следующая несвязанная — открой новый чат.

   Разница между оценками судей: недоступна: учтена оценка только одного судьи.

   Комментарии судей

   • ChatGPT Sol: 9 — План отлично структурирован, содержит конкретные действия, роли, сроки, критерии результата и все обязательные элементы. Главный недостаток — 14 рабочих дней фактически занимают почти 3 недели, а не 2; для двухнедельного плана этапы нужно уложить в 10 рабочих дней. Также выпуск кода в прод с первого дня сформулирован слишком категорично: это зависит от рисков, процесса ревью и правил релиза.
     • Структура: 10 из 10
     • Конкретность: 10 из 10
     • Реалистичность: 7 из 10
     • Полнота: 9 из 10
7. GLM 5.2Ответ получен через APIСредняя оценка: 9.0

   Привет! Как HR BP, я понимаю, что в стартапе до 50 человек каждый новый сотрудник сильно влияет на динамику. У нас нет бюджета на дорогие курсы, поэтому наша главная ставка — это прозрачность процессов и плотная работа с наставником.

   Вот конкретный, без воды, план адаптации junior-разработчика на первые 2 недели.

   Подготовка (До выхода сотрудника)

   • Доступы: Завести корпоративную почту, аккаунты в Slack, Jira, GitHub/GitLab, доступ к Notion/Confluence.
   • Железо: Подготовить ноутбук, установить базовый софт (IDE, Docker, VPN), проверить доступы к внутренним репозиториям.
   • Анонс: Написать в общий канал Slack короткое сообщение о новичке: кто он, над чем будет работать, пара фактов о нем (хобби/интересы), чтобы снять неловкость первого дня.

   ---

   Неделя 1: Погружение и первые шаги

   День 1: Настройка и знакомство

   • Утро (HR BP): Встреча 1-1 (30 мин). Обзор оргструктуры (кто за что отвечает), краткая история продукта, правила коммуникации в стартапе (у нас нет жесткой бюрократии, можно писать напрямую фаундерам).
   • Знакомство с командой: Обед с командой разработки (наставник, тимлид, еще 1-2 разработчика). Без официоза, просто познакомиться.
   • Наставник (1 час): Встреча с наставником. Ожидания от двух недель: "Твоя задача сейчас — не писать идеальный код, а понять, как мы работаем". Выдача доступа к локальной среде.
   • Задача на день: Поднять проект локально, запустить, кликнуть по интерфейсу как пользователь.

   День 2-3: Документация и первая строка кода

   • Доступ к документации: Наставник дает ссылки в Notion на 3 конкретных документа: 1) Архитектура проекта (high-level), 2) Процесс деплоя, 3) Правила оформления PR (Pull Request).
   • Встречи: Теневое участие (shadowing) в Daily Standup. Новичок просто слушает, как команда синхронизируется, и запоминает сленг.
   • Наставник (30 мин): Разбор архитектуры. Наставник рисует схему на доске, как данные идут от фронта к базе.
   • Первая задача: "Good first issue". Например, исправить опечатку в UI, добавить логирование в один метод или поправить мелкий баг. Цель — пройти полный цикл: ветка -> коммит -> PR -> ревью -> мердж.

   День 4-5: Интеграция в процессы

   • Задача: Написать unit-тест для того самого мелкого бага/метода, который трогали вчера.
   • Наставник (1 час): Парное программирование (Pair programming). Наставник и джун вместе садятся за экран. Наставник пишет код, джун пишет тесты (или наоборот). Это лучший способ передать опыт без бюджета на курсы.
   • Встреча с HR BP (30 мин): Чек-ин. "Как доступы? Понятна ли документация? Не перегружен ли?".

   ---

   Неделя 2: Первая самостоятельная задача

   День 8-9: Работа над фичей

   • Задача: Тимлид ставит в Jira небольшую, изолированную фичу (например, добавить новое поле в существующую форму или написать простой эндпоинт, возвращающий список справочников).
   • Наставник (30 мин): Декомпозиция задачи. Джун сам предлагает, как он будет это делать, наставник корректирует маршрут, чтобы джун не пошел в сторону переписывания половины проекта.
   • Встречи: Участие в Grooming/Planning. Джун смотрит, как тимлид и команда оценивают задачи, может задать вопросы по бэклогу.

   День 10-11: Code Review и фидбек

   • Задача: Завершить фичу, оформить PR по стандартам из документации.
   • Наставник (1 час): Разбор PR. Наставник не просто пишет "исправь тут", а объясняет почему мы в стартапе пишем именно так (например, почему мы жертвуем идеальной архитектурой ради скорости релиза).
   • Встреча с HR BP (30 мин): Обсуждение атмосферы в команде. Адекватен ли наставник? Есть ли страх задавать "глупые" вопросы? (В стартапе их быть не должно).

   День 12: Релиз и ретроспектива

   • Задача: Попасть в релиз. Проследить, как фича уезжает на прод (или стенд), проверить, что ничего не сломалось.
   • Демо: Джун сам презентует свою первую фичу на еженедельном демо всей компании (2-3 минуты). Это повышает вовлеченность и дает ощущение полезности.

   День 13-14: Планирование испытательного срока

   • Встреча: HR BP + Тимлид + Джун (1 час): Подведение итогов двух недель.
   • Результат встречи: Постановка 3 конкретных целей на испытательный срок (например: "Самостоятельно закрывать до 3 задач в спринте", "Покрыть тестами модуль X", "Провести презентацию для команды о том, как работает твоя подсистема").

   Ключевые правила для наставника (передаются от HR BP):

   1. Не давать готовых ответов. Направлять джун к документации или гуглу: "Посмотри, как это реализовано в модуле Y, там похожий паттерн".
   2. Хвалить за заданные вопросы, а не только за закрытые тикеты.
   3. Если джун застрял на проблеме больше 2 часов — он обязан позвать наставника. Это правило спасает от выгорания в первый месяц.

   Разница между оценками судей: 0.5

   Комментарии судей

   • Claude Opus: 9.25 — Сильный ответ. Структура образцовая: этап подготовки до выхода, разбивка по неделям и дням, отдельный блок правил для наставника, финал с целями на испытательный срок. Конкретность высокая — названы конкретные инструменты (Slack, Jira, Notion), длительность встреч, тип задач (good first issue, unit-тест, изолированная фича), формат работы (shadowing, pair programming). Реалистичность соответствует стартапу до 50 человек с упором на наставничество и нулевым бюджетом на курсы — ставка на парное программирование и внутреннюю документацию логична. Полнота: закрыты все требования задания (знакомство с командой, настройка рабочего места, первые задачи, встречи с наставником, доступ к документации), плюс добавлены демо и ретро. Минусы мелкие: пропущены дни 6-7 (видимо выходные, но явно не оговорено), клише-вступление 'без воды' само по себе слегка клишировано, а формулировка целей на испытательный срок могла бы быть измеримее по срокам.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 9 из 10
     • Полнота: 9 из 10
   • ChatGPT Sol: 8.75 — План хорошо структурирован, охватывает все обязательные элементы и содержит конкретные встречи, задачи, сроки и ожидаемые результаты. Реалистичность снижена из-за путаницы между календарными и рабочими днями, гарантированного релиза за 2 недели и спорной цели закрывать до 3 задач в спринте без учета сложности. Вступление и отдельные формулировки содержат клише, хотя задание просило их избегать.
     • Структура: 9 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 8 из 10
     • Полнота: 9 из 10
8. GLM 5.1Ответ получен через APIСредняя оценка: 9.0

   Пре-онбординг (до выхода на работу)

   • Доступы заранее: Отправка на личную почту ссылок на Google Workspace/GitHub/Jira и временных паролей. Инструкция по настройке 2FA.
   • Анкета новичка: Короткая форма (любимый напиток/снек, как обращаться, часовой пояс) для анонса в общем чате.
   • Аппаратное обеспечение: Доставка ноутбука курьером (если удаленка) или подготовка рабочего места в офисе с установленной базовой IDE.

   ---

   Неделя 1: Инфраструктура и первый коммит

   День 1: Настройка и знакомства

   • Утро (10:00): Встреча с HR. Передача оборудования, обход офиса (или виртуальная карта Miro для удаленки). Выдача чек-листа на неделю.
   • Знакомство с командой: 15-минутные 1-to-1 с Тимлидом и Продактом. Фокус: кто чем занимается, как мы общаемся, какие сейчас приоритеты.
   • Наставник (Mentor): Установка правил взаимодействия. Наставник озвучивает формат: «Пиши в слак в любой момент, если вопрос блокирует работу дольше 15 минут — подходи/звони».
   • Настройка рабочего места: Клонирование репозиториев, запуск проекта локально. Если проект не собирается с первого раза — это первая совместная задача с наставником.
   • Документация: Доступ в Notion/Confluence. Чтение документа «Архитектура проекта (High-level)» и «Соглашения по коду (Code Style)».

   День 2: Процессы и песочница

   • Утро (11:00): Встреча с наставником (30 мин). Разбор вчерашних блокеров. Ответы на вопросы по архитектуре.
   • Процессы: Демонстрация работы CI/CD (наставник показывает, как проходит пайплайн). Правила создания веток (gitflow) и нейминга коммитов.
   • Первая задача (Sandbox): Выдача таски уровня good first issue (исправление опечатки в UI, добавление локализованной строки, мелкий рефакторинг утилиты). Цель — пройти полный цикл: ветка -> коммит -> Pull Request.
   • Документация: Изучение схемы БД и API (Swagger/Postman коллекции).

   День 3: Code Review и погружение в продукт

   • Утро: Наставник проводит Code Review первого PR. Разбор замечаний голосом (важно для джуна, чтобы не было страха перед красными комментариями).
   • Встреча с QA: 20 минут с тестировщиком. Как мы тестируем, где заводим баги, что должно быть в описании к PR, чтобы тестировщику было понятно.
   • Продукт: Самостоятельное изучение демо-стенда. Попытка пройти основной юзкейс клиента.

   День 4: Первая боевая задача

   • Утро (11:00): Встреча с наставником. Обсуждение первой реальной задачи (небольшой баг-фикс или микро-фича на 1-2 дня).
   • Правило оценки: Джун озвучивает свою оценку времени. Наставник умножает её на 2 (скрыто от джуна) для планирования, но помогает джуну декомпозировать задачу, чтобы она казалась реалистичной.
   • Работа: Написание кода. Наставник доступен для вопросов, но не пишет код за джуна.

   День 5: Ретроспектива недели

   • Утро: Работа над задачей, создание PR.
   • Встреча с наставником (45 мин): Разбор PR. Ретроспектива недели: что далось легко, где застревал, хватает ли документации.
   • Встреча с HR (20 мин): Проверка бытовых моментов. Выдача доступа к корпоративному скидкам, ответы на вопросы про отпуска и дедлайны.
   • Документация: Джун обновляет README.md проекта, если в процессе настройки нашел неточности (привыкаем оставлять проект лучше, чем нашел).

   ---

   Неделя 2: Самостоятельность и кросс-функциональность

   День 6: Планирование спринта

   • Утро: Участие в Sprint Planning (в режиме слушателя/наблюдателя). Понимание, как задачи попадают в бэклог и как формируется план.
   • Задачи: Взятие новой фичи. Наставник просит джуна самому написать шаги воспроизведения и план реализации в комментарии к тикету перед началом кодинга.

   День 7: Архитектурный контекст

   • Утро (11:00): Встреча с наставником. Ревью плана реализации фичи. Корректировка подхода до написания кода (предотвращение переписывания с нуля).
   • Встреча с DevOps/Сисадмином: 20 минут. Как смотрим логи (Kibana/Grafana), что делать, если упал прод (алерты, дежурства).
   • Работа: Кодинг по утвержденному плану.

   День 8: Кросс-функциональные связи

   • Утро: Работа над задачей. Создание PR.
   • Встреча с Продактом (20 мин): Обсуждение бизнес-логики текущей задачи. Зачем мы делаем именно эту фичу, какую метрику она должна улучшить.
   • Code Review: Получение фидбека не только от наставника, но и от другого миддла/сеньора из команды (расширение кругозора и снижение зависимости от одного человека).

   День 9: Дежурства и инциденты

   • Утро (11:00): Встреча с наставником. Разбор текущих блокеров.
   • Shadowing: Джун прикрепляется к дежурному разработчику на 2 часа. Смотрит, как тот обрабатывает алерты, отвечает в чат поддержки, чинит срочные баги.
   • Работа: Доработка фичи по результатам Code Review. Мердж в основную ветку.

   День 10: Итоги адаптации

   • Утро: Участие в Daily/Sync.
   • Встреча 1-to-1 с Тимлидом (30 мин): Обсуждение прогресса. Тимлид озвучивает ожидания на испытательный срок (конкретные навыки: "самостоятельно поднимать окружение", "писать тесты на свои модули").
   • Встреча с наставником и HR (45 мин): Финальная встреча периода онбординга. Честный фидбек от джуна: что бесило, чего не хватило. Фидбек от наставника: скорость погружения, качество кода, самостоятельность.
   • Документация: Фиксация плана на следующий месяц. Переход от формата "каждодневные синки" к формату "синки по запросу 2-3 раза в неделю".

   Разница между оценками судей: 0.5

   Комментарии судей

   • Claude Opus: 9.25 — Отличная структура: чёткие подзаголовки, разбивка по неделям и дням, тайминг встреч. Все требования задания закрыты — знакомство с командой, настройка рабочего места, первые задачи, регулярные встречи с наставником, доступ к документации (Notion/Confluence, схема БД, Swagger). Конкретика сильная: реальные инструменты (Miro, Kibana/Grafana), градация задач от good first issue до боевой фичи, shadowing дежурного, кросс-функциональные встречи с QA/DevOps/Продактом. Клише почти нет. Минус по реалистичности: приём 'наставник умножает оценку джуна на 2, скрыто от джуна' — сомнительная и слегка манипулятивная механика, лучше обучать честной декомпозиции открыто; план на 2 недели плотный, для настоящего junior риск перегруза встречами. Упор на наставничество при минимальном бюджете выдержан точно.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 8 из 10
     • Полнота: 10 из 10
   • ChatGPT Sol: 8.75 — План чётко разбит по этапам и дням, содержит расписание, конкретные задачи, встречи с наставником, настройку окружения и работу с документацией. Снижает реалистичность перегруженность встречами, привязка к необязательным инструментам и процессам, передача временных паролей по личной почте, скрытое удвоение оценки и раннее погружение джуна в продовые инциденты. Не хватает явных ответственных, критериев успешного завершения каждой недели и резервного сценария, если первая боевая задача затянется.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 7 из 10
     • Полнота: 9 из 10
9. Qwen 3.5 PlusОтвет получен через APIСредняя оценка: 9.0

   Неделя 1: Контекст, окружение и первый код

   День 1. Рабочее место и вводный контекст

   • Выдача ноутбука, настройка ОС, IDE, Docker, ключей SSH, доступов к Git, CI/CD, Jira, мессенджерам, внутренней базе знаний
   • 30-минутный звонок с HR BP: каналы коммуникации, ожидания по скорости обучения, правила запроса помощи
   • Встреча с наставником (45 мин): карта архитектуры, критические сервисы, стандарты ветвления, критерии принятия PR
   • Знакомство с командой: 15-минутные мини-встречи с каждым участником (роль, зона ответственности, как лучше обращаться)

   День 2. Погружение в код и процессы

   • Чтение CONTRIBUTING.md, гайдлайнов код-ревью, правил написания тестов, структуры репозитория
   • Локальная сборка проекта: запуск тестов, настройка переменных окружения, проверка CI-пайплайна
   • Разбор 3 закрытых PR наставника: выбор подхода, почему отвергли альтернативы, как оформляли описание
   • Вечерний чек-ин с наставником (15 мин): блокеры по окружению, вопросы по документации

   День 3. Первый пул-реквест

   • Задача: исправление опечатки в документации или мелкий баг с лейблом good first issue
   • Создание ветки, коммит по conventional commits, пул-реквест по шаблону команды
   • Настройка линтера и пре-коммит хуков, прохождение базовых тестов в CI
   • Live-ревью от наставника в течение дня: комментарии прямо в PR, разбор одного архитектурного решения

   День 4. Командный ритм и обратная связь

   • Участие в дейли-стендапе: формат отчета, как обозначать блокеры, где брать контекст задачи
   • Наблюдение за рефайнментом или планированием (если совпадает): как декомпозируют задачи, где хранятся требования
   • Встреча с наставником (30 мин): разбор первого PR, фидбек по тестам, описанию, скорости реакции на комментарии
   • Практика поиска ответов: как использовать внутреннюю базу знаний, когда писать в общий чат, когда — в личку наставнику

   День 5. Итоги недели 1

   • Самостоятельное решение второй задачи (мелкая фича/рефакторинг без изменения публичных API)
   • Встреча с HR BP (20 мин): комфорт процесса, качество онбординга, вопросы по адаптации
   • Планирование недели 2 с наставником: выбор задачи из бэклога, критерии готовности, ожидаемый объем кода
   • Закрытие временных доступов, настройка уведомлений CI/CD, фиксация частых вопросов в заметках

   ---

   Неделя 2: Интеграция, самостоятельность и метрики роста

   День 6. Парное программирование и реальные задачи

   • Pair-программинг с наставником или сеньором (2 часа): разбор сложного модуля, отладка, работа с логами/метриками
   • Выбор задачи из бэклога с пометкой junior-friendly или first-own-feature
   • Настройка локального мониторинга: как смотреть логи, воспроизводить баги, проверять edge-кейсы

   День 7. Кросс-функциональный контакт

   • 30-минутная встреча с продуктом/дизайном/тестированием: где брать требования, как уточнять неочевидное, где хранятся макеты/спеки
   • Разбор одного инцидента из прошлых спринтов: хронология фикса, что изменили в процессах, как джун может помочь в будущем
   • Вечерний чек-ин с наставником (15 мин): прогресс по задаче, риски, нужна ли помощь с зависимостями

   День 8. Документация и обмен знаниями

   • Обновление README или добавление заметки в базу знаний по итогам работы (как запускать, какие подводные камни)
   • Участие в техническом шеринге или просмотр записи: фиксация 3 практических инсайтов
   • Наставник оценивает, как джун формулирует вопросы, ищет решения, использует поиск по кодовой базе

   День 9. Самостоятельная работа и проверка

   • Завершение задачи, покрытие тестами, подготовка к ревью, проверка CI-статусов
   • Проведение ревью чужого PR (под наблюдением наставника): оценка читаемости, тестов, соответствия стандартам
   • Встреча с наставником (30 мин): качество кода, скорость, коммуникация, что делать иначе в следующий раз

   День 10. Итоги 2 недель и план на месяц

   • Демо выполненной задачи команде (5–10 мин): что сделано, какие решения приняты, что осталось на будущее
   • Встреча с наставником и HR BP (40 мин): фидбек по 3 направлениям (код, процессы, коммуникация), сильные стороны, зоны роста
   • Формирование индивидуального плана на месяц: 2–3 конкретные цели, метрики готовности, следующие задачи из бэклога
   • Переход в режим регулярных 1:1 с наставником (раз в неделю), закрепление канала для срочных вопросов, закрытие онбординга

   Разница между оценками судей: 0.0

   Комментарии судей

   • Claude Opus: 9 — Структура образцовая: две недели, дни с подзаголовками, внутри дня сгруппированы место/наставник/задачи/команда/доки — все требования задания закрыты, включая доступ к документации и встречи с наставником. Конкретность высокая: реальные артефакты (CONTRIBUTING.md, conventional commits, good first issue, pre-commit хуки, live-ревью, демо), почти без клише. Главная просадка — реалистичность: для junior это очень плотный график. День 1 требует настройки ноутбука + звонка с HR + встречи с наставником по архитектуре + мини-встреч со всей командой — за один день это перегруз, особенно когда доступы часто отваливаются. К дню 3 ждут первый PR с линтером и CI, к дню 6 — парное на 'сложном модуле', к дню 9 — проведение ревью чужого PR: для новичка за 2 недели амбициозно, риск фрустрации. Также 'закрытие временных доступов' в день 5 звучит странно, если человек остаётся. Полнота отличная: добавлены кросс-функциональный контакт, разбор инцидента, метрики роста и план на месяц — сверх минимума задания.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 7 из 10
     • Полнота: 10 из 10
   • ChatGPT Sol: 9 — План четко разбит по дням, охватывает все обязательные элементы и содержит конкретные встречи, задачи, длительность и результаты. Снижена реалистичность: программа местами перегружена для junior-разработчика, наличие готовых junior-friendly задач, записей шерингов и подходящего инцидента не гарантировано, а закрытие временных доступов на 5-й день выглядит необоснованно. Для полноты не хватает ответственных за выдачу доступов, критериев успешного завершения каждой недели и запасного сценария при блокерах.
     • Структура: 10 из 10
     • Конкретность: 9 из 10
     • Реалистичность: 8 из 10
     • Полнота: 9 из 10
10. MiniMax M2.7Ответ получен через APIСредняя оценка: 8.8

    План адаптации Junior-разработчика

    Неделя 1: Основы

    День 1 — Встреча с наставником (утро, 2 часа)

    • Наставник выдаёт доступы: почта, Slack, Jira/Linear, Git-репозитории, VPN
    • Совместная настройка рабочего окружения: IDE, линтеры, форматирование кода
    • Наставник показывает структуру проекта в репозитории, объясняет naming conventions
    • Обсуждают, в каких каналах Slack что происходит (general, dev, deploys, incidents)

    День 1 — Знакомство с командой (после обеда)

    • Наставник организует обход: product owner, дизайнер, QA, DevOps, второй разработчик
    • Каждая встреча — 15 минут, неформальный формат, без презентаций
    • Цель: понять, кто за что отвечает и как пересекаются потоки работы

    День 2 — Документация

    • Наставник проводит 1.5-часовой созвон по документации: архитектура, схема БД, API-контракты
    • Junior читает README в репозиториях, составляет список вопросов
    • Наставник отвечает на вопросы в конце дня (30 минут)

    День 2 — Первая задача

    • Наставник даёт задачу уровня «исправить опечатку в тексте» или «добавить одно поле в форму»
    • Цель: пройти путь от создания ветки до merge самостоятельно, пусть с подсказками
    • Обязательно: сделать PR, получить хотя бы один review

    День 3 — Процессы

    • Наставник показывает процесс code review: что смотрят, как пишут комментарии, как реагировать на замечания
    • Разбирают последний merged PR в команде как пример
    • Обсуждают, как ставятся задачи в Jira/Linear: критерии готовности, приоритеты

    День 3–4 — Самостоятельная работа

    • Junior берёт задачу чуть сложнее: исправление бага, добавление несложной фичи
    • Наставник доступен в Slack, но не вмешивается без запроса
    • Обязательный ритуал: вечером — 15-минутный созвон разбора проблем и вопросов

    День 5 — Обратная связь

    • Наставник проводит 30-минутную встречу: что получилось, что непонятно, что тормозит
    • Корректируют план на вторую неделю, если нужно

    ---

    Неделя 2: Погружение

    День 6–7 — Работа с фичей

    • Junior получает задачу, затрагивающую frontend и backend
    • Наставник на связи для консультаций, но не делает за него
    • Обязательно: написать unit-тесты, если они есть в проекте

    День 8 — Встреча с product owner

    • Наставник приглашает на 30-минутную встречу с PO
    • Junior слушает, как обсуждают приоритеты и ограничения
    • Задача: понять, откуда берутся требования и как они превращаются в задачи

    День 9 — Деплой и мониторинг

    • Наставник показывает процесс деплоя: что происходит после merge, как проверить на staging
    • Знакомство с логами, алертами, дашбордами (Grafana, Sentry или аналоги)
    • Junior деплоит свою задачу самостоятельно под наблюдением

    День 10 — Работа с инфраструктурой

    • DevOps или наставник показывает, как устроен CI/CD, где смотреть пайплайны
    • Разбирают, что делать, если deploy упал

    День 11–12 — Самостоятельный участок работы

    • Junior берёт задачу среднего уровня сложности
    • Наставник проверяет только готовый PR, не промежуточные шаги
    • В конце дня — разбор: что бы наставник сделал иначе

    День 13 — Финальная встреча

    • Наставник даёт обратную связь по итогам двух недель
    • Обсуждают зоны роста на ближайший месяц
    • Договариваются о регулярности созвонов: минимум 3 раза в неделю по 20 минут

    День 14 — Не обязательно рабочий

    • Если пятница — выходной, на этом всё
    • Если рабочий — лёгкая задача, нет давления

    ---

    Что должно быть у наставника в течение двух недель

    • Быть онлайн в рабочие часы, отвечать в Slack в течение часа
    • Не делать работу за junior, а направлять
    • Фиксировать прогресс: что освоено, где пробелы
    • К концу второй недели junior должен уметь: создать ветку, написать код, сделать PR, пройти review, задеплоить на staging

    Разница между оценками судей: 1.0

    Комментарии судей

    • Claude Opus: 9.25 — Чёткая иерархия недели→дни→блоки с подзаголовками, читается сразу — структура почти эталонная. Конкретика сильная: названы инструменты (Slack, Jira/Linear, Grafana, Sentry, CI/CD), длительности встреч, тип первых задач по нарастанию сложности, критерии готовности к концу двух недель. Реалистично и учитывает контекст стартапа: упор на наставничество вместо платного обучения (бьётся с минимальным бюджетом), градация задач от опечатки до фичи frontend+backend, разумная обработка Дня 14. Полнота: все требования задания закрыты — знакомство с командой, настройка окружения, первые задачи, встречи с наставником и PO, доступ к документации. Минусы мелкие: День 2 перегружен (документация + первая задача одновременно), бюджет явно не проговорён (только косвенно через менторство), а unit-тесты и деплой на staging завязаны на оговорку «если есть в проекте» — для junior стоило бы дать чёткую цель. Клише и вода отсутствуют.
      • Структура: 10 из 10
      • Конкретность: 9 из 10
      • Реалистичность: 9 из 10
      • Полнота: 9 из 10
    • ChatGPT Sol: 8.25 — План хорошо структурирован по дням, содержит конкретные действия, длительность встреч, ожидаемые результаты и все обязательные элементы задания. Реалистичность снижена из-за календарной ошибки: двухнедельная адаптация обычно включает 10 рабочих дней, но план растянут до дня 14 и содержит странную оговорку про пятницу как выходной. Для junior в маленьком стартапе задачи на стыке frontend и backend, самостоятельный деплой и задача средней сложности уже на второй неделе могут оказаться чрезмерными без критериев выбора и запасного сценария. Формулировка про unit-тесты только при их наличии также ослабляет требования к качеству.
      • Структура: 9 из 10
      • Конкретность: 9 из 10
      • Реалистичность: 6 из 10
      • Полнота: 9 из 10
11. DeepSeek V4 FlashОтвет получен через APIСредняя оценка: 8.8

    Этот план адаптирован под реалии стартапа до 50 человек: минимум бюрократии, максимум погружения в продукт и код. Наставник (Senior или Tech Lead) выделяет 1–1,5 часа в день на новичка в первые 2 недели.

    Цель: К концу 2-й недели junior должен сделать первый осмысленный коммит в основную ветку (feature flag или багфикс) и понимать, куда «стучаться» с вопросами.

    ---

    Неделя 1: Погружение в контекст и инфраструктуру

    День 1: «Welcome & Tooling»

    • 09:00 — 09:30 Встреча с HR BP / CEO (10 мин) + наставник. Выдача ноутбука, доступов (GitHub, Slack, Jira/Linear, корпоративная почта, VPN).
    • 09:30 — 11:00 Настройка окружения под руководством наставника (парное программирование настройки):
    • Установка IDE, Docker, менеджера пакетов.
    • Клонирование репозитория, запуск проекта локально (должен «завестись» с первого раза, если есть README).
    • 11:00 — 12:00 Чтение документации (только 3 файла):
    • README.md (как запустить проект).
    • CONTRIBUTING.md (правила коммитов, code review).
    • ARCHITECTURE.md (схема сервисов, если есть).
    • 12:00 — 13:00 Обед с командой (неформально, без обсуждения задач).
    • 13:00 — 14:00 Знакомство с командой по кругу (5-минутные 1:1 с каждым разработчиком, QA, PM). Задача: узнать, кто отвечает за какую часть кода.
    • 14:00 — 15:00 Первая задача: найти и исправить опечатку в документации (намеренно оставленную наставником) или добавить комментарий к непонятному куску кода. Цель — сделать первый merge request.
    • 15:00 — 16:00 Ретроспектива дня с наставником: что было непонятно, какие вопросы остались.

    День 2: «Бизнес-логика и первые правки»

    • 10:00 — 11:00 Воркшоп от наставника: «Как устроен наш основной микросервис» (только 1 диаграмма последовательности, без лишних деталей).
    • 11:00 — 12:00 Знакомство с тестовой средой (staging). Задача: задеплоить свою вчерашнюю правку на тестовый стенд (под контролем наставника).
    • 12:00 — 13:00 Обед.
    • 13:00 — 14:30 Первая «живая» задача: написать unit-тест для существующей функции (самой простой, без моков). Наставник проверяет тест и объясняет, как запускать тесты в CI.
    • 14:30 — 15:30 Code review теста от наставника (вживую, через экран). Объяснение, почему код-ревью — это норма.
    • 15:30 — 16:00 Заполнение «Карты компетенций» (Google Doc): что знаю / что не знаю / что хочу изучить.

    День 3: «Баги и коммуникация»

    • 10:00 — 10:30 Ежедневный стендап команды (участвует как слушатель, потом задаёт 1 вопрос).
    • 10:30 — 12:00 Поиск и исправление бага низкой сложности (например, неправильный текст ошибки или кривой CSS). Наставник даёт ссылку на баг-трекер с фильтром «good first issue».
    • 12:00 — 13:00 Обед.
    • 13:00 — 14:00 Встреча с QA-инженером: как писать баг-репорты, что такое «воспроизводимо».
    • 14:00 — 15:00 Доработка бага: написание теста, проверка на staging.
    • 15:00 — 16:00 1:1 с наставником: разбор типичных ошибок новичков в проекте (логирование, обработка ошибок, нейминг).

    День 4: «Работа с Git и код-ревью»

    • 10:00 — 11:00 Практикум по Git (только rebase, squash, разрешение конфликтов). Наставник создаёт искусственный конфликт.
    • 11:00 — 12:30 Junior делает merge request для своего бага. Участвует в код-ревью с командой (комментирует чужие MR, задаёт вопросы).
    • 12:30 — 13:30 Обед.
    • 13:30 — 15:00 Вторая задача: добавить логирование в ключевые точки (по списку от наставника). Цель — понять, как работает мониторинг.
    • 15:00 — 16:00 Встреча с DevOps (если есть) или тимлидом: как деплоится продакшн, что такое feature flags.

    День 5: «Ретроспектива первой недели»

    • 10:00 — 11:00 Самостоятельная работа: исправить замечания по код-ревью за неделю.
    • 11:00 — 12:00 Демо наставнику: показать, что сделано за неделю (2-3 коммита).
    • 12:00 — 13:00 Обед.
    • 13:00 — 14:00 Заполнение чек-листа адаптации (см. ниже).
    • 14:00 — 15:00 1:1 с HR BP: обратная связь, что нравится/не нравится, корректировка плана на 2-ю неделю.
    • 15:00 — 16:00 Легкая задача на выходные (опционально): прочитать 1 главу из внутренней базы знаний по архитектуре.

    ---

    Неделя 2: Самостоятельность и первый фича-флаг

    День 6: «Первая фича под присмотром»

    • 10:00 — 11:00 Получение задачи: реализовать простой эндпоинт (например, GET /health или добавление поля в ответ API). Наставник даёт ТЗ в 3 предложениях.
    • 11:00 — 13:00 Самостоятельная работа (наставник доступен в Slack, но не сидит рядом). Junior пишет код, тесты, документацию.
    • 13:00 — 14:00 Обед.
    • 14:00 — 15:30 Парное программирование с наставником: рефакторинг написанного кода, объяснение best practices.
    • 15:30 — 16:00 Деплой на staging.

    День 7: «Работа с базой данных»

    • 10:00 — 11:00 Воркшоп: как писать миграции (на примере добавления колонки).
    • 11:00 — 12:30 Задача: написать миграцию и обработать её в коде (с проверкой на существование).
    • 12:30 — 13:30 Обед.
    • 13:30 — 15:00 Написание интеграционного теста для новой миграции.
    • 15:00 — 16:00 Code review от другого разработчика (не наставника) — первый опыт ревью от «чужака».

    День 8: «Ошибки и исключения»

    • 10:00 — 11:00 Разбор реального инцидента на проде (за последний месяц). Наставник показывает логи и explain.
    • 11:00 — 12:30 Задача: добавить обработку ошибок в свой эндпоинт (404, 500, валидация).
    • 12:30 — 13:30 Обед.
    • 13:30 — 15:00 Написание документации к своему эндпоинту (Swagger/OpenAPI или README).
    • 15:00 — 16:00 Встреча с продакт-менеджером: как фичи попадают в бэклог, приоритизация.

    День 9: «Code Review чужого кода»

    • 10:00 — 11:00 Junior получает 2 чужих MR (от других разработчиков) и пишет к ним ревью (только стиль, нейминг, тесты). Наставник проверяет качество ревью.
    • 11:00 — 12:30 Исправление замечаний по своему MR (если есть).
    • 12:30 — 13:30 Обед.
    • 13:30 — 15:00 Подготовка к демо: написать краткий пост в Slack о том, что сделано за 2 недели.
    • 15:00 — 16:00 1:1 с наставником: разбор «слепых зон» — что junior до сих пор не спросил, но должен знать.

    День 10: «Финальное демо и план роста»

    • 10:00 — 11:00 Финальное демо для команды (5-7 минут): показать свой эндпоинт, тесты, документацию.
    • 11:00 — 12:00 Получение доступа к продакшену (только read-only логи) и просмотр метрик своего кода.
    • 12:00 — 13:00 Обед с командой (пицца/суши за счёт компании).
    • 13:00 — 14:00 Заполнение «Карты компетенций» (сравнение с первой неделей).
    • 14:00 — 15:00 Встреча с HR BP: утверждение плана развития на следующий месяц (какие технологии учить, какие книги читать).
    • 15:00 — 16:00 Передача ответственности: junior становится «дежурным» по баг-трекеру на следующую неделю (с поддержкой наставника).

    ---

    Чек-лист для наставника (внутренний)

    • [ ] День 1: Убедиться, что проект собирается без ошибок.
    • [ ] День 3: Дать задачу, которая гарантированно решается за 2 часа.
    • [ ] День 5: Проверить, что junior знает, где лежат логи и как перезапустить сервис.
    • [ ] День 7: Убедиться, что junior не боится писать миграции.
    • [ ] День 10: Оценить, может ли junior самостоятельно сделать простой CRUD.

    Метрики успеха адаптации

    1. Количество коммитов: минимум 5 за 2 недели.
    2. Количество принятых MR: минимум 2 (1 багфикс, 1 фича).
    3. Время первого ответа на вопрос в Slack: junior знает, к кому обратиться, не ждёт наставника >15 минут.
    4. Обратная связь от команды: «Не тормозит процесс, задаёт правильные вопросы».

    Разница между оценками судей: 0.5

    Комментарии судей

    • Claude Opus: 9 — Структура образцовая: недели → дни → тайм-слоты, плюс чек-лист наставника и метрики успеха, все обязательные блоки задания закрыты (знакомство, окружение, задачи, 1:1, документация). Конкретность высокая — реальные файлы (README, CONTRIBUTING), 'good first issue', намеренная опечатка для первого MR, ТЗ в 3 предложениях; клише почти нет. Полнота избыточна в хорошем смысле: добавлены карта компетенций, план роста, дежурство по баг-трекеру. Слабое место — реалистичность: поминутный жёсткий график на 2 недели противоречит заявленному 'минимум бюрократии', а темп (деплой правки на staging в день 1, миграция в день 7, свой эндпоинт в день 6) оптимистичен для junior и почти не оставляет буфера на реальные затыки и разброс скорости. В живом стартапе план поедет уже к среде первой недели.
      • Структура: 10 из 10
      • Конкретность: 9 из 10
      • Реалистичность: 7 из 10
      • Полнота: 10 из 10
    • ChatGPT Sol: 8.5 — План отлично структурирован, содержит расписание, конкретные задачи, встречи, доступы, документацию и измеримые результаты. Реалистичность снижена из-за перегруза junior и наставника: за 2 недели запланированы багфикс, эндпоинт, миграция, интеграционные тесты, ревью чужого кода и дежурство. Некоторые решения спорны: задача на выходные, выдача продакшен-доступа, искусственная опечатка и метрика в 5 коммитов оценивают активность, а не освоение работы. Также заявленные 1–1,5 часа наставника в день не совпадают с фактическим объёмом встреч.
      • Структура: 10 из 10
      • Конкретность: 9 из 10
      • Реалистичность: 6 из 10
      • Полнота: 9 из 10
12. Claude SonnetОтвет получен через APIСредняя оценка: 8.5

    План адаптации джуна на 2 недели

    Условия: команда до 50 человек, бюджета на курсы нет, наставник — единственный canonical источник знаний. План строю так, чтобы к концу недели 1 джун закоммитил первый мердж-реквест в прод, а к концу недели 2 — вёл свою вторую задачу без сопровождения на каждом шаге.

    Неделя 1

    День 1 — вход и первый коммит малой кровью

    • Утро. HR BP лично проводит 30-минутную встречу: кто есть кто в компании (не орг-структура из Notion, а «к кому идти с чем» — 5-6 конкретных имён и их зона ответственности).
    • Настройка. Доступы выдаются заранее, до выхода: репозиторий, VPN/staging, таск-трекер, Slack/Telegram-каналы команды. Джун не должен тратить день 1 на ожидание доступов от IT.
    • Наставник назначен и представлен лично, не письмом. Первая встреча один на один — 45 минут: наставник рассказывает свой стиль работы (когда пишет в личку, когда ждёт вопроса в канале, как часто ревьюит).
    • Первая задача выдаётся в первый день, не на второй. Критерий: баг или мелкий тех-долг, который трогает 1-2 файла, имеет чёткий acceptance criteria, и по которому наставник уже знает решение (чтобы ревью было быстрым). Цель — смёрженный PR к пятнице, не к концу второй недели.
    • Конец дня. Джун сам пишет в общий канал команды: кто он, чем занимался раньше, что будет делать первым. Не HR пишет за него — это должен быть его голос.

    Дни 2-3 — контекст через код, не через документы

    • Наставник проводит live-разбор архитектуры на реальном коде (не диаграмма в Miro): открывают вместе 3-4 ключевых модуля, наставник объясняет, почему сделано именно так, а не иначе, где грабли.
    • Джун получает доступ к актуальной документации — не ко всей вики, а к конкретному списку из 5-7 страниц, которые наставник считает нужными прямо сейчас (README проекта, гайд по деплою, конвенции код-стайла, схема БД если есть). Остальное — по запросу.
    • Ежедневная 15-минутная синхронизация с наставником: не статус-митинг, а «на чём застрял».
    • Работа над первой задачей продолжается, ревью PR — в течение рабочего дня, не «когда будет время».

    Дни 4-5 — первый мердж и вторая задача

    • Первый PR должен быть смёрджен до конца недели. Если не успевает — это сигнал для HR BP проверить, не завышена ли сложность задачи или не занят ли наставник другими вещами больше, чем договаривались.
    • Выдаётся вторая задача, чуть сложнее — с зависимостью от другого модуля или человека из команды, чтобы джун начал коммуницировать за пределами наставника.
    • Короткая (20 минут) встреча с CTO или тимлидом — не церемониальная, а с вопросом «что было непонятно в коде за эти дни» и реальным ответом на него.
    • HR BP собирает обратную связь у наставника: успевает ли, не боится ли задавать вопросы, есть ли трение с командой.

    Неделя 2

    Дни 6-8 — снижение сопровождения

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

    Дни 9-10 — самостоятельность и обратная связь

    • Финальная встреча с наставником не в формате «как дела», а с конкретным разбором: 2-3 примера кода из задач джуна за две недели — что было хорошо, что переделать.
    • Встреча джуна с HR BP: собрать его собственную оценку — что было понятно, что провисло, хватило ли доступов и контекста. Это должно менять план для следующего найма, а не оставаться формальностью.
    • К концу дня 10 у джуна должно быть: минимум 2 смёрженных PR, понимание, к кому идти по каждому из 3-4 основных модулей продукта, и явная договорённость с наставником о формате поддержки на следующий месяц (не «отвалится сама собой», а конкретно — например, раз в неделю 30 минут до конца испытательного срока).

    Что намеренно не входит в план

    Курсы, сертификации, «welcome-пак» с мерчем, длинные онбординг-презентации о миссии компании — при таком бюджете и размере команды это шум. Обучение здесь — это код, ревью и доступность наставника, а не контент.

    Разница между оценками судей: недоступна: учтена оценка только одного судьи.

    Комментарии судей

    • ChatGPT Sol: 8.5 — План чётко разбит по дням, содержит измеримые результаты, конкретные форматы встреч, критерии первых задач и порядок доступа к документации. Снижает оценку реалистичности обязательный PR в прод уже на первой неделе: это зависит от продукта, сложности окружения и правил релиза. Для полноты не хватает детального чек-листа настройки рабочего места, полноценного знакомства с командой и проверки доступов в первый день; тезис о наставнике как единственном источнике знаний также создаёт риск зависимости от одного человека.
      • Структура: 9 из 10
      • Конкретность: 9 из 10
      • Реалистичность: 8 из 10
      • Полнота: 8 из 10
13. ГигаОтвет введён вручнуюСредняя оценка: 8.5

    День 0: До выхода (ответственный — HR BP)

    База: Создание учетной записи в Google Workspace, добавление во все обязательные каналы Slack (#dev-team, #random, #announcements), создание корпоративной почты. Документы: Отправка ссылки на общую базу знаний (Notion/Confluence) и чек-лист первого дня. Никаких PDF-инструкций почтой. Команда: Написать в #dev-team пост-знакомство с фото новичка, его стеком и ссылкой на гитхаб. Попросить команду отреагировать эмодзи, чтобы снизить барьер первого сообщения. Железо: Заказ ноутбука за неделю до выхода. Если сотрудник работает удаленно — согласование адреса доставки.

    Неделя 1: Инфраструктура и контекст (цель — работающая среда и понимание продукта)

    День 1: Онбординг без простоя

    9:30 Встреча-знакомство (HR + Team Lead): Не экскурсия по офису. Обсуждение целей на испытательный срок, ритуалов команды (дейли, демо, ретро) и каналов коммуникации. Кто за что отвечает. 10:30 Настройка рабочего места (Наставник): Развертывание проекта из единого скрипта (./scripts/bootstrap-dev.sh). В малом стартапе кастомные настройки окружения недопустимы. Доступы к GitHub/GitLab, CI/CD (GitHub Actions), тестовому стенду. Подключение к системе мониторинга ошибок (Sentry). 12:00 Первый коммит: Исправление опечатки или неработающей ссылки в документации локального README.md. Цель — пройти полный цикл от создания ветки до успешного мержа в main. 15:00 Демо архитектуры (Tech Lead / СТО): 30 минут экрана. Как данные ходят от фронтенда к базе через бэкенд. Где лежат самые старые костыли, о которых нужно знать. Конец дня: Задача «пройтись по коду модуля X» без дедлайна. Оставить 3 комментария с вопросами прямо в IDE (через Code Owners или Reviewpad).

    День 2–3: Погружение в процессы

    Дейли: Новичок присутствует, но молчит, слушая, как команда формулирует проблемы, а не задачи. Доступ к знаниям: Ссылка на Notion-раздел: архитектура, API-контракты, регламент деплоя, схема БД. Папка в Drive: записи последних трех командных демо (видео по 10–15 минут). Чат-бот в Slack для запроса доступов (чтобы не бегать по админам). Задача: Ревью старого пул-реквеста месячной давности. Найти одно узкое место (например, отсутствие индексов в запросе) и описать его в комментарии.

    День 4–5: Первое касание продакшена

    Встреча с QA/DevOps (30 мин): Показывают, как читать логи ELK/Kibana и трассировки Jaeger. Как воспроизвести ошибку с тестового стенда у себя локально. Задача: Взять задачу типа P3-P4 из бэклога (исправление бага верстки, обновление зависимости, написание unit-теста для существующей функции). Срок — до конца недели. Парное программирование (2 часа): Наставник пишет сложную бизнес-логику, джун управляет мышкой и задает вопросы «почему так, а не иначе». Пятница, 16:00 Синхронизация с наставником: Без галстуков и статусов. Что было самым непонятным? Где документация соврала реальности?

    Неделя 2: Автономность и первая ценность (цель — самостоятельный таск-комлит)

    День 8–9: Первая самостоятельная фича

    Выбор задачи: Небольшая изолированная функциональность из текущего спринта (например, добавить поле в профиль пользователя и вывести его на экран; написать эндпоинт для экспорта данных в CSV). Оценка: Джун сам декомпозирует задачу на подзадачи вместе с наставником. Оценивают в сторипоинтах на троих (джун, наставник, тимлид) для калибровки. Процесс: Полный цикл разработки силами джуна. Наставник подключается только если тот заблокирован дольше 45 минут.

    День 10: Кросс-функциональное знакомство

    Product Manager (30 мин): Откуда берутся задачи в Jira. Почему эта фича важнее той. Понятие MVP. Поддержка/CSM (30 мин): Прослушивание одного звонка клиента в Gong или чтение пяти тикетов из Intercom. Понимание реальных болей пользователей.

    День 11–12: Работа над ошибками и рефакторинг

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

    День 13–14: Выход из гнезда

    Подготовка к Demo Friday: Джун готовит двухминутную демонстрацию своей готовой фичи. Репетиция перед наставником. Снижение частоты встреч: Переход с ежедневного парного программирования на одну встречу-синк в конце дня (15 минут). Финальная встреча (HR BP + Тимлид + Джун): Сбор обратной связи о первой неделе. Корректировка плана развития на следующие 90 дней. Назначение бадди (приятеля) из смежной команды для неформальных вопросов. Итоговое ревью репозитория: Ментор проверяет первые три закрытых PR джуна, дает развернутую обратную связь по стилю кода и архитектурным решениям.

    Инструменты и бюджет (нулевой)

    Вместо платных курсов: Оформленная подписка на месяц видео-платформы (Udemy/Coursera) передается внутри компании по эстафете. Сегодня она у джуна, через месяц — у следующего. Вместо дорогого онбординга: Скрипты автоматизации настраиваются один раз девопсом. Документация пишется всеми членами команды в формате «если наступил на грабли — сразу запиши в Confluence». Любой процесс, вызвавший вопрос дважды, документируется. Социализация: Вместо платных корпоративных обедов — совместный поход за кофе в соседнюю кофейню за счет сотрудника (стартап-культура подразумевает разделение бытовых расходов на старте).

    Разница между оценками судей: 2.0

    Комментарии судей

    • Claude Opus: 9.5 — Структура образцовая: День 0 → Неделя 1 по дням → Неделя 2 по дням, везде подзаголовки, ответственные, тайминг, цели этапов. Конкретность на высоте — реальные инструменты (Slack-каналы, Sentry, bootstrap-скрипт, ELK/Kibana, Jaeger), понятные задачи (первый коммит на опечатке, ревью старого PR, поиск отсутствующих индексов, P3-P4 из бэклога), декомпозиция и оценка в story points. Клише реально избегаются. Полнота: все требуемые блоки закрыты (знакомство с командой, настройка места, первые задачи, встречи с наставником, доступ к докам) плюс бюджетный раздел и план на 90 дней. Реалистичность чуть проседает: для стартапа до 50 человек стек ELK + Jaeger + Gong + Intercom одновременно выглядит перегруженным и противоречит тезису о минимальном бюджете; правило «наставник подключается только после 45 минут блока» для джуна сомнительно; кофе за счёт сотрудника как элемент онбординга спорно с точки зрения HR. В остальном план приземлённый и рабочий.
      • Структура: 10 из 10
      • Конкретность: 10 из 10
      • Реалистичность: 8 из 10
      • Полнота: 10 из 10
    • ChatGPT Sol: 7.5 — План детальный, хорошо разбит по этапам, содержит ответственных, сроки, встречи, доступы и измеримые результаты. Реалистичность снижена из-за перегруза junior-разработчика сложными задачами и инструментами, путаницы в нумерации дней, несуществующей связи между Code Owners/Reviewpad и комментариями в IDE, а также противоречий: на второй день джун не пишет код, хотя позже должен его рефакторить; финальная встреча обсуждает первую неделю после завершения второй. Требование молчать на дейли противоречит открытости, правило помощи только после 45 минут может затягивать блокеры, а передача общей подписки и кофе за счет сотрудника выглядят сомнительно и могут нарушать правила сервиса или ухудшать адаптацию.
      • Структура: 8 из 10
      • Конкретность: 9 из 10
      • Реалистичность: 5 из 10
      • Полнота: 8 из 10
14. Claude HaikuОтвет получен через APIСредняя оценка: 8.3

    План адаптации junior-разработчика (2 недели)

    День 1 (понедельник)

    Утро

    • 9:00 — встреча с HR/руководителем: пароли, доступы, железо
    • 9:30 — техсетап вместе с наставником: окружение, инструменты, запуск проекта локально
    • 11:00 — тур по офису, знакомство с основными сотрудниками (указать конкретных людей, не абстрактную команду)

    День (с наставником)

    • Обзор codebase за 1–1.5 часа: архитектура проекта, главные папки, как запускается тестирование
    • Чтение README и внутренней документации (не более 2 часов — количество ограничено намеренно)
    • Первая микрозадача: что-то совсем простое (добавить логирование, поправить комментарий в коде, обновить версию библиотеки) — задача на 30–60 минут, чтобы запустить локально и отправить PR

    Вечер

    • 1:1 с наставником: что непонятно, что нужно доразобрать завтра

    ---

    Неделя 1 (вт–пт)

    Вторник–среда: контекст проекта

    • Вт утро: 30-минутный звонок с product/CEO (что бизнес пытается решить, зачем этот продукт)
    • Вт–ср: 2–3 микрозадачи в одной части кода (например, все в модуле авторизации или API слое) — простые, но связанные, чтобы выучить один corner of the system
    • Ср: код-ревью от наставника на всех трёх PR, с конкретным feedback (не "сделай красивее", а "используй листcomprehenion вместо for, потому что в проекте такой стиль")
    • Ср вечер: встреча с разработчиком, который ownerит ту часть кода, которую junior трогал (10–15 минут вопросов-ответов)

    Четверг: расширение зоны комфорта

    • Первая задача среднего размера: что-то с парой часов работы, но всё ещё в знакомом модуле
    • Обзор инструментов: как поднять локальную БД, как прочитать логи, как использовать дебаггер
    • Встреча с человеком из другого отдела (бэк знакомится с фронтом или наоборот) — 30 минут, понять что они делают

    Пятница: синхронизация

    • Ревью всех PR за неделю
    • Собор разработчиков (если он есть) — слушает, не обязательно участвует
    • 1:1 с наставником: что клеится, что застрял
    • Лист вопросов, которые остались — записать для следующей недели

    ---

    Неделя 2 (пн–пт)

    Понедельник: первая "настоящая" задача

    • Задача на 1–2 дня: что-то реальное из бэклога, но не critical path
    • Задача должна затрагивать несколько файлов, но в известной части системы
    • Наставник доступен, но не всегда подсказывает — encourage self-sufficiency (читать код, гуглить, писать вопросы в slack)

    Вторник–среда: углубление

    • Продолжение задачи или новая задача такого же размера
    • Первый опыт с тем, что сломалось: баг в коде или в локальном окружении junior-а
    • Встреча с тестировщиком/QA (если есть) — как работает процесс тестирования, какие edge-case-ы часто пропускают

    Четверг: feedback loop

    • Ревью от наставника: качество кода, скорость, стиль
    • Обсуждение, что нужно подкачать (если видна проблема)
    • Презентация что-то одной из задач перед хотя бы парой человек (5 минут, неформально)

    Пятница: итоги и roadmap

    • Встреча с наставником: что выучил, где застрял, что нужно ещё
    • Небольшая ретро в письменном виде (гугл-форма или доклад): "Что помогло? Что надо улучшить в адаптации?"
    • Если всё идёт хорошо — первая "bonus" задача на выбор junior-a (что интересно, того и делает)

    ---

    Сквозные элементы

    Наставничество

    • Встречи: ежедневно в первую неделю (15–30 минут, обычно вечер), потом через день на второй
    • Slack-канал адаптации: один чат, где junior может задавать вопросы без стеснения, архивируются ответы
    • Что не делать: наставник не должен сидеть с junior-ом весь день и диктовать решение; задача — помочь найти ответ самому

    Документация

    • Внутренняя вики / Notion / GitHub Pages: architecture decisions, как запустить локально, как прочитать логи
    • Если документации нет — не изобретать за неделю; junior пишет заметки для себя, наставник уточняет
    • К концу недели 2: junior добавляет в документацию одну-две заметки про то, что было непонятно (этот feedback помогает следующему)

    Рабочее окружение

    • Доступы: GitHub, Slack, internal tools, staging, БД (readonly или ограниченные права)
    • IDE / editor: установить, настроить линтер, дебаггер, горячие клавиши
    • Локальное окружение: docker-compose / скрипт на bash / whatever, но должно "просто работать" из коробки

    Первые таски

    • Репозиторий с бэклогом должен иметь label типа good-first-issue или junior-friendly
    • Таски: конкретные, с AC, с контекстом (зачем это нужно, как это тестировать)
    • Не надо начинать с "причистить код" или "добавить комментарии" — это деморализует

    Feedback

    • Неформальное: ежедневно "как дела?", слышать проблемы рано
    • После недели 1 и недели 2: письменный feedback от наставника (2–3 пункта: что получается, на что обратить внимание)
    • От junior-a про адаптацию: что помогло запуститься быстро, что было трудно

    ---

    Метрика успеха на конец недели 2

    • Junior может самостоятельно запустить проект и написать простой PR (без помощи наставника)
    • Понимает общую архитектуру, может ответить "где лежит логика авторизации"
    • Знает, кому писать с вопросами в разных ситуациях
    • Выглядит расслабленнее чем в день 1

    Если что-то из этого не готово — адаптация продолжается. Это нормально.

    Разница между оценками судей: недоступна: учтена оценка только одного судьи.

    Комментарии судей

    • ChatGPT Sol: 8.25 — План хорошо разбит по дням и неделям, охватывает все обязательные элементы, содержит расписание, длительность встреч, примеры задач и критерии результата. Реалистичность снижают перегруженный первый день, три PR к среде, обязательный созвон с CEO и искусственное ожидание поломки. Есть противоречие: сначала предлагается правка комментария как микрозадача, а ниже такие задачи названы демотивирующими. Часть формулировок требует конкретизации под компанию: ответственные за доступы, перечень обязательной документации, критерии готовности задач и план действий при блокерах.
      • Структура: 9 из 10
      • Конкретность: 8 из 10
      • Реалистичность: 7 из 10
      • Полнота: 9 из 10
15. YandexGPTОтвет получен через APIСредняя оценка: 7.0

    План адаптации нового junior-разработчика (2 недели)

    День 1–2: знакомство с компанией и настройка рабочего места

    • встреча с HR-менеджером: обзор структуры компании, корпоративной культуры, правил работы, системы коммуникации (используемые мессенджеры, системы управления задачами и проектами);
    • знакомство с командой: общий созвон или встреча в офисе с ключевыми сотрудниками, представление нового сотрудника, краткий рассказ о ролях и обязанностях коллег;
    • настройка рабочего места: помощь в установке необходимого ПО, настройка доступа к корпоративным ресурсам (внутренний портал, системы контроля версий, базы данных и т. д.);
    • знакомство с наставником: личная встреча с наставником, обсуждение плана адаптации, определение ключевых задач на ближайшие две недели, установление частоты встреч.

    День 3–4: погружение в документацию и процессы

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

    День 5–6: первые задачи и практика

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

    День 7: промежуточный обзор и планирование

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

    День 8–11: углубление в проекты и процессы

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

    День 12–13: работа над реальным проектом

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

    День 14: итоговая встреча и обратная связь

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

    Разница между оценками судей: 1.0

    Комментарии судей

    • Claude Opus: 6.5 — Структура чёткая: разбивка по дням с подзаголовками и списками, логичная прогрессия от знакомства к реальному проекту. Полнота хорошая — все требуемые блоки (команда, рабочее место, первые задачи, наставник, документация) на месте. Главный провал — конкретность: задание прямо требовало избегать общих фраз, а ответ построен именно на них ('настройка доступа к корпоративным ресурсам', 'получение первых небольших задач', 'обзор структуры компании'). Ни одного конкретного инструмента (Slack/Jira/Git), примера задачи, метрики или критерия оценки. Специфика стартапа (до 50 человек, минимальный бюджет, культура открытости) не отражена — план обезличенный, подойдёт любой компании. Реалистичность нормальная: сроки и нагрузка для джуна адекватны, упор на наставничество выдержан.
      • Структура: 8 из 10
      • Конкретность: 3 из 10
      • Реалистичность: 7 из 10
      • Полнота: 8 из 10
    • ChatGPT Sol: 7.5 — Ответ логично разбит по этапам и включает все обязательные элементы. Конкретности не хватает: не названы примеры первых задач, ожидаемые результаты, критерии готовности рабочего места и итоговые показатели адаптации. Нумерация 1–14 не учитывает выходные, а частота встреч с наставником сначала остается неопределенной. Для стартапа план в целом выполним, но нагрузка на наставника и формат контроля стоило зафиксировать точнее.
      • Структура: 9 из 10
      • Конкретность: 6 из 10
      • Реалистичность: 7 из 10
      • Полнота: 8 из 10