Анализ и Лидство | Настя Шкваренко

Не лучшая стратегия для аналитика ждать у моря погоды Кайф работать на проекте, на котором ты уже знаешь всё как свои пять пальцев. Задачи идут привычно и на потоке, знаний достаточно и процессы понятны, пусть иногда и бесят. Дааа, местами это может быть скучновато, зато есть время выдохнуть. В такие моменты блаженного неведения и приходят перемены: какая-то новая большая фича, с реализацией которой ты не сталкивался до этого, или компания хочет провести performance review. И здесь приходится уже разбираться находу, а это очень нервно и долго, а нужно было вчера. Или вовсе в наше нестабильное время проект неожиданно могут свернуть и, если повезет, тебе предложат место на новом. А там может ждать что угодно: другой стек, другие задачи и уже будут нужны другие знания и опыт для их решения. А искать новую работу сейчас не для слабонервных, вилки зарплат упали и это всё может растянуться на месяцы. Сейчас особенно важно себя обезопасить и заранее разобраться в асинхроне, а не тогда, когда от этого будет зависеть новая работа или проект. Поэтому если хочешь спокойно работать и не переживать каждый раз, когда речь заходит про реализацию webhook'а для статусов оплаты или обработку сообщений из Kafka топика, приглашаю на мой интенсив по асинхронным интеграциям. Старт – 15 июля. На нем мы разберем все основные способы асинхронного взаимодействия: webhook, websocket, polling, SSE, брокеры (Kafka и RabbitMQ), асинхрон на уровне БД, файлов и через джобы. Всё это будем осваивать на реальных кейсах с работы и собесов, без оторванных от жизни кафешек и кинотеатров. И в маленькой группе с моей детальной обратной связью. После 3х недель ты: 1️⃣ сможешь уверенно проектировать асинхронные интеграции 2️⃣ будешь знать, как ставить такие задачи разработке и что нужно описать в спецификации от аналитика 3️⃣ освоишь, как выбирать подходящий способ интеграции под задачу 4️⃣ сможешь участвовать в принятии архитектурных решений и на равных обсуждать это с командой разработки, архитекторами и техлидами Осталось всего пару мест. Напиши мне @shkvara и я расскажу про формат, стоимость и отвечу на твои вопросы.

Не могу пройти собес ⛔️ Ты наконец-то дошел до технического интервью, пройдя все игноры, скрининги и отказы. Готовишься к нему как можешь: тренишь с ИИшкой, поднимаешь свои старые материалы, думаешь, как грамотно подать свой опыт. А потом получаешь фидбек: недостаточно глубокие знания в архитектуре, мы ищем человека с детальным пониманием брокеров, нам не хватило вашей экспертизы в кейсе, который мы вам дали на собесе. Чаще всего приходит отказ, мало вероятнее – оффер, но с понижением от запрашиваемой зп. И с этим сталкивается каждый второй. Опыт есть, задачи на проекте закрываешь, а на собесе что-то идет не так. Рынок реально поменялся. И я не только про его изрядную тухлость по вакансиям. А скорее про то, что если уж в этом киселе и удается сойтись с потенциальным работодателем, то нужно не упустить такую возможность и выложиться по-максимому. Пока рынок был на подъеме можно было позволить себе что-то недоучить к собесу или забить на какие-то темы. Сейчас конкуренция возросла и, чтобы ей соответствовать, нужно знать всё и даже больше. Чтобы потом не было эффекта: "Если бы глубже покопался в этом, ответил бы по-другому". Раньше на позиции middle можно было к собесу быстренько освежить теорию и этого было бы достаточно. Например, про ту же Kafka: ее плюсы\минусы, в общих чертах как работает, что в спеке написать и всё. Сейчас даже на middle могут уже выдать такое (хотя вопрос senior'ный по мне): Представь, consumer топика упал посреди обработки сообщений, потом перезапустился. Какие риски ты видишь? Что вообще нужно предусмотреть при обработке сообщений? И тут на одной теории не выехать. Чтобы уверенно выходить на middle+ и senior, нужно именно понимать, как устроены асинхронные интеграции на практике, их нюансы проектирования. Не просто знать базу о них, а уметь рассуждать, как делать идемпотентность, что такое Outbox паттерн для брокера и как его реализовывать и зачем он, про retry-политики и пр. Уверенность на собесе считывается мгновенно, а она формируется из глубоких знаний, когда нет ощущения "ну вот сейчас они спросят то, что я не знаю" и реальной практики в теме. И тогда вместо переживаний приходит спокойствие и рассудительность. Из этого состояния уже можно общаться с интервьюером на равных, показывая свою экспертность, чтобы он сделал вывод: "а он(а) шарит". И перетендовать на верхний край вилки, конечно же.

Подучу асихрон потом, сейчас пока он мне не нужен Раньше это действительно была рабочая стратегия и, более того, я сама советовала всем оставлять эту тему напоследок, и заняться чем-то более приоритетным: основами архитектуры, api, БД. Раньше к этой теме действительно относились более лояльно и не сильно заваливали по ней вопросами. Также было и у меня. Когда я только переходила из бизнес в системные аналитики, я вообще не знала ни одного способа асинхронного взаимодействия. Ну ладно, я знала как они все называются и их определения 🤓 И это было вполне окей. На собесах больше пытали про REST. А когда на проекте я впервые столкнулась с брокером, все отнеслись к моим вопросам довольно лояльно, ведь от аналитика ждали лишь понимания, что это посредник между сервисами для обмена сообщениями, а как там это документировать и что от тебя нужно команде, – разберешься по ходу. С годами всё, как обычно, поменялось. Сейчас на собесах уже копают сильно вглубь: 🔘чем отличаются и когда лучше использовать Kafka и RabbitMQ 🔘что описывать в документации для взаимодействия через брокер 🔘как описать обработку webhook, в чем его особенности реализации и пр. Этот список можно еще долго продолжать. Это уже не тема для "будет плюсом", а обязательное требование во многих вакансиях. Даже если на текущем проекте аналитику пока не нужно в это погружаться или вовсе на проекте не используются всякие там брокеры, важно помнить, что задачи, да и проекты, меняются. В такие моменты те, кто уже имеет опыт работы с множеством способов интеграций, чувствуют себя стабильнее и увереннее. За последние полгода у меня было несколько ребят, которые столкнулись с сокращением. Они внезапно оказывались в ситуации, когда нужно срочно искать работу, и приходилось за очень короткий срок поднимать весь этот огромный пласт информации и галопом пытаться набрать практический опыт в этих темах. Поэтому оставить на потом часто выходит боком. Мы говорим себе: "Когда будет время, я вернусь и это обязательно освою". Но чаще всего подходящий момент не наступает, а вот острая необходимость обычно случается, когда не ждешь. Когда нужно быстро вливаться в новый проект или уже через пару дней проходить важный собес. И все это приходится осваивать в экстренном режиме как в ночь перед экзаменом. Но, как мы помним, такие знания долго не задерживаются 🐹

Знаете, что стабильно входит в топ-5 тем обсуждений с моей командой на проекте? Наряду с продолбанными сроками в конце квартала, проблемами с релизом, который мы планировали на днях и уже перед всеми закоммитились, и чудесными нововведениями в процессах, которые и так уже сложнее некуда, но их нужно исполнять 🤡 ✨Архитектурные споры ✨ Они бывают очень жаркими. У каждого свое мнение. Каждый показывает свою экспертность. Это моя любимая часть работы, потому что в этих обсуждениях сконцетрированы ГОДЫ опыта, кейсов и ошибок, ТОННА изученных статей, лекций и митапов, НЕМНОЖКО инфы из иишки об этом и КАПЕЛЬКУ уверенности в своей правоте 😉 Когда решаем, в каком сервисе разместить функциональность (тут можно красиво спихнуть часть своих доработок другой команде), как эффективнее реализовать алгоритм или каким образом делать интеграцию с другой системой. Сколько я здесь работаю, всегда всплывает один и тот же вопрос: так мы делаем синхронно или асинхронно? А выбирать всегда ой как сложно. С одной стороны, есть куча архитектурных стандартов, как принято делать, а как уже, мягко сказать, не рекомендуется и люди "выше", с которыми нужно согласовать. А с другой – сроки и бюджет: продакт, которому выполнять KPI продукта, вечная нехватка ресурсов на задачи и всякие дефекты с высоким приоритетом. Чаще всего это выбор из двух зол. И тот, и тот вариант может повлечь много проблем и нюансов. Чтобы принимать такие решения и уметь общаться на равных с архитекторами и техлидами, важно знать как можно больше о разных способах интераций. В enterprise, особенно в банке, уровень погружения системного аналитика в эти детали очень глубокий. Там от аналитика ожидают, что он понимает разные варианты реализации, их плюсы и минусы, имеет реальный опыт проектирования и документирования таких интеграций, умение оценить риски и вместе с командой выбрать решение, которое лучше всего подходит под конкретную задачу. Поэтому, чтобы спорить на равных с серьезными дядями 😎, в каких случая можно просто дернуть API, в каких лучше использовать брокер, а когда хватит и фоновый воркер сделать, недостаточно просто знать теорию, важно понимать последствия каждого решения, как их правильно реализовать и учитывать другие факторы проекта, помимо требований. И пока я в этом всём многообразии не разобралась, я действительно переживала перед каждой такой встречей. Боялась, что попросят доп. аргументы или опровергнут мои. А потом с новым опытом и знаниями приходила уверенность в своих решениях и спокойствие при подобных архитектурных беседах.

Неочевидные ошибки при проектировании API – часть 2 Продолжаем разбирать кейсы, по которым довольно быстро можно понять уровень аналитика на собесах и в работе. 1️⃣Создавать отдельные эндпоинты для передачи 2-3 атрибутов Иногда в голову может прийти идея: мне же нужно получать только часть параметров сущности, сделаю такой эндпоинт отдельно только с теми атрибутами, что мне надо. И получается такое: GET /orders/{id}/main-data GET /orders/{id}/track-code GET /orders/{id}/delivery-info GET /orders/{id}/documents ❌В чем ошибка: API начинает разрастаться множеством похожих эндпоинтов, каждый из которых решает узкую задачу. В результате потребителям приходится выполнять дополнительные запросы для получения информации об одном и том же ресурсе. Это усложняет интеграцию с API и увеличивает нагрузку на сервис, т.к. нужно делать больше вызовов. А для команды это чревато внесением правок сразу в несколько эндпоинтов при любом изменении модели данных ресурса. 🆗Как лучше: если нет особых требований по производительности, безопасности или источникам данных, лучше отдавать полное представление ресурса в ответе. 2️⃣Использовать синхронное взаимодействие по API там, где достаточно просто события Часто разбираем этот кейс на mock-собесах. Представим инвестиционное приложение. После покупки акции пользователю нужно начислить бонусные баллы в рамках маркетинговой акции. И нередко звучит такой вариант: сделать в сервисе бонусов API эндпоинт и вызывать его при каждой покупке акции. То есть сервис покупки акций должен дождаться ответа от сервиса бонусов, прежде чем завершить свою работу. ❌В чем ошибка: использовать синхронный API вызов, где достаточно сообщить о произошедшем событии. Если второстепенные процессы (начисление бонусов, отправка уведомлений, обновление аналитики) вызываются синхронно из критически важного сервиса, они увеличивают его нагрузку, время выполнения и становятся дополнительными точками отказа. Проблемы в сервисе бонусов не должны влиять на ключевую фичу – покупку акций. 🆗Как лучше: в этой ситуации мгновенный ответ по начислению бонусов не нужен, поэтому можно рассмотреть асинхронное взаимодействие через брокер (Kafka, RabbitMQ, например). Сервис покупки публикует событие и сразу продолжает работу, а сервис бонусов обрабатывает его независимо. Это снижает связанность сервисов, повышает отказоустойчивость и способность лучше выдерживать нагрузку. Кстати, один из маркеров middle+\senior аналитика для меня – это умение не зацикливаться на одном решении, а предлагать много вариантов реализации и уметь выбирать между ними. А для этого нужно развивать насмотренность во всех видах интеграций: брокеры и ESB, разные реализации API (websocket, webhook, polling и др.), на уровне БД и файлов.

Почему так часто пропадаешь? Моя жизнь последние пару месяцев – один нескончаемый наркотрип из работы, обучений, менторинга, проблем со здоровьем и попыток как-то преуспевать в личной жизни 😭😭😭 Накрыло меня от этой отборной дури так сильно, что я даже не сразу поняла, что это со мной такое происходит, и двигалась на автопилоте. Местами, конечно, было кайфово: новые впечатления, поездки и люди. Но вчера меня догнал, как отходняк, один непростой вопрос – ХТО Я? 😐 Мем смешной, а ситуация страшная. Потерять себя оказывается довольно просто. Череда событий (как будто я свою жизнь на x3 смотрю) вымотала и не оставила желания всё обдумать. Психика в стрессе и нестабильности всегда выбирает проторенную дорожку. Моя – погрузиться в других людей: их мнения, чувства, реакции и помощь им. Хлебом не корми, дай кого спасти и о ком подумать. Поэтому я напрочь забыла как жить свою жизнь. Чего МНЕ хочется, какие у МЕНЯ цели, как МНЕ нравится и как со МНОЙ нельзя. А тут нет места творчеству и созиданию, а идеи вторичны. Проводить время с собой стало в тягость, оставаться наедине со своими мыслями невмоготу. Самое печальное, что даже годы терапии не помогли этого избежать, лишь в какой-то момент заметить и не оставаться в этом долго. Уже неплохо 🤗 И вот уже я бегу за блокнотом и ручкой в ближайший магаз, чтобы записывать поток своих мыслей, просто что приходит в голову. Для меня это самое действенное – писать о СЕБЕ. Еще помогло просто НАЧАТЬ проводить время с собой 🤨 По началу хочется кому-то позвонить или зайти полистать ленту, но потом втягиваешься и появляется ЖЕЛАНИЕ что-то сделать для СЕБЯ: выпить кофе в тишине, сводить себя вкусно покушать, погулять или написать этот пост в конце концов. Это я всё к тому, что мы у себя одни, других не будет. И только нам себя и вытаскивать 💙

Неочевидные ошибки при проектировании API Вчера уже закончился интенсив по REST API, а я так и не смогла в рассказ про то, что мы с ребятами вообще там изучали такого интересного 😁 😁 Исправляюсь прямо сейчас. В этом посте не будет всяких очевидностей типа PATCH нужно использовать для частичного редактирования или что ресурсы нужно называть во множественном числе. Тут будут только неявные кейсы в проектировании, по которым легко можно вычислить уровень аналитика. 1️⃣Выбор типа данных number для денежных сумм в API Одна из опасных ошибок в финтехе – проектирование атрибутов стоимости, суммы или баланса через числовой тип number. ❌В чем ошибка: стандартные типы с плавающей точкой допускают микро-ошибки при округлении. Спустя тысячи операций эти «копейки» накапливаются и приводят к нестыковкам в финансовой отчетности. 🆗Как правильно: передавайте деньги как integer, переводя в минимальные единицы (копейки или центы) или используйте decimal, который гарантирует точность дробей в коде. В API decimal часто передают как string(decimal), чтобы избежать потери точности. 2️⃣Передача атрибутов ид, статуса и даты создания при создании ресурса с потребителей Многие аналитики включают параметры типа id, status или createdAt в тело запроса на создание ресурса и тем самым обязуют потребителей API задавать их самостоятельно. ❌В чем ошибки и к чему это может привести по каждому из этих атрибутов: 🔘по Id: сервис сам отвечает за состояние ресурса и только он знает, какой корректный идентификатор назначить объекту. Один отдельно взятый клиент не знает о состоянии всех объектов в системе и может сгенерировать некорректный Id, что приведет к конфликтам. Конечно, есть исключения, когда это нужно, например, при интеграции двух систем у них у обоих будет свой ид сущности и также, если нам нужно обрабатывать кейс с идемпотентностью. 🔘по статусу: только сервер знает правила, по которым ресурс может переходить из одного состояния в другое. Также присвоение статусов на сервере дает возможность гибко менять флоу статусов, не дорабатывая потребителей. Поэтому лучше не передавать статус напрямую, а моделировать действия, которые приводят к смене статуса. Конечно, это не касается кейсов, когда у вас потребитель директивно говорит, какой статус должен быть установлен (например, сотрудник склада меняет статус посылки на "Отсортирована"). 🔘по дате создания: сервер может самостоятельно вычислить дату создания ресурса в момент прихода запроса к нему. Передача даты с потребителей избыточно. Исключением здесь будет наличие требования о том, что нужно фиксировать момент нажатия на кнопку или какое-то другого специфического действия потребителей (например, момент генерации сообщения). 🆗Как правильно: эти поля должны приходить в ответе от сервера после успешного создания ресурса. Ставьте 🔥 и выложу еще ошибки, у меня таких много накопилось 💅 #api

Интенсив по REST API стартанул пару недель назад, и сейчас у нас идет очень активная работа с ребятами на потоке. Честно, меня немного захлестнуло задачами, разборами и домашками, поэтому я выпала от нагрузки 🥺 Параллельно полностью набрался и менторинг, поэтому сейчас новых мест нет. Для тех, кто не успел попасть в этот поток или в менторинг, оставляю анкету предзаписи. Если освободится место на менторинг или я запланирую следующий интенсив, я в первую очередь напишу тем, кто оставил заявку, и у вас будет возможность вписаться в движ. Заполнение анкеты занимает буквально 2 минуты. И скоро я начну делиться всякими интересными штуками, которые мы обсуждаем с ребятами на интенсиве. Там уже накопилось много практических моментов, которые точно будут полезны и вам. Не переключайтесь ❤️

Сидеть на всём готовеньком Часто от аналитиков я слышу один и тот же запрос: Я работаю на проекте, где уже готова архитектура, спроектированы сервисы, есть API, есть структура БД. Я просто вношу доработки. А вдруг я не справлюсь с проектированием с нуля? И это очень понятно. Ведь я сама когда-то начинала именно с таких систем и мне было страшно самой выбирать и идти работать на проекты, где нужна была сильная проработка с нуля. Конечно, можно долго делать вид, что всё в порядке 😐 Работа есть. Задачи закрываются. Зачем думать о том, чего пока нет? И правда, пока проект стабильный, архитектура уже продумана, решения принимают архитекторы или разработчики, можно комфортно существовать внутри готовой конструкции. Но жизнь интересная штука и обычно сталкивает нас с тем, чего ты боишься. Поэтому даже на казалось бы стабильных проектах, начали разрастаться какие-то масштабные рефакторинги и проектирования новых модулей. И это всё равно затронуло меня 😬 А еще проект вообще могут закрыть или запустить новый продукт в компании. И вот уже нужно будет: ▪️проектировать архитектуру ▪️декомпозировать функции на сервисы ▪️создавать с нуля контракты API или брокеров ▪️проектировать структуру БД Участвовать в принятии решений или даже где-то самому принимать их, а не только описывать доработки. И вот, когда я попала в такую ситуацию, я мягко сказать начала тревожиться 😐 И начала судорожно это всё изучать. А сейчас пишу уже с той стороны, чтобы возможо уберечь вас от сложной и стрессовой адаптации, если такая ситуация настигнет и вас. Можно ведь без спешки и паники уже сейчас начать потихоньку разбираться в архитектуре, в интеграциях, в БД. Тогда и появится другое состояние. Если проект закроется или закончится, у тебя получится найти новый на рынке. Если возникнет необходимости на текущем месте в рефакторинге, разработке новых модулей или вообще продуктов, ты справишься. Если дадут задачу спроектировать что-то в с нуля, ты будешь знать, как это делать. И чтобы сделать шажок в сторону этого, предлагаю начать с самой популярной темы – REST API. После интенсива ты сможешь проектировать любой сложности API с нуля, а также прорабатывать интеграции с уже готовыми API. Осталось 1 место, напиши мне @shkvara, чтобы узнать детали 🏃‍♀️

Знаю != умею Я регулярно вижу одну и ту же проблему у аналитиков – они классно знают теорию, но не умеют применять её на практике. А это вскрывается очень быстро на реальных задачах. В итоге – отказы после собесов и, того хуже, увольнения на испыте. Горькая правда состоит в том, что вы не нужны работодателю со знанием только теории. Уже прошли те времена, когда это худо бедно работало. Сейчас же даже на собесах для джунов и начинающих мидлов дают сразу кейсы: просят спроектировать эндпоинт API, решить архитектурный кейс на взаимодействие систем и рассказать, что и как описывать в спецификации. Допустим, собес можно проскочить (такое, кстати, случается 👀). Но на испыте после первых задачек на интеграции и совместных обуждений с командой, всё станет ясно как день. Проверено много раз: сама и мои коллеги увольняли таких сотрудников на испыте. Представьте: человек приходит на проект, у него зп 3-4к$, а он не может самостоятельно прийти к команде со своими вариантами решений. Это отнимает много сил и времени у команды, а тем более сейчас в период оптимизации ресурсов за таким строго следят. Я общалась со многими аналитиками, и они делились похожим опытом: теория на курсах понятна, но практики нет или ее недостаточно. Домашка либо формальная проверка знаний тестом, либо без детальной обратной связи. В итоге тема вроде бы изучена, но применять её в работе всё равно сложно. Чтобы получить реальный опыт и отточить практику критически важна обратная связь и делать что-то руками самому с поддержкой опытого преподавателя. Это будет тепличный вариант, где можно спокойно и в своем темпе разобраться. Поэтому интенсив по REST API – это в первую очередь практикоориентированный курс с индивидуальной обратной связью. Домашки – это спецификации API и описание интеграций, решение реальных задач и кейсов с проектов. Я НЕ набираю много людей (до 10 человек), потому что работаю индивидуально с каждым. Практика проходит в формате настоящего ревью как на проекте: нет лимита правок, итерации исправлений до получения верного варианта. Так что интенсив НЕ подойдет тем, кто рассчитывает, что уверенность и навык появятся сами после просмотра материалов. Навык проектирования API формируется только через практику. На это нужно время и вовлеченность. Это не курс, который поставлен на поток с кучей участников, это камерный продукт без постоянных запусков раз в месяц с моей максимальной вовлеченностью. Для меня главное, чтобы после интенсива у вас остался реальный и релевантный опыт проектирования и интеграций API, который будет легко применить как в работе на проекте, так и на тех. собесах. Старт потока интенсива – 24 февраля 5 недель практики 8 модулей 35+ видео-уроков по 15-20 минут Онлайн-созвоны Q&A Домашки с моим ревью Группа до 10 человек После интенсива вы сможете: *️⃣самостоятельно проектировать REST API *️⃣уверенно проходить собесы на эту тему *️⃣писать спецификации, которые реально можно отдать в разработку *️⃣предлагать решения на проекте, а не ждать, пока вам скажут, что делать *️⃣понимать, как проектируются интеграции между системами по API Если хотите получить реальный опыт проектирования и интеграции API, а не просто знать теорию – напишите мне в личку @shkvara.

Увольнение – "лучший" подарок под Новый год Бу, испугался? 🐕 Очень страшно и небезопасно неожиданно терять работу. А вот Кате и представлять не надо – её сократили под Новый год. Представьте ситуацию: работы нет, конец года, никто уже особо не нанимает, да и найм возобновится только в середине-конце января. Это всё случается так неожиданно, что даже толком нет готовности к прохождению собесов и всех этих этапов отбора. Хотелось просто стругать салатики и пересматривать рождественские фильмы. И вот еще некоторые вводные, которыми поделилась Катя: - Тревога от нытья в проф.чатах аналитиков о том, что рынок умер и зарплаты мизерные - Желание устроиться в стабильную финтех-компанию с повышением зп - Отсутствие опыта работы с брокерами и некоторыми видами интеграций по API - Отсутствие навыка прохождения практической части собеса по system design/проектированию интеграций - 4 года опыта работы системным аналитиком, оценивала себя на middle уровень Помимо всего этого, еще сверху Катя добила меня: Ну и главное - назначенное через месяц техническое собеседование в желаемую финтех-компанию 😱 Ситуация была мягко сказать критическая, сроки поджимали со всех сторон. Я так не работаю, но мы решили проэкспериментировать, не ожидая каких-то сверхрезультатов, и провести "экспресс-курс молодого бойца" по подготовке к собесам 🫡 Времени у нас было в обрез. 3 недели, этого как раз хватило на 3 встречи: • первые 2 мы решили посветить теории, ее нужно было поднять, дабы смочь решать практику. Изучили архитектурные паттерны, прошлись по всем видам интеграций, а далее смогли погрузиться более детально в брокеры (Kafka и RabbitMQ) и повторить API. • и еще 1 встречу посвятили отработке кейсов для собеса. Решали задачки по system design и ситуационные тех. задач для собеса. Катя поделилась: Я хоть и смотрела многочисленные видео по решению кейсов на собесах, но когда ты делаешь это сам - это огромная разница. Оказывается, я до этого не понимала, какие вопросы действительно важно задать, а какие на собесе просто не нужны. Поэтому мы учились задавать правильные вопросы, работать с входными данными и предлагать подходящие варианты решения задач на основе теоретической базы и требований. В итоге: В этот месяц занятий я чувствовала себя намного спокойнее и увереннее в себе. А после наступления дня X с запланированным собесом: Кейс, который мне дали на собесе, показался мне лёгким, а ответы на теоретические вопросы отскакивали от зубов, ведь они были буквально про то, что мы ранее обсуждали. И самое главное, к чему привел этот успешный эксперимент, – это оффер с первого же собеса. пришел заветный оффер в тот самый финтех с желаемой зп (с повышением на 15%) и оценкой меня как middle+ специалиста. Чтобы не было розовых очков, это была наша огромная командная работа, а особенно, Катина личная: она была очень замотивирована и ответственно подходила к каждой моей рекомендации. Освоила тонну необходимой информации и даже доп.материалы. Катя смогла добиться таких классных результатов, потому что она очень сильно вкладывалась и интенсивно работала, в т.ч. самостоятельно. Иначе, такого бы просто не получилось. Такие головокружительные результаты возможны, если прилагать такие же сверхусилия. P.S. не читайте чатики со страшилками, не поднимайте себе тревожность. #отзывы

Сейчас работу найти сложно Рынок изменился, HR игнорят, на hh.ru работу найти нереально, "я сделал 100 откликов, 0 приглашений", на собесе спрашивают какую-то дичь, да еще и опыт потом приходиться подтверждать всякими рекомендациями с прошлых мест и справками от врача. Если читать это каждый день, можно легко отловить паничку 😵 Что многие успешно и делают. Рынок действительно изменился. И всё то, что я перечислила выше, действительно имеет место быть. Выбора адекватных вакансий стало в разы меньше. Но тут основная загвоздка, как и с чтением любых новостей, это искажение, кажется, что везде так и этого много. Поэтому я считаю своим долгом ассенизировать эту кучу плохих историй, убеждений и страшилок. И поделиться своей реальностью. Поэтому я стараюсь почти не читать эти чаты 😎 А еще, я не люблю мыслить ограничениями, а наоборот – предпочитаю мыслить возможностями. А многие из них не исчезли. Работу сейчас действительно искать дольше. Нужно затратить больше ресурсов, чем раньше. Нужно видоизменить свои старые стратегии поиска и даже где-то быть более находчивым и креативным. Уже недостаточно просто выложить резюме и к тебе повалят толпами HR. Я сама скучаю по этому времени😠 Сейчас нужно уметь выигрышно подавать свой опыт в резюме, цеплять своими сопроводительными. Буквально красиво продать свой опыт. Также задействовать другие места поиска работы: рекомендации, LinkedIn, хабр карьера, тг-каналы, искать прямые контакты HR. А еще нужно уметь показать реальную скилуху на собесе. Вот эти вот system design секции, практические кейсы и замудренные вопросики. Для этого нужно хорошо знать техническую базу СА и БА. И это не просто теорию выучить (как раньше), а уметь проектировать API и структуры БД на ERD, проектировать взаимодействие систем. Сейчас редко встречается, когда работодатель идет на уступки и дает доучить уже на практике что-то, им уже не нужны такие сотрудники, а нужны сразу укомплектованные всеми нужными знаниями и опытом на практике. Выигрышным преимуществом будет умение мыслить находу, адаптироваться к изменяющимся условиям задач и не замыкаться, если что-то не получается. Поэтому найти работу аналитиком в 2026 года безусловно можно, но нужно тщательно к этому подготовиться: 1. подтянуть техничку: приобрести опыт и отточить практику в интеграциях, архитектуре, БД. Если не знаете, где подтянуть техничку, то вы знаете, к кому идти🙂 2. красиво подать свой опыт в резюме, сопроводительном и при рассказе о себе на собесах 3. расширить список мест для поиска работы Всем офферов ❤️

НЕочевидные ошибки при проектировании REST API, которые я регулярно вижу на проектах Тут не будет очевидных вещей типа "используйте не только POST метод", "называйте ресурсы во множественном числе", "делайте валидацию". Я прошла афганскую войну 15+ проектов и провела уже 5 потоков интенсива REST API и вот действительно неочевидные ошибки, которые встречаются как у "новичков" в этой теме, так и у давно работающих СА. 1️⃣Делать эндпоинты для получения одного-двух атрибутов сущности ❌ GET /deliveries/track-codes GET /deliveries/statuses А что если... Фронту нужен только статус или трек-код заказа Лучше такие эндпоинты не выделять, поскольку они плохо переиспользуются, не масштабируются и непредсказуемы для потребителей. Если предполагаемая "сущность" состоит из 1-2 атрибутов – это, скорее всего, не отдельный ресурс, а атрибут другой сущности. ✅ GET /deliveries GET /deliveries/{id} А если в ответе нужны не все атрибуты, можно решить это через добавление в URL запроса параметра fields. Туда передать названия параметров, которые нужно получить в ответе. GET /deliveries/{id}?fields=trackCode,status А вообще, если нужна большая гибкость, это к GraphQL 😉 REST – это про универсальность. Но исключения возможны: • разные права доступа • тяжёлые расчёты • если нужно сократить объем данных ответа 2️⃣Проектировать API от таблиц БД Ключевая ошибка путать логическую или, тем более, физическую модель данных и API-контракт. То, что в БД или доменной модели это отдельные сущности, не означает, что они обязаны быть отдельными REST-ресурсами. Перед выделением ресурса в API задай себе вопросы: Например, в Заказе можно доставить несколько Товаров. • Могут ли Товары создаваться, редактироваться и удаляться отдельно от самого Заказа? • Нужно ли на UI отдельно от Заказа управлять и получать Товары? • Есть ли у Товаров собственный жизненный цикл, отдельные статусы? Если ответы "нет", то тогда Товар будет входить в ресурс Заказа в API. Т.е. будет частью структуры данных Заказа. ❌ GET /orders/{id}/goods GET /orders{id} ✅ GET /orders{id} REST API проектируется от потребностей клиента. С тебя 🔥 и выйдет вторая часть 🫢

Год "спасибо, что живой" Долго думала, публиковать этот пост или нет. Потому что уже 20-е числа января, а это про итоги 2025 года. Еще пост получился глубокий и некоторые вещи я не озвучивала здесь до этого. Но подумала, а чем черт не шутит. В интернетике я видела много итогов года. Большинство были про то, как много удалось достичь: про купленные хаты и тачки, посещенные страны, запущенные потоки курсов с кучей участников и СУММЫ заработанных денег. Но какой ценой это достигалось, остается за кадром. Поэтому мне очень понравился тренд, где люди говорят и о том, где не удалось. А отдельные смельчаки даже рассказали о том, как себя чувствовали, в особо сложные моменты. 2025 год для меня был годом, когда я была счастлива: в личной жизни, в моем деле – обучении. Часть года я даже не работала в найме и это было высшее чувство свободы 😎 Я полностью была погружена в моё любимое дело. 8 моих менти получили офферы, я выпустила 2 потока интенсива rest api на 25+ человек, да еще и перевела его на платформу для обучения, запустила новый интенсив по асихрону. А еще я обрела свое место – маленький уютный офис – и обустроила его. В это время было до жути страшно, перманентно. Доход был нестабильный и хоть подушка безопасности была хорошая, меня всё равно частенько била под дых тревога и желание вернуться в найм в «стабильность». Однако несмотря на всё это, я реально кайфовала. Но потом всё пошло по 3.14зде: в августе на фоне жизненных обстоятельств вне моей власти меня ударил жесткий личный кризис. Я растеряла свой былой запал и продуктивность, действия давались туго. Сил и смелости на развитие бизнеса просто не осталось, было тяжело выдерживать неопределенность (из коей сшита концепция бизнеса), поэтому я вернулась в найм 😬 Но договорилась с собой, что я не брошу обучать и буду продолжать, просто в своем темпе. Поэтому новому потоку интенсива rest api быть и скоро. Во мне была детская надежда, что вот пробьют куранты и всё пройдет: всё то бессилие, боль и потерянность. Новый год – чистый лист. Но… Ah shit, here we go again. Любой кризис, какой бы он болезненный ни был, повод узнать себя лучше, научиться заботиться о себе, отпустить то, что уже изжило себя и найти что-то новое и более подходящее. В новом году хочется объединять людей вокруг и создавать среду, где можно найти поддержку и понимание. И, конечно, впереди много планов на запуски интенсивов и даже новых курсов. Так и поддерживаю себя и, возможно, кого-то еще поддержу этим постом. У каждой истории есть год спустя 💙

История о том, как я ворвалась в СА с двух ног и споткнулась о первые задачи по интеграциям Я тогда только нашла работу системным аналитиком (до этого была чисто по бизнесу). Раньше был не очень популярен system design на СА интервью, поэтому моё хорошее знание теории пустило пыль в глаза и мне сделали оффер. Моя радость длилась не долго, ведь пришло время показать все свои отсутствующие скилы и описать новую интеграцию с какой-то сторонней системой. Открываю доку от вендора, а там 100 страниц какой-то непонятной дичи, столько же API эндпоинтов и еще куча инфы для разработчиков на половину состоящей из неведомых для меня тогда слов🗿🗿🗿 Когда прошел мой первый шок, я начала паническое перелистывание всего, пытаясь выудить хоть что-то полезное. Выхлопа это особо не дало. Следующая попытка поискать по ключевым словам – тоже. Ведь я еще даже не знаю, что именно мне нужно. Дальше я решила пойти в лоб – начала детально изучать каждый эндпоинт и помечать, что он делает. На это я убила бессонную ночь. А руководитель уже писал любимое "что там по задаче?". Помню, тогда я много курила🚬 И вот я, поспавшая пару часов, приношу свои наработки и получаю: «так тут вроде не этот эндпоинт надо было вызывать, а что тут за данные какие-то странные передаются, у нас таких в системе нет». И иду переделывать. А за этой задачей дают новую и этот круг страданий и хауса запускается по-новой. Тогда еще не было AI, хотя сейчас они тоже не особо сильно помогают. Ты им доку, а они тебе – несуществующие эндпоинты и какие-то левые параметры 😫 Только после того как я на собственной шкуре прогнала 5+ интеграций, я осознала, что оказывается дока не такая уж и разная и в ней есть общие паттерны. А искать все нужное можно быстрее и легче, пропуская при этом стадию паники. Через 10 интеграций я уже могла зайти в доку и сразу сориентировать, где находится нужная мне информация. Сейчас уже обычное дело сходу зайти в любую API спеку и в онлайне найти, где описан подход к авторизации, нужные мне эндпоинты и описание моделей данных. Если бы я тогда в самом начале выделяла время не просто на теорию по интеграциям, а ещё и на проектирование хотя бы придуманных кейсах, мне бы не пришлось испытывать как минимум половину всех тех непередаваемых ощущений. Поэтому я топлю за то, чтобы как можно скорее идти и делать что-то руками. Можно взять открытые API (хоть здесь) и начать изучать документацию, развивать насмотренность и находить общие паттерны, потом накидывать описание интеграции. И так с каждой новой докой будет приходить все больше уверенности и скорости. Это не учится в теории. В моем случае – через стресс, боль и ошибки на реальных задачах. А в вашем может быть по-другому: практикой на учебных кейсах, где в спокойных условиях в какой-то момент придет понимание, что ты где-то это видел, и сформируется картинка в голове.

Как выжить среди токсиков 🐍 Год Змеи подходит к концу, поэтому давайте обсудим ядовитых токсичных коллег, и как выжить в этом мире дикой природы. Я убедилась, что самое главное на любой работе – это люди. Каким бы интересным ни был проект и как классно бы там ни были выстроены процессы, если в команде есть токсичные люди, оттуда хочется бежать. Там много злости, тяжело и дико тошно 🌟 Даже один индивид может отравить жизнь целой команды. Поэтому мое скромное мнение, как руководителя, – таких людей надо сразу же УВОЛЬНЯТЬ. Даже если он сто сиксилионов лет в проекте и перформит как боженька. Почему так категорично? Когда я только ступала на путь лида, я на своем горьком опыте убедилась, что любые разговоры не помогают. Договариваемся, человек обещает пересмотеть свое поведение, даже иногда происходят какие-то кратковременные улучшения, но в конечном итоге он вовращается в свое привычное агрегатное состояние. Едкие шуточки, подколки и сарказм, постоянная критика и обесценивание, перепады настроения и даже открытая агрессия, распространение слухов и обсуждение других за их спиной. Нужно принять, что взрослых людей не изменить, если они сами того не захотят. А пока мы пытаемся бороться с ветряными мельницами, хорошие люди покидают команду. А что если я не руководитель и у меня нет полномочий махать шашкой? Для начала надо не игнорировать такое поведение: собирать кейсы и эскалировать на руководителя. Если нападки идут в вашу сторону, найдите контакт со своей злостью и пробуйте защищать себя. Может получаться не сразу, но в такой атмосфере попыток много 😬 Защита может быть в любой приемлемой для вас и для других коллег форме: говорить, что вам не приятно с просьбой прекратить или отвечать той же монетой, для этого придется влиться в образ 🤡 Но я для себя вывела более простую формулу – просто уйти. Если не готова так сразу, хотя бы начать планировать увольнение: обновить резюме, подтянуть знания, начать проходить собесы. Потому что оставаясь с такими людьми, тратиться очень много сил. И расходуются они не на работу, а на злость и раздражение, на подавление своих реакций, на размышления о том, как же реагировать на выпады такого человека и что же он еще может выкинуть. Как следствие – обессиленность, прокрастинация и выгорание. И вот вроде ничего за рабочий день не сделал, а уже чувствуешь себя выжитым как лимон. Желаю в Новом году оставить таких людей в прошлом 😉

Сделать +50% к зарплате на рынке игнора Эти мертвые вакансии на hh, по которым никто не отвечает, и HR, которые пропадают после интервью, – это наши реалии сейчас. Но даже с этими палками в колесах можно смело разогнаться и найти себе шикарную работу, как это сделала моя менти Ксюша. Цели ▪️огромное желание поменять работу с повышением дохода на удаленке ▪️научиться подавать свой опыт в резюме и самопрезентации на собесах ▪️нарастить уверенность в своих текущих знаниях и навыках Что мы сделали 🔸подтянули техничку на реальных кейсах по главным темам СА: интеграции (api, брокеры и др.), БД и архитектура 🔸оформили продающее резюме, которое само приводило HR в личку к Ксюше 🔸научились классно проходить system design часть собеса, выигрышно подавать свой в самопрезентации и отвечать на каверзные вопросы Результаты ⭐️ +50% к зарплате ⭐️ смена домена с e-commerce на финтех в крупный банк ⭐️ полная удаленка и возможность работать по всему миру ⭐️ крепкие технические знания по всем главным темам СА ⭐️ уверенность на собесах и в своем опыте Собесы проходить, конечно, уметь надо, это навык, который можно и нужно развить. Но все-таки без классных знаний технички никуда. Вот прошел ты собес всеми правдами и неправдами и казалось бы, самое сложное позади. Но дальше ещё работать придется 😬 Чтобы удержаться на работе и закрыть испыт, нужны реальные знания и опыт. Поэтому мы с менти сначала прокачиваем нужную теорию, решаем реальные кейсы по интеграциям и архитектуре и делаем пет-проекты, и только потом учимся это красиво подавать на собесах. #отзывы