Как я нашёл работу и ушёл оттуда через месяц.

Я фронтенд-разработчик и уже больше семи лет в разработке. Чуть больше месяца назад я устроился на работу в компанию Beget на должность middle frontend разработчика в команду core и уволился с испытательного срока спустя месяц.

Нижеизложенное эссе — попытка наиболее полно изложить мой опыт трудоустройства в компанию Beget на должность middle frontend разработчика в команду core и причины, почему я покинул компанию через месяц после трудоустройства.

Данное эссе — лишь описание частного опыта через призму личного восприятия и ваш опыт может отличаться от моего.

Я постарался подавать ситуации настолько не предвзято, насколько способен, но, очевидно, полностью отстраниться от эмоций и субъективного восприятия невозможно.

То, что я описываю — ситуация в одном отделе над одним проектом и не говорит о всей компании в целом.

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

Ещё отдельно хочу отметить HR. Коллеги общались дружелюбно, хорошо выполняли свои обязанности и старались помочь во всех ситуациях. HR отдел — лучшее, с чем я столкнулся с Beget.

И пара слов о технических деталях, которые я упомянул в статье.

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

У меня в трудовой два вкладыша. Мне довелось поработать до Beget в трёх it компаниях: Redsys, ЛАНИТ и МТС, а до этого на Почте России и нигде не было ничего, похожего на то, что я получил в Beget.

Началось наше с Beget сотрудничество не очень ровно: с отказа. Нет, конечно, был отклик, интервью, но после — отказ с мотивацией «оверквалифайд».

Ну отказали и отказали. Я "похвалился" отказом в «сетке» и пошёл искать работу дальше.

Однако через две недели Бегет вернулись и аккуратно спросили, не нахожусь ли я ещё в поиске. Мол им нужно ещё расширить команду.

Я к тому моменту уже 10 месяцев как искал работу — кто вышел на рынок в 25-26 годах, те понимают — и не долго думая согласился на предложение. Договорились, что первый рабочий день будет 5 июня 2026 года.

Перед началом работы меня предупредили, что погружение будет интенсивным. Не обманули. В первый же день мозги мне поплавили как следует. Меня ожидало три созвона. Два с HR: приветственный для знакомства с компанией и для получения обратной связи по первому дню и один — самый важный — с заместителем техдира и моим будущим наставником (это, если что, два человека).

На знакомстве с компанией мне рассказали о структуре, основных корпоративных ресурсах и как в них ориентироваться, о принятых в компании способах коммуникации и к кому по каким вопросам пообщаться. В довершение отправили в меня ссылку на статью в Confluence с описанием компании, ценностей, принципов, структуры и вот этого вот всего. Конечно с перекрёстными ссылками на пространства разделов. Очень на самом деле солидно сделанная и тщательно оформленная статья.

Дальше — встреча с зам. техдира (ЗТД) и с наставником (Н).

Сначала слово взял ЗТД. Он рассказал мне об испытательном сроке и критериях его прохождения. Показал расписанный в Confluence план ввода меня в должность с явно прописанными количественными и качественными показателями, необходимыми для успешного прохождения. Там что-то вроде 90% выполненных в срок задач; не больше 40% задач с критическими доработками на ревью и подобное. Вообще, такие показатели практика совершенно правильная и говорит о том, что в компании полный порядок с онбордингом и адаптация новых сотрудников. И поначалу оно именно так и было. Но я забегаю вперёд.

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

Сначала мы прошлись по Confluence разделу отдела разработки. Что актуально, а что — нет. На что обратить внимание, а что пропустить. И особое внимание Н. уделил доке с описанием правил и принципов разработки.

С правилами всё понятно — это, по сути, кодстайл и договорённости "используем это, не используем то".

С принципами прикольнее. Вот некоторые примеры:

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

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

Основных проектов оказалось два: сайт компании и контрольная панель. Мне рассказали, зачем они нужны, кто в основном ими занимается и к кому подходить с вопросами. Помимо этого показали собственный внутренний портал, написанный на angular.

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

Интересно, что по-человечески мне этого никто не объяснил. Все говорили «с апи общаемся по proto», а я, как дурак, хлопал глазами и не понимал, как они умудрились rpc с фронта дёргать. Потом, поковырявшись в коде, уже разобрался, что rpc с фронта никто не дёргает. Всё через классический REST.

В общем, после осмотра гитлаба я по ssh подключился к поднятой под меня виртуалке, под внимательным взором наставника подключился к Гитлабу и стянул проект. После — под тем же внимательным взглядом — прочитал документацию и поднял проект. Опыт, скажем так, не очень комфортный. И не самый тривиальный, потому что сначала нужно проинициализировать git модули, подтянуть их все, сгенерировать из них api, и только потом можно собираться.

Кстати, о виртуалке! Вся разработка проводится на облаке Beget. Компания выделяет каждому разрабу виртуальную машину. Неплохую: 8 ядер, 16гб оперативки. Там преднастраивается специальное окружение: пачка докер контейнеров с nginx и другими приблудами. К виртуалке подцепляешься по ssh, туда тащишь код и там уже ведёшь всю разработку. Поначалу немного непривычно, но в целом удобно, чтобы не забивать рабочими проектами личный комп и не мучить сборкой собственное железо.

Проекты тоже поднимаются в контейнерах. В Readme описана последовательность команд для правильной сборки, но вообще есть sh скриптики чтобы поднять/опустить дев или прод сборку. Удобно на самом деле. Стоит только привыкнуть.

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

Бошка к тому моменту кипела от количества впихнутой в неё за день информации.

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

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

На самом деле, их и задачами стыдно назвать. Три мелких бага, каждый максимум на час работы. И на это мне дали 4 дня — до пятницы.

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

В команде было принято два созвона: в 12 для синхронизации статусов и разрешения возникших проблем и в 18 для того же самого и демонстрации успехов. Натурально, ребята стримили экран и проходили пользовательские сценарии или дёргали апишку с разными наборами данных. Что-то вроде приёмки функционала.

Итак, в четверг был мой первый такой вечерний созвон. Начали мы в 18, закончили в 20:45. Причём примерно до 20 часов я просто сидел и смотрел, как остальные протыкивают интерфейс или дёргают апи, а лид напару с владельцем продукта смотрят, правильно или не правильно работает система.

Вот такие рабочие ритуалы.

Когда же очередь добралась до меня, мне представили будущую задачу и показали, где её искать в Miro. Ага, Jira для задач, почему-то, не использовали. Хотя в компании Jira, конечно, закуплена. Я даже пару раз туда заходил, чтобы баги забрать. Но задачи в Miro. Продактер даже канбан доску там закостылил, лишь бы не пользоваться нормальным инструментом.

В общем, мне показали три карточки с задачами и сказали: «Этим займёшься с понедельника. Декомпозируй и проставь сроки». Помним, что сейчас четверг. Под декомпозицией подразумевалось создать дополнительные карточки со значениями

Кайф? Я, вот, думаю — не то слово. Я на это посмотрел и предложил, мол, давайте я в пятницу задачи подробнее изучу, нормально декоспозирую и оценю. Лид согласился, но продактер упёрся: «Нет, давай сейчас». Ну, в принципе, как хотите. Я быстро "на-глазок" раскидал карточки и попробовал ещё заход, мол давайте сроки завтра проставлю. Не горит же. Продактеру хоть кол на голове теши. Упёрся и всё тут: «Нужно сегодня». Тут я уже совсем от балды сроки накидал и спокойно ушёл. Признаться, к тому моменту я уже был порядком раздражён происходящим идиотизмом. Уже полтора часа как пришёл из садика сын — спасибо бабушке, что забрала — и уже сорок минут как нужно вести на прогулку собаку, а я сижуу на ненужном созвоне и занимаюсь работой, которую с тем же успехом могу спокойно сделать на следующий день.

И раздражён оказался не только я. Часом раньше мнение о бессмысленности встречи уже высказывала коллега-фронтендер. Забегая вперёд расскажу, что её после демарша убрали с проекта. Но это будет чуть позже.

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

По сути, аренда домена — готовый бизнес-процесс, который нужно адаптировать под новые требования законодательства для трёх доменных зон — ru/su/рф. В целом выглядит не сложно, если бы не несколько "но".

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

На следующий день — в пятницу первой недели, то бишь — после двенадцатичасового созвона меня попросил остаться продактер. Что он мне сказал, я постараюсь привести близко к тексту. Простите, дословно не помню.

«Ты, вот, вчера вечером про декомпозицию и оценку говорил, что завтра сделаешь. Помнишь? Вот не говори так больше. Тут такое не приветствуется.»

Признаюсь, я от такого заявления немного прифигел. Но на этом всё не закончилось.

Примерно через час, когда я уже занимался задачами, меня снова попросили подключиться в созвон. Там уже были продактер, тимлид и замтехлида. Меня как будто на ковёр вызвали. Речь держал замтехлида. Спросил, в чём суть конфликта. Сообщил, что проект срочный и переработки будут. Уточнил, готов ли я к ним. А я что? Мне работа нужна. Что с рынком — вы и без меня знаете. Конечно, я готов к переработкам. Но с оговоркой, что с 7 до 11 я должен уделить время семье, а потом, ночью, могу работать. На том порешили.

Если вы думаете, что переработки по-вечерам закончились, то вы заблуждаетесь.

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

Четверг. Утро. Промежуточный созвон по проведению итогов и принятию решения, продолжать ли со мной сотрудничество.

В роли судьи замтехлида. в роли обвинителя владелец продукта. В роли свидетелей наставник, тимлид и второй фронтендер на проекте — девушка, с которой я довольно плотно общался и взаимодействовал по работе. Напоминаю, что вторую сняли на следующий день после её демарша.

Наблюдательный читатель может удивиться: «почему тимлид в роли свидетеля, а не защитника? Ты же часть его команды!». Ну, такой тимлид. Не обвинитель — и на том спасибо.

Если не пересказывать все подробности разговора, то голоса в мою пользу были 3 к 1. То есть явно против только продактер. У наставника были небольшие замечания по тому, что я не всегда рефачу код, в котором работаю, но в целом он тоже дал апрув.

Дальше спросили обратной связи у меня. Само собой я сразу же сообщил о том, что работать без документации труднее, чем с ней. Приходится тратить больше времени на сбор информации о бизнес-процессе, отрывать коллег от работы и результат получается менее надёжным. В принципе, ответ ЗТЛ отрезал все мои дальнейшие вопросы. Он сказал:

«Написать нормальную документацию — это минимум неделя рабочего времени. Плюс её нужно поддерживать в актуальном состоянии. А подойти спросить быстро.»

После этого отпало всякое желание давать ему какую бы то ни было ещё обратную связь.

По итогу созвона, ЗТЛ решил, что этого достаточно для сомнений и дал мне новую задачу со сроком до вечера понедельника.

Важно: до вечера понедельника не просто реализация, а релиз на прод.

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

Оказалось, что часть бизнес-процесса по юрлицам считают не сделанным и это, оказывается, отдельная задача в планах. А на проде даже api ещё не поддерживает юрлиц.

Думаете, кто-нибудь сказал мне это, когда я делал продление домена? А хрен-там плавал!

Итак, из чего же состоит моя задача по имплементации бизнес-процессов по юрлицам? (ко всему мысленно можно приписывать «… и ИП»)

Итого, 6 бизнес-процессов за 2.5 дня. Бизнес-процессов не описанных, наполовину сделанных, при этом, что именно в них не доделано — мне нужно выяснить самостоятельно путём сопоставления фактического поведения-макетов и уточнения у тимлида, что правильно: фактическое поведение или макеты? Почему так проблемно? А потому что документации нет, а в коде видно явно намеренно сделаную реализацию, которая расходится с макетом. Я был бы плохим разработчиком, если бы не предположил, что изменение было сделано по какой-то договорённости, которую забыли зафиксировать и информацию о которой не передали дизайнеру. А значит — нужно уточнить.

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

Начал я с регистрации домена. Когда уточнял у тимлида логику бизнес-процесса обнаружилось, что нужно делать ручное кэширование экрана. Суть в том, что пользователь может получить несколько юрлиц, а выбрать администратором может только одно. Вот, он может выбрать юрлицо, передумать, вернуться на экран выбора, передумать снова и выбрать первоначальное. А каждый выбор юрлица — запрос в ЕСИА для получения данных этого юрлица. А для получения данных нужен токен. А токен одноразовый. То есть второй запрос по тому же токену возвращал ошибку и ломал сценарий. И, вот, чтобы этого не происходило, нужно кэшировать запросы от ЕСИА и понимать, когда пользователь повторно выбирает оргу, которую уже выбирал прежде.

А запрос дебильный и на все(!) бизнес-процессы он один. И его внятной документации нет.

А под капотом nuxt. А каждый запрос в ЕСИА работает через редирект. И с этим всем нужно разбираться.

Пришлось костылить кэширование pinia состояния в localStorage с механизмами автоматической очистки. 7 часов фактической работы, из них — два ночью с 11 до 01 ночи. И это только для управляющей панели.

Потом то же самое для сайта с той разницей, что тут использовал sessionStorage. Оно прошло уже быстрее, но напоминаю, что кодовые базу похожи, но не идентичны.

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

Тимлид: помнишь, мы договаривались, что по процессу обновления должно быть так-то и так-то?

Бэкендер: нет. Не договаривались.

Тут-то я вспомнил, как ЗТЛ мне ответил, что «Документацию писать долго, а спросить быстро». Ну да, ну да...

В общем, поговорили, выработали костыль для реализации ожидаемой бизнес-логики. Бэкендер пообещал поправить и запросил час, а я тут же на месте сказал, что задача к вечеру понедельника на прод не доедет ни в каком случае. Прямо говоря, я уже был изрядно раздражён и могу привести свою цитату дословно. Уж это я помню.

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

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

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

Это в 17 пятницы, с двумя бизнес-процессами в ревью, одним заблокированным бэкендом и ещё тремя с неизвестным количеством багов и доработок, которые мне по ним докинут.

В этот момент я и понял, что лучше уж обратно на рынок, чем с этими двумя в одной команде.

Ну и, собственно, я здесь.

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

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

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

Дудки. С таким отношением я работать не согласен.

Фух. Закончил.

Признаюсь, публиковать это эссе мне страшновато. По ряду причин. Однако считаю, что прозрачность процессов в компании пойдёт этой самой компании на пользу. Рынок сейчас сложный и люди готовы хвататься за любой шанс. Если кто-то, прочитав моё эссе, решит, что подобный формат работы для него не подходит, он сохранит и собственное время, и деньги компании, которые та в ином случае потратила бы впустую на адаптацию сотрудника, который всё равно уйдёт с испытательного срока, как и я.

Вот теперь, наверное, всё. Спасибо всем, кто дочитал до конца и, если вам есть что сказать, приглашаю в комментарии для дискуссии.