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

Я ЗАБЫЛА как жить спокойную жизнь 💅💅


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

Во-первых, я не успеваю 💀
И вы свидетели, в канале меня не было больше 2!! месяцев...

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

Последние пару месяцев я была как хомяк в колесе, который разогнался до своей максимальной скорости. Я работаю в найме: управляю целой командой из 10 человек, веду интенсив да еще и параллельно обновляю материалы по нему и записываю видео для учеников, а еще у меня консультации и менторинг для моих котиков, рабочие задачи и активные собесы которых тоже не ждут.

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


Эта аналогия сразу пришла мне на ум, потому что именно так и случилось со мной. Когда активности по обучению завершились, у меня появилось много свободного времени, которое я ЗАБЫЛА, куда и как тратить, и продолжала жить на спидах 😵

Обычно в эмоциональном перегрузе мой отдых выглядит как залипание в рилсы\тредсы\тиктоки. В такие периоды просто ничего другого не хочется и на это нет ресурса.

Понадобился месяц, чтобы вспомнить, какого это, когда не нужно постоянно переключаться между задачами и когда нет кучи непрочитанных сообщений в телеграме. А еще на добивочку: когда после основной работы есть время вечером, где можно НИЧЕГО НЕ ДЕЛАТЬ ✨ по другим своим работам 🥹 И вот через какое-то время, о чудо, у меня появилось ЖЕЛАНИЕ сходить на йогу, почитать книгу, налепить маску себе на лицо и пр. Обычные радости жизни.


Честно говоря, я просто ОХРЕНЕЛА от того, что это можно забыть... КАК? Ведь это как бы базовая фигня.

А потом до меня начало доходить... я пыталась прикрыть зияющую огромную дыру соломкой и надеялась, что это исправится. Я старалась свои перегрузки компенсировать недельным отпуском, простыми выходными, лежанием на диване, прогулками на воздухе. Но этого было мало. Даже те крохи сил, которые мне удавалось накопить, испарялись за первые пару дней работы.

И мои очередные выводы: единственное, что помогает, если ты уже задолбался в край, – это СНИЗИТЬ НАГРУЗКУ на себя и ВСЁ. А еще лучше – быть бережнее к себе ИЗНАЧАЛЬНО и не разгонять своё колесо до невиданных скоростей.

Если месяцами жить в режиме марафона и душить себя запредельными нагрузками уже никакие преславутые восстановления ресурса, ретриты, просто полежи и отдохни✨не помогут. Это будет капля в бездонном море.

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

I'm back ❤️

Не лучшая стратегия для аналитика ждать у моря погоды


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

В такие моменты блаженного неведения и приходят перемены: какая-то новая большая фича, с реализацией которой ты не сталкивался до этого, или компания хочет провести 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 (хоть здесь) и начать изучать документацию, развивать насмотренность и находить общие паттерны, потом накидывать описание интеграции. И так с каждой новой докой будет приходить все больше уверенности и скорости.

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

Как выжить среди токсиков 🐍


Год Змеи подходит к концу, поэтому давайте обсудим ядовитых токсичных коллег, и как выжить в этом мире дикой природы.

Я убедилась, что самое главное на любой работе – это люди. Каким бы интересным ни был проект и как классно бы там ни были выстроены процессы, если в команде есть токсичные люди, оттуда хочется бежать. Там много злости, тяжело и дико тошно 🌟

Даже один индивид может отравить жизнь целой команды. Поэтому мое скромное мнение, как руководителя, – таких людей надо сразу же УВОЛЬНЯТЬ. Даже если он сто сиксилионов лет в проекте и перформит как боженька.

Почему так категорично?

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

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

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

А что если я не руководитель и у меня нет полномочий махать шашкой?

Для начала надо не игнорировать такое поведение: собирать кейсы и эскалировать на руководителя. Если нападки идут в вашу сторону, найдите контакт со своей злостью и пробуйте защищать себя. Может получаться не сразу, но в такой атмосфере попыток много 😬 Защита может быть в любой приемлемой для вас и для других коллег форме: говорить, что вам не приятно с просьбой прекратить или отвечать той же монетой, для этого придется влиться в образ 🤡

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

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

Желаю в Новом году оставить таких людей в прошлом 😉