Первая работа и первые 90 дней: онбординг, ожидания, типичные ошибки

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

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

Про то, как вы сюда попали, — в статьях про собеседования и переговоры об оффере. Про то, куда двигаться дальше, — в «Как расти». Здесь — про промежуток между этими двумя точками, который почему-то всегда пропускают.

Что вообще такое онбординг с точки зрения компании

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

Из этого следует несколько вещей, неочевидных изнутри первого рабочего дня:

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

Метрика, которую в разных формах считают почти везде, называется time to first meaningful contribution — время до первого содержательного вклада. Где-то это формализовано (первый PR в проде за N дней), где-то живёт только в голове тимлида, но она есть всегда.

Обратите внимание на оранжевую кривую. Провал уверенности на третьей–шестой неделе — самая массовая часть опыта новичка и самая неожиданная для него самого. Механика простая: в первую неделю вы видите только верхушку системы и она кажется понятной; к третьей неделе вы обнаруживаете легаси-модуль, шесть микросервисов, о которых не знали, и бизнес-правила, которым десять лет. Объём непонятого растёт быстрее, чем объём понятого. Это арифметика, а не признак профнепригодности.

До первого дня: что можно сделать заранее

Не героические подвиги, а полчаса работы, которые снимут половину трения.

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

Спросите, что почитать заранее — и не переусердствуйте. Уместный вопрос будущему тимлиду: «Есть ли что-то, что стоит посмотреть до старта, чтобы быстрее включиться?» Если ответят «ничего, всё покажем» — поверьте и отдохните. Если пришлют ссылки — пролистайте, не пытаясь выучить. Учить продуктовую доменную область без доступа к системе бессмысленно: термины не за что зацепить.

Не пытайтесь «подтянуть технологию» за выходные. Если вас взяли, зная ваш уровень по стеку, дыры будут закрываться в работе. Марафон по видеокурсу перед выходом даёт иллюзию подготовки и реальную усталость на старте.

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

Первая неделя: цель — не код, а инфраструктура вашей работоспособности

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

Три детали, которые стоят отдельного упоминания.

Правка README — идеальный первый PR. Инструкция по запуску устаревает почти везде: её пишут один раз, а окружение живёт дальше. Вы — единственный человек в команде, который проходит её с нуля и видит все дыры. Записывайте каждый недостающий шаг и оформляйте правкой. Такой PR полезен, безопасен, не требует знания домена и заодно прогоняет вас через весь процесс: ветка, коммит, ревью, CI, мердж. Как этот процесс устроен подробно — в «Разработка: ветки, код-ревью, стандарты и DoD».

Первая задача должна быть тривиальной по содержанию и полной по процессу. Смысл не в том, чтобы что-то починить, а в том, чтобы пройти путь от тикета до прода целиком и найти на нём все места, где вы застреваете. Если вам сразу дали большую задачу «чтобы прочувствовал», это не признак доверия — это чаще признак того, что онбординг никто не продумал.

Заведите рабочий журнал в первый же день. Один файл, куда падает всё: непонятные аббревиатуры, имена людей и за что они отвечают, команды, которые пришлось гуглить, вопросы, которые пока стыдно задать. Через месяц он превратится в вашу личную вики, а через полгода — в основу для документа о достижениях, который понадобится на performance review. Джулия Эванс называет такой документ brag document и подробно расписывает формат: https://jvns.ca/blog/brag-documents/.

Жизненный цикл вашей первой задачи — включая застревание

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

Ключевое состояние — «Застрял». Именно там новички теряют дни, и именно оттуда вытекает главная претензия тимлидов к джунам: не то, что застрял, а то, что застрял молча.

Как спрашивать: главный навык первых месяцев

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

Рабочее правило простое: таймбокс. Договоритесь с собой (а лучше вслух с тимлидом) на конкретное число — обычно 30–60 минут для джуна. Застряли — ставите таймер. Не решили за таймбокс — идёте спрашивать, и это не «сдался», а выполнение договорённости. Для многих это единственный способ обойти собственный стыд: решение уже принято заранее.

Формат вопроса решает почти всё. Плохой вопрос: «Привет, есть минутка?» — и молчание, пока человек не ответит. Это ping-пинг, из-за которого коммуникация растягивается на часы; про этот антипаттерн есть целый сайт https://nohello.net/. Хороший вопрос содержит четыре вещи и умещается в одно сообщение:

Делаю задачу PAY-1421 — надо добавить поле в ответ /api/orders.
Хочу понять, где формируется DTO: нашёл OrderResponse, но поля туда
попадают откуда-то из маппера, который я не вижу в этом модуле.
Пробовал: grep по имени поля, git log по OrderResponse, поиск в вики.
Вопрос: есть ли отдельный слой маппинга, и где он лежит?

Такой вопрос отвечается за минуту, показывает, что вы работали сами, и заодно остаётся в поиске для следующего новичка. Полезные тексты на эту тему: «Don’t ask to ask» https://dontasktoask.com/, формулировка XY-проблемы https://xyproblem.info/ и заметка Джулии Эванс про хорошие вопросы https://jvns.ca/blog/good-questions/.

Два уточнения из практики:

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

Кто вокруг вас и от кого чего ждать

Роли подробно разобраны в «Кто есть кто в команде» — здесь только про то, как они выглядят с точки зрения новичка в первые недели.

Главное, что стоит вынести: у вопросов есть адресаты. «Почему код такой» — к автору кода (ищется через git blame). «Как система должна себя вести» — к продакту или аналитику, и это не стыдный вопрос, а профилактика недели работы не в ту сторону (см. «Требования и аналитика»). «Что считается готовым» — к тимлиду и в Definition of Done. «Где тестовые данные» — к QA.

Если в компании назначили бадди — человека, который отвечает за ваши бытовые вопросы, — пользуйтесь этим активно. Это его официальная задача, часто оплачиваемая или учитываемая в его же оценке. Не «отвлекаете»: он для этого и назначен.

План на 30 / 60 / 90 дней

Формат «30/60/90» пришёл из менеджмента — его популяризировал Майкл Уоткинс в книге «The First 90 Days» (https://hbr.org/2006/01/the-first-90-days). Для разработчика он адаптируется без потерь: разница лишь в том, что вместо «выстроить отношения с заинтересованными сторонами» у вас «понять кодовую базу».

Раскроем по фазам — что считается нормой, а что должно насторожить.

Дни 1–30: понять, как здесь всё устроено

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

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

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

• Попросить у тимлида явные критерии успешного испытательного срока. Формулировка: «Чтобы мне через три месяца было понятно, что всё в порядке, — как для вас выглядит успешно пройденный испытательный? На что смотреть мне?» Вопрос абсолютно уместный, и хороший руководитель ответит с облегчением.
• Договориться о регулярных 1:1 — раз в неделю или хотя бы раз в две. Если тимлид не инициирует, просить самому.
• Познакомиться со смежниками: QA, аналитик, DevOps, поддержка. По 20 минут на человека, один вопрос — «чем ты занимаешься и когда мне стоит к тебе приходить».
• Прочитать не всю кодовую базу, а один сквозной сценарий целиком: от HTTP-запроса до записи в базу и обратно. Один вертикальный срез даёт больше, чем месяц чтения вширь.

Дни 31–60: начать закрывать задачи самостоятельно

Норма: задачи среднего размера, вы сами оцениваете их (плохо, но сами), сами декомпозируете, комментариев на ревью меньше и они больше по сути, чем по стилю. Вы начинаете замечать, что в системе устроено криво, и понимаете, почему так вышло.

Что должно насторожить: вы всё ещё на микрозадачах и никто не объясняет почему; на ревью повторяются одни и те же замечания (значит, вы их не усваиваете — стоит завести чеклист перед открытием PR); вы регулярно уходите в задачу на неделю и молча пропадаете.

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

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

Дни 61–90: подтвердить, что вам можно доверять

Норма: вы ведёте фичу от обсуждения требований до релиза; вас зовут обсуждать решения, а не только исполнять; вы знаете, где посмотреть, если что-то сломалось, и понимаете процедуру инцидента (см. «Релиз и эксплуатация»).

Что должно насторожить: вас всё ещё не подключают ни к каким обсуждениям; никакой обратной связи вы так и не получили; на прямой вопрос «как у меня дела» отвечают уклончиво. Последнее — самый громкий сигнал: плохие новости на испытательном сроке почти всегда доходят до человека последними.

Что делать активно: за две-три недели до конца срока прямо спросить о статусе. «Испытательный заканчивается 10 апреля. Есть ли что-то, что стоит подтянуть за оставшееся время?» Если проблемы есть, у вас появляется три недели на исправление вместо неприятного сюрприза. Если проблем нет — вы это услышите и перестанете тратить силы на тревогу.

Испытательный срок: как это устроено формально

Полезно понимать юридическую рамку, а не только неформальную. В России она задана Трудовым кодексом (главы 11 и 13, статьи 70 и 71 — https://www.consultant.ru/document/cons_doc_LAW_34683/):

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

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

Отдельно: в разных юрисдикциях правила разные — в США преобладает at-will employment, где формального испытательного срока может не быть вовсе, но и уволить можно почти в любой момент. Если оффер зарубежный, читайте местное трудовое право, а не переносите привычную рамку.

Типичные ошибки: разбор

Ниже — то, что повторяется из раза в раз. Не «плохие люди», а предсказуемые ловушки.

1. Тонуть молча. Самая дорогая ошибка. Три дня «я почти разобрался» — это три потерянных дня команды, а не ваша личная героическая борьба. Лечится таймбоксом и правилом: если оценка задачи выросла вдвое, об этом узнают сегодня, а не в конце спринта.

2. Огромный первый PR. «Сделаю сразу всё и покажу». В итоге 40 файлов, ревьюер смотрит на это с ужасом, апрув идёт неделю, и половина замечаний требует переделки архитектуры. Мелкие PR ревьюятся быстрее и качественнее — про зависимость качества ревью от размера диффа подробно в статье про разработку.

3. «Тут всё написано плохо, давайте перепишем». Почти всегда неверно по сути и всегда неверно по таймингу. Код, который выглядит бессмысленным, часто хранит в себе десяток краевых случаев, багов клиента и требований регулятора. Правило Чéстертона про забор: прежде чем убирать забор посреди поля, выясните, зачем его поставили. Записывайте замечания в личный список — через два месяца вы вернётесь к нему, половину вычеркнете как «теперь понятно почему», а с оставшейся половиной пойдёте к тимлиду с аргументами. Тогда это будет разговор о техническом долге, а не жалоба новичка.

4. Компенсировать неуверенность переработками. Работать до полуночи в первый месяц — способ выгореть к третьему и при этом не выглядеть продуктивнее: скорость новичка ограничена не количеством часов, а объёмом непонятого контекста. Регулярные переработки в начале ещё и задают ожидания, которые потом придётся ломать.

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

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

7. Молчать на дейли и встречах. «Мне нечего сказать, я же ничего не сделал». Ровно наоборот: «вчера разбирался с X, застрял на Y, сегодня попробую Z» — это идеальный статус новичка, и он часто мгновенно приносит помощь от того, кто Y уже проходил.

8. Прятать ошибку. Уронили тестовый стенд, снесли данные, смержили не туда. Инстинкт — замять. Правильное действие — сказать сразу и громко. Стоимость инцидента растёт со временем нелинейно, а репутационно «сказал сам через 5 минут» несопоставимо лучше, чем «нашли через три часа». В зрелых командах культура постмортемов без поиска виноватых прямо это поощряет — см. подход Google SRE к blameless postmortem (https://sre.google/sre-book/postmortem-culture/).

9. Принимать замечания на ревью на свой счёт. Ревью — про код, а не про вас. Полезная привычка: на каждое непонятное замечание задавать уточняющий вопрос, а не молча править. Во-первых, так вы учитесь. Во-вторых, иногда прав окажетесь вы.

10. Ждать, что задачи принесут. Первые недели — да, принесут. Дальше человек, который сам приходит с «я закончил, что взять дальше?» или «заметил вот это, можно я починю?», растёт заметно быстрее.

11. Сидеть в наушниках три месяца и ни с кем не разговаривать. Технически можно. Но карьера в команде — это ещё и то, доверяют ли вам люди. Доверие строится на маленьких взаимодействиях, а не на объёме коммитов.

12. Сравнивать себя с сеньором за соседним столом. Он в этом коде третий год. Сравнивайте себя с собой две недели назад — это единственное осмысленное сравнение на этом этапе. Подробнее про то, чем на самом деле отличаются грейды, — в отдельной статье.

Ошибки другой стороны: когда виноват не новичок

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

• Нет ответственного. Вы вышли, вас посадили и забыли. Никто не назначен вашим бадди, тимлид в отпуске, задач нет. Это не «проверка на самостоятельность», это отсутствие процесса.
• Документации нет, а вопросы раздражают. Комбинация убийственная: узнать самому негде, спросить нельзя. Если на нормально сформулированный вопрос стабильно отвечают вздохом, проблема не в вас.
• «Разберёшься по ходу» вместо первой задачи. Новичку в первый месяц выдают критичную задачу без контекста, потом удивляются результату.
• Никакой обратной связи до самого конца испытательного. Затем внезапное «нам не подошло». Это управленческая ошибка в чистом виде: обратная связь, данная в последний день, ничего не могла изменить.
• Постоянные пожары. Команда живёт в режиме инцидента, никто не может выделить час на объяснения. Вы будете барахтаться не потому, что слабы, а потому что система не имеет резерва.

Что с этим делать. Сначала — компенсировать самому: писать документацию по ходу (вы всё равно её пишете в свой журнал — просто выкладывайте в вики), формулировать вопросы так, чтобы на них было дёшево ответить, самому предлагать себе задачи из бэклога, самому звать тимлида на 1:1. Такое поведение почти всегда замечают и оценивают.

Но у этого есть предел. Если через шесть-восемь недель у вас всё ещё нет доступов, нет задач, нет ни одного разговора о вашем прогрессе — это данные о компании, а не о вас. Уйти на испытательном сроке — легальный и нормальный ход, и в этот период он делается быстрее и с меньшими издержками, чем позже. Строчка «три месяца» в резюме объясняется одним предложением на следующем собеседовании; год выгорания объяснить сложнее.

Онбординг в энтерпрайзе, стартапе и аутсорсе

Одинаковых первых 90 дней не бывает — тип компании меняет почти всё. Подробно контексты разобраны в статьях про типы проектов, энтерпрайз и стартап, здесь — только про вход.

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

Отдельно про удалёнку

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

Что помогает:

• Просить видео-созвоны на 15 минут вместо переписки там, где переписка идёт третий круг. Один шеринг экрана экономит два часа текста.
• Писать статусы избыточно. На удалёнке о вас знают ровно столько, сколько вы написали. Молчащий новичок выглядит как исчезнувший новичок.
• Явно спрашивать про «неписаные» вещи: когда принято быть онлайн, насколько быстро ожидается ответ в чате, что срочно, а что нет. В офисе это считывается за неделю; на удалёнке об этом надо спросить вслух.
• Договориться о регулярном созвоне с бадди — даже пустом, «просто поболтать про задачи» раз в два дня в первые недели. Это компенсирует отсутствующую фоновую коммуникацию.

Про то, как выстраивать коммуникацию в распределённой команде системно, есть отдельный материал в треке project-management: «Команда и коммуникация».

Про деньги в первые 90 дней

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

Механика вознаграждения — оклад, бонусы, грейды, вилки, индексация — разобрана в «Зарплата и своя цена», а подготовка к разговору — в «Переговоры об оффере». Единственное, что действительно стоит делать в первые 90 дней с точки зрения будущих денег, — копить фактуру: что вы сделали, какой был эффект, кто это подтвердит. Через год эта фактура будет стоить дороже любых аргументов «я хорошо работал».

Как понять, что всё идёт нормально

Формальных критериев нет, но есть набор наблюдаемых признаков. Если к концу третьего месяца верно большинство пунктов — вы в норме:

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

Чего в этом списке нет: «пишу код так же быстро, как сеньоры», «знаю всю кодовую базу», «не задаю вопросов». Ни одно из этого не является ожиданием к трём месяцам ни в одной здоровой команде.

Как это выглядит на горизонте года

Три месяца — не финиш, а первая контрольная точка. Дальше траектория примерно такая:

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

Мини-итог

• Онбординг — это инвестиция компании, а не испытание на прочность. Отрицательный вклад в первые недели заложен в план.
• Оценивают траекторию, а не текущий уровень: важно, что вы понимаете больше, чем две недели назад.
• Цель первой недели — работоспособное окружение и один проведённый через весь процесс PR, а не большая задача.
• Провал уверенности на 3–6 неделе — нормальная часть кривой. Он проходит.
• Главный навык — задавать вопросы: таймбокс 30–60 минут, полный контекст в первом сообщении, публичный канал, записанные ответы.
• Самая дорогая ошибка — застревать молча. Вторая по дороговизне — молчать про свою ошибку.
• Явно спросите критерии успешного испытательного срока в первые недели и статус за три недели до конца — не ждите сюрпризов.
• Испытательный срок двусторонний: закон даёт вам право уйти с предупреждением за три дня, и иногда это правильное решение.
• Отсутствие доступов, задач и обратной связи через два месяца — данные о компании, а не о вас.
• Ведите рабочий журнал с первого дня: он станет и вашей вики, и основой для разговора о грейде и деньгах через год.

Что почитать

• Michael D. Watkins. «The First 90 Days» — https://hbr.org/2006/01/the-first-90-days
• Camille Fournier. «The Manager’s Path» — взгляд на онбординг и менторство со стороны руководителя
• Julia Evans. Brag documents — https://jvns.ca/blog/brag-documents/; хорошие вопросы — https://jvns.ca/blog/good-questions/
• Google SRE Book, глава про культуру постмортемов — https://sre.google/sre-book/postmortem-culture/
• Google SRE Book, «Accelerating SREs to On-Call and Beyond» — про то, как вводят новичка в дежурства: https://sre.google/sre-book/accelerating-sre-on-call/
• «Don’t ask to ask» — https://dontasktoask.com/; «No hello» — https://nohello.net/; XY problem — https://xyproblem.info/
• Трудовой кодекс РФ, статьи 70 и 71 об испытании при приёме на работу — https://www.consultant.ru/document/cons_doc_LAW_34683/
• Will Larson, lethain.com — заметки о первых месяцах в новой роли и о том, как читать незнакомую организацию

Что дальше

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

Карьерные треки: эксперт, менеджер, архитектор, фриланс, свой продукт