Первые 90 дней на новой работе разработчика: как пройти испытательный

Короткий ответ

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

Неделя 1: окружение и знакомство

• Поднимите проект локально. Пройдите инструкцию по запуску, а где она устарела — поправьте README. Это полезный первый вклад.
• Получите доступы: репозиторий, трекер задач, CI, логи, мониторинг, чаты команды.
• Познакомьтесь с людьми. Узнайте, кто за что отвечает и к кому идти с вопросами по бэкенду, инфраструктуре, продукту.
• Первая встреча с руководителем. Спросите прямо: что должно получиться у меня к концу испытательного и по каким критериям это будут оценивать?

Запишите ответы и через пару дней отправьте руководителю короткое резюме — так вы оба зафиксируете одинаковое понимание.

Недели 2–4: домен и первые задачи

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

Как работать с ревью:

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

Вопросы: когда спрашивать

Новички чаще ошибаются в одну из двух сторон: молчат днями или спрашивают каждую мелочь. Рабочее правило:

1. Попробуйте разобраться сами — код, документация, история задач и коммитов.
2. Если за разумное время (например, час-два) не продвинулись — спрашивайте.
3. Формулируйте вопрос с контекстом: что делаете, что уже проверили, где именно застряли.

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

Недели 5–8: стабильность и отношения

• Закрывайте задачи предсказуемо. Если оценка срывается, сообщайте об этом заранее, а не в день дедлайна.
• Участвуйте в ревью чужого кода. Даже вопросы «почему здесь так?» помогают вам учиться и вовлекают в команду.
• Выстраивайте отношения. Поблагодарите тех, кто помог; предложите помощь в том, что уже знаете.
• Промежуточная встреча с руководителем. Спросите: что получается хорошо, что стоит улучшить, совпадает ли мой прогресс с ожиданиями?

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

Недели 9–12: заметный результат

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

Чек-лист к концу испытательного

Частые ошибки

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