Коротко
На новую работу я выходил за зарплатой, а не за правом снова стать бесплатным студентом. Разобраться в чужом проекте — тоже работа. Я сменил 23 компании по ТК РФ и не приходил в каждую с готовым знанием её инфраструктуры. Учился по ходу, осваивал следующий уровень и получал за это деньги. Испытательный срок для меня — не конкурс на самого удобного сотрудника: компания смотрит на тебя, ты смотришь на компанию.
Оффер получил. Теперь можно разбираться
Собеседование и работа — две разные вещи. На собесе ты объясняешь, как устроен Kubernetes. После выхода выясняешь, почему именно этот кластер живёт так, кто его собирал и почему инструкция заканчивается на самом интересном месте. Эту часть невозможно было выучить заранее на курсе.
Мой путь от Help Desk до Senior DevOps не выглядел как «сначала освоил всё, потом получил должность». Следующий уровень я добирал уже внутри работы. Это не значит, что после оффера можно закрыть ноутбук и ждать переводов. Это значит, что работа даёт и задачи, и среду, и чужие решения, на которых действительно растёт опыт.
Я не обещаю, что в каждой компании новичку дадут три спокойных месяца. Где-то есть онбординг, где-то с первого дня наваливают задачи. Поэтому мне важнее понять реальную ситуацию, чем убеждать себя, что после удачного собеса всё обязано пойти гладко.
Первая неделя без показательной суеты
Я бы не пытался в первые дни доказать, что меня наняли не зря, количеством сообщений в чате. Полезнее разобраться в нескольких простых вещах:
- Где работать. Доступы, репозитории, задачи, документация, тестовая среда. Если доступа нет, это отдельная помеха, а не твоя техническая несостоятельность.
- У кого спрашивать. Кто знает конкретную систему, кто решает вопросы по задачам, а кто выдаёт права. Один тимлид не обязан помнить всю инфраструктуру.
- С чего начать. Понятная задача с проверяемым результатом полезнее попытки сразу спасать весь проект. По ней видно, как здесь вносят изменения и проверяют работу.
- Что сохранить себе. Заметки о том, где что лежит и как устроен процесс. Не для отчёта о собственной прилежности — чтобы второй раз не проходить тот же квест.
Если несколько дней ушло на доступы, не надо компенсировать это бесплатными ночами. Лучше зафиксировать, чего не хватает, и выбрать то, в чём можно разобраться сейчас. Чужая организационная медлительность не делает тебя должником компании.
За что платят и что хотят получить
«Разобраться в проекте» — слишком размытая задача. Я за конкретику: что нужно сделать, к какому моменту, с чьей помощью и как поймём, что готово. Такой разговор нужен прежде всего мне — меньше гаданий, меньше внезапных требований.
«Что сейчас самое важное? Какой результат нужен от меня в первую очередь? Если одновременно прилетят ещё три задачи, что из этого откладываем?»
И ещё: обещания на собеседовании стоит сравнить с действительностью. Обсуждали спокойную инфраструктурную работу, а получили круглосуточное тушение пожаров? Это повод обсуждать условия или искать другое место, а не молча доказывать свою универсальность.
Спрашивать, а не изображать всезнание
Для меня вопрос — способ сэкономить время. Сначала посмотрел, что уже есть, попробовал понятное решение, упёрся — пошёл к тому, кто знает контекст. Нет смысла три дня молчать только ради образа человека, которому никогда не нужна помощь.
«Хочу сделать X. Сейчас получается Y. Проверил вот это, не помогло. Здесь есть особенность, которую я ещё не знаю?»
Это не магическая формула, чтобы понравиться тимлиду. Просто с таким вопросом проще получить полезный ответ. И да, если объяснение не понял, можно переспросить. Второй вопрос дешевле второго сломанного деплоя.
Учиться на работе — буквально
Когда я говорю «получать опыт уже за зарплату», я не имею в виду восемь часов работы и ещё пять обязательной учёбы ночью. Разбор задачи, документации и незнакомого инструмента — часть выполнения этой задачи. Не всё обучение нужно выносить из оплачиваемого дня.
- Разбирать то, с чем столкнулся. Если задача про Helm, мне нужен Helm в контексте этой задачи, а не весь курс про облачную архитектуру.
- Читать уже работающие решения. Репозиторий, история изменений, закрытые задачи и конфиги дают контекст, которого нет в абстрактном уроке.
- Проверять в песочнице. Небольшой отдельный стенд позволяет ошибаться без чужого продакшена. Как я смотрю на такую практику — в разборе DevOps изнутри.
- Пользоваться ИИ. Разобрать ошибку или непонятную конструкцию с нейросетью нормально. Пароли, токены и закрытые данные для этого в публичный чат не нужны. Ответ нейросети всё равно проверяешь ты.
Если пришёл с резюме на вырост, разрыв придётся закрывать. Я не убираю серую зону из разговора: именно в этот момент бумажная версия встречается с реальной задачей. Но и превращать каждый вечер в наказание за то, что осмелился получить оффер, не надо. Смотри, где именно не хватает базы, и занимайся этим, а не всем IT сразу.
Если кажется, что тебя сейчас раскусят
Мне не нравится идея, что человек обязан сначала почувствовать себя достойным зарплаты. Договор уже есть. Теперь вопрос не в твоём праве находиться в этой компании, а в конкретных задачах: что получается, что пока нет и что с этим делать.
Незнакомая инфраструктура и отсутствие знаний вообще — не одно и то же. Не знаешь, где у них лежат секреты, — узнай. Не понимаешь сам механизм, который используешь, — разбери. Общее «я ничего не умею» не помогает ни в одном из этих случаев.
Мне ближе смотреть на сделанное, чем мерить себя чужой уверенностью на созвоне. При этом оффер — не сертификат всезнания, а отказ одной компании — не приговор профессии. На моих записях собеседований хорошо видно, что даже с большим опытом можно зависнуть на вопросе.
Нормально работать, не становясь удобным
Можно сообщать, что сделал и где застрял, не жить в рабочих чатах круглосуточно. Можно договариваться о сроках, не брать всё подряд. Можно не соглашаться с устройством проекта, не устраивая из каждого обсуждения битву за правоту.
Для меня нормальные рабочие отношения — это когда понятно, кто за что отвечает и чего ждать друг от друга. А не когда все должны постоянно демонстрировать энтузиазм. Если от тебя ждут не результата, а бесконечной доступности, это уже отдельная часть условий работы — и не факт, что она тебе выгодна.
Про контроль программистов у меня есть отдельное видео. После оффера полезно проверить, сколько обещанной свободы осталось в реальности.
Что действительно мешает
Я бы смотрел не на список качеств «хорошего сотрудника», а на вещи, из-за которых сам теряешь управление работой:
- Делаешь задачу, но не знаешь, какой результат от тебя нужен.
- Не имеешь нужного доступа и неделями считаешь это собственной медлительностью.
- Говоришь «готово», хотя ещё не проверил, работает ли решение.
- Берёшь новые задачи, не обсуждая, что произойдёт со старыми сроками.
- Затыкаешь любую проблему своим вечером — и постепенно превращаешь это в обычный режим.
Слабые знания тоже могут мешать и стать причиной расставания. Делать вид, что увольняют только за плохую коммуникацию, было бы сказкой. Но и любой промах не означает, что всё потеряно: разбирай конкретную ситуацию, а не выноси себе приговор заранее.
Не справляюсь — или мне это не подходит?
Я бы сначала разделил три истории: не хватает знаний, не хватает условий для работы или объём просто не помещается в рабочий день. Они не лечатся одним универсальным «старайся больше».
В первом случае — точечный добор базы. Во втором — доступы, объяснение контекста и помощь коллег. В третьем — разговор о приоритетах и нагрузке. Если компания на любой вопрос отвечает «это твои проблемы», тебе тоже есть что о ней понять.
И не обязательно любой ценой проходить испытательный срок. Можно решить, что это место тебе не подходит. В 2026 году я вообще ушёл из найма — не потому, что наконец нашёл идеальную компанию, а потому, что захотел делать свои проекты. О моём отношении к переходам — почему я сменил 23 компании.
Если расстались, забираешь полученный опыт, обновляешь резюме и решаешь, куда дальше. Порядок увольнения и оформление разбираю отдельно на IT-Para. Здесь главное: неудачное место не обязано становиться главным событием твоей жизни.
Частые вопросы
Сколько длится испытательный срок в IT?
По общему правилу ТК РФ — не больше трёх месяцев. Шесть месяцев допустимы для отдельных категорий, например руководителей организаций, а не любого тимлида. Конкретный срок и само условие об испытании смотрите в трудовом договоре.
Что делать, если ничего не понимаешь на новой работе?
Разделить незнакомый контекст и пробелы в базе: получить доступы, найти человека, который объяснит систему, взять понятную задачу. Изучение рабочего инструмента — тоже часть работы, а не автоматическая обязанность учиться ночами.
Как справиться с ощущением, что тебя сейчас раскусят?
Я бы смотрел на конкретику: что уже получается, где застрял и чего не хватает для следующего шага. Незнание чужого проекта не обнуляет весь опыт. Не нужно превращать каждую рабочую ошибку в оценку себя целиком.
Могут ли уволить на испытательном сроке?
Да. При неудовлетворительном результате испытания работодатель должен письменно предупредить не позднее чем за три дня и указать причины. Нельзя обещать, что пробелы в знаниях не повлияют на решение. Сам работник во время испытания тоже может уйти, письменно предупредив за три дня.
Видео по теме
Как не выгорать на трёх работах параллельно
Тотальный контроль: что ждать от работодателя
Как стать айтишником после 30: реальные кейсы
Есть своя история с новой работой?
В закрытом комьюнити «Будни Айтишника» обсуждаем такие ситуации. Я там отвечаю и помогаю; платный вход нужен против спама. Это общение, не персональное сопровождение на испытательном.
Формат чата и отдельной индивидуальной работы описан на странице менторства.