❓Как часто менять работу мидлам?

Сегодня разберем мидлов:

Сколько сидеть на одном рабочем месте?
Какой апгрейд по деньгам возможен на рынке?
Плохо ли, если кандидат "вечный мидл"?
Когда переходить в синьоры?

⚠️ Опираюсь исключительно на свой опыт, наблюдение за коллегами и общение с HR, поэтому ваш опыт может отличаться :)

P.S. Там выше голосовалка за тему занятия 11.07, завтра в 12:00 подведу итоги и в 16:00 открою запись 👆

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️ 11.07 REST API ❗️

Запись будет открыта сегодня в 16:00 МСК

Тема: Проектирование REST API.
Уровень: junior.
Требуемые навыки: Умение читать ER-диаграмму.
Кол-во участников: до 4.
Длительность: ~4 часа.
Программа:
✅ Форматы данных;
✅ HTTP-методы и их свойства;
✅ REST и RESTfull;
✅ Обработка ошибок в синхронных интеграциях.

Практика:
✅ Проектирование REST API для нового сервиса;
✅ Внедрение пагинации и фильтрации;
✅ Swagger;
✅ Postman.

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

✅ Запись открыта ✅

11.07 12:00 МСК Проектирование REST API

Для записи жмите сюда 👈

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❓Что там у синьоров со сменой работы?

Сегодня на очереди синьоры, самая неоднозначная категория, на мой взгляд :)

⚠️ Опираюсь исключительно на свой опыт, наблюдение за коллегами и общение с HR, поэтому ваш опыт может отличаться :)

Предыдущие части:
🔸Где эффективно искать работу?
🔸Какие харды необходимы?
🔸Как часто менять работу джунам?
🔸Как часто менять работу мидлам?

P.S. Запись на REST API 11.07 открыта тут 👈

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️Тема занятия 12.07❗️

А давайте пока выберем тему занятия 12.07 (воскресенье), голосовать будем до понедельника:)

Описание программ:
🔸REST API;
🔸Базы данных (с нуля);
🔸Базы данных (middle);
🔸Брокеры сообщений;
🔸Функциональные требования;
🔸Event-Driven Architecture;
🔸Нотация С4;
🔸System design.

❓Для тех, кто не понимает, о каких интенсивах речь, рассказал тут.

❗️Как и всегда: голосуйте, только если сможете посетить занятие❗️

Почему это важно?
Ваш голос может решить исход голосования, при этом места останутся пустыми, и меньше людей получат новые знания 🥺

Опрос ниже👇

❗️12.07 Event-Driven Architecture❗️

✅ Запись будет открыта сегодня в 16:00 МСК ✅

Уровень: Middle+.
Требуемые навыки: Понимание принципов работы распределённых систем, Apache Kafka.
Кол-во участников: до 4.
Длительность: ~4 часа.
Программа:
✅ Немного общей теории по распределенным системам;
✅ Что такое "событие";
✅ Что такое EDA;
✅ Сильные и слабые стороны EDA;
✅ Модели данных для EDA;
✅ Мониторинг в EDA.

Практика:
✅ Проектируем EDA систему с нуля;
✅ Готовим схему расположения сервисов;
✅ Расширяем функционал системы с использованием имеющихся событий;
✅ Внедряем в систему мониторинг.

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

✅ Запись и анонс ✅

Запись на занятие по Event-Driven Architecture 12.07 12:00 МСК открыта!

Для записи жмите сюда 👈

Предыдущий разбор кейса из практики вам, вроде как, зашёл🎉

Поэтому завтра выйдет следующий!

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

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

Будет большое видео со схемой и разбором 🫡

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️Ещё один разбор технического кейса❗️

В этот раз получение документов из системы партнера в реальном времени внутри закрытого контура.

Без склеек, все рассуждения и развилки решений есть в видео.

Получилось достаточно объемно, посмотреть можно:

📹 На youtube
🔝 VK без VPN

У нас, кстати, REST и событийная архитектура в эти выходные, слоты ещё есть:

11.07 REST API
✅ 2 свободных места ✅

12.07 Event-Driven Architecture
✅ 3 свободных места ✅


🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❓На очереди архитекторы :)❗️

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

⚠️ Опираюсь исключительно на свой опыт, наблюдение за коллегами и общение с HR, поэтому ваш опыт может отличаться :)

Небольшой оффтоп на эту тему:

Я уже говорил ранее и скажу ещё раз, что нет ничего страшного и сложного в переходе из senior системного аналитика в архитекторы. Поэтому, если вас посещают мысли "я не потяну" и т.п., гоните их и пробуйте. А если сомнения не проходят, пишите мне, развеем:)

Предыдущие части:
🔸Где эффективно искать работу?
🔸Какие харды необходимы?
🔸Как часто менять работу джунам?
🔸Как часто менять работу мидлам?
🔸Что там у синьоров со сменой работы?

А ещё на интенсивах много мест, приходите качать харды в выходные, следующие занятия смогу провести только во 2-й половине августа 😐

✅11.07 REST API
✅12.07 Event-Driven Architecture

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

🌟Да будет холивар 🌟

Предвижу, что за этот пост мне знатно прилетит, но я обещал его сделать, поэтому вот он 😎

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

Без классического видеоформата, потому что в тексте можно нагляднее сравнить.

Дабы не дублировать строчки, писал только в сторону усложнения от грейда к грейду.

Ну что ж поехали... 💫

Стажеры
Тут все очень просто, делать самому с нуля, скорее всего, ничего не придётся, поэтому будет достаточно:

🔸Понимать, кто вообще такой аналитик и его роль в команде;
🔸Уметь читать схемы в базовых нотациях, чтобы проще было погружаться в проект;
🔸Понимать разницу между клиентом, сервером и базой данных;
🔸Отличать FE и BE разработчиков друг от друга;
🔸Иметь представление о популярных форматах (json, XML).

Джуны
Как показывает мой опыт, любое профильное образование поможет вам зайти сразу сюда, минуя ступеньку стажёра:

🔸Уметь внятно описывать сценарии работы системы, не важно в каком формате;
🔸Моделировать схемы в базовых нотациях (UML, BPMN). Касательно UML, сильно не упарывайтесь, будет достаточно ER, Sequence и в редких случаях use-case, ещё реже может пригодиться data flow;
🔸Отличать аутентификацию от авторизации и понимать, зачем они нужны;
🔸Понимать, что такое REST API, уметь проектировать с нуля новые эндпоинты, а также понимать, чем HTTP-методы отличаются друг от друга;
🔸Чуть-чуть знать о брокерах сообщений, достаточно понимания на уровне "черного ящика";
🔸Если говорить о базах, то будет достаточно понимания реляционных СУБД (связи и типы данных, без усложнения) и написания простых SQL-запросов на уровне join.

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

🔸Проектирование отдельных сервисов системы с нуля, без глубокого погружения в архитектуру;
🔸Для этого сервиса спроектировать интерфейсы (REST, gRPC и тп);
🔸Понимать отличие JWT от API KEY;
🔸Если есть работа с брокерами, то описать, что, как и в каком формате;
🔸Работу брокера, который используется на проекте, желательно знать поглубже, хотя бы на уровне балансировки сообщений;
🔸Проектировать модели данных с нуля для отдельного сервиса;
🔸SQL на уровне понимания FWGHSOL и написание простых запросов для анализа, без всяких оконных функций, хранимых процедур и тд;
🔸Уметь читать и править С4.

Синьоры
Когда ты почти архитектор, но ещё не принял этого:

🔸Подготовка архитектуры с нуля целых модулей (несколько сервисов) существующей системы со всеми вытекающими;
🔸Проектирование интеграций уже превратилось в рутину, независимо от технологии и способа;
🔸Помимо глубокого понимания устройства брокеров вашего проекта, неплохо понимать, в каких случаях применять нативные коннекторы и тп;
🔸Есть опыт работы и проектирования различных баз под разные задачи (OLAP, кеши, графы и тд);
🔸К теме работы с данными ещё круто понимать, что такое CDC и когда его применять;
🔸Балансировка нагрузки, многопоточность, прокси, CDN — не просто фоновый шум в созвонах, а понятные инструменты;
🔸Описание всего этого хозяйства в С4, желательно в DaC формате.

Архитекторы
Тут всё ещё проще, чем у стажёров: "Всего побольше и можно без хлеба"

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

Отдельное внимание хочу обратить на то, что нигде не писал про "самостоятельность", "принятие решений" и тд. Я считаю, что человеческий фактор присутствует на всех грейдах, поэтому хоть стажеру, хоть архитектору обязательно нужно ревью от коллег и взгляд со стороны 🔍

А размазывать ответственность "коллективными решениями" — это вообще мёд 🍯

Ваш опыт и матрицы компетенций внутри компаний 100% могут отличаться, буду рад, если поделитесь в комментариях, обсудим 👍

Про использование ИИ специально не написал, расскажу отдельным постом :)

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

🤖 Так ли важно уметь работать с ИИ? 🤖

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

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

В вакансиях все чаще встречается требование к наличию опыта работы с условными Claude, Perplexity и т.п.

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

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

И лишь малая часть коллег ответила, что активно рисуют с помощью ИИ диаграммы, готовят документацию и проводят код-ревью.

Важно отметить, что именно эти люди чаще других отмечали несовершенство отдельно взятых технологий 🫂

Лично я считаю, что любой навык лучше, чем отсутствие такового (ваш капитан😎).

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

Хочу отметить, что сами нанимающие менеджеры и HR не всегда это понимают, поэтому часть кандидатов действительно отсеивают из-за отсутствия таких скиллов в резюме.

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

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

Я отношусь к ИИ как к джуну, который никогда не устает, никогда не ударит вас по пьяни (да, ещё одна отсылка к терминатору🔥), никогда не выгорает и с радостью ныряет в новую задачу, но с невозмутимой уверенностью косячит при каждом удобном случае.

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

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

Буду рад, если поделитесь своим опытом использования подобных инструментов в комментариях👇

I'll be back... 👍

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❓GET с телом?❓

Неожиданно появился новый HTTP-метод ⁉️

Без преувеличения можно сказать, что такое случилось впервые в этом тысячелетии.

Да-да, сам в шоке, мне на консультации рассказали пару дней назад, решил вынести это дело в массы.

Метод был назван QUERY, и представляет собой GET с телом, такие вот дела.

Привет всем адептам отправки тела в GET 🤦‍♂

Остальные свойства аналогичны. Вот небольшое сравнение методов, заодно и память освежить поможет:

⚠️ Все свойства описаны для классического варианта применения методов!

GET:
✅ Безопасный;
✅ Кешируемый;
✅ Идемпотентный;
❌ Не определена симантика тела.

POST:
❌ Небезопасный;
❌ Некешируемый;
❌ Неидемпотентный;
✅ Определена симантика тела.

QUERY:
✅ Безопасный;
✅ Кешируемый;
✅ Идемпотентный;
✅ Определена симантика тела.

Таким образом, больше не нужно делать POST /search, чтобы передать сложную структуру фильтра.

Почему это удобно и все остальные мысли на тему появления нового метода изложил в видео, обязательно послушайте 👆

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

А как вам подобные нововведения? 😉

P.S. Подробную документацию можно почитать в самом RFC.

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️Очередная задачка с собеса❗️

В этот раз разобрал задачку по System Design, которую дали ученику во время интервью на позицию Solution Architect ↗️

Она достаточно простая, поэтому запросто может прилететь и на позиции senior СА, так что обязательно посмотрите.

Чем примечательна задача?

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

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

Простыми словами, умение "Не усложнять там, где не нужно".

▶️ Посмотреть на youtube

Если у вас остались вопросы, обязательно задавайте их в комментариях, обсудим👇

P.S. ВК очень криво работает, особенно с загрузкой видео, а ещё там шакалье качество почему-то. После бесчисленного количества попыток загрузить новый разбор туда, принято решения оставить эту идею 🙃

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️Интенсивы августа❗️

Как вы могли заметить, я долго не выкладывал расписание занятий августа. Это было связано с некоторым непониманием своего графика 🙃

❓Для тех, кто не понимает, о каких интенсивах речь, рассказал тут.

В августе смогу провести только один интенсив 15.08 (суббота) в 12:00 по МСК, предлагаю сразу выбрать тему, опрос, как всегда, ниже 👇

Описание программ:
🔸REST API;
🔸Базы данных (с нуля);
🔸Базы данных (middle);
🔸Брокеры сообщений;
🔸Функциональные требования;
🔸Event-Driven Architecture;
🔸Нотация С4;
🔸System design.

❗️Как и всегда: голосуйте, только если сможете посетить занятие :)

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️15.08 System Design❗️

System Design впереди с большим отрывом, думаю, что тянуть с голосованием смысла нет:)

✅ Запись будет открыта сегодня в 17:00 МСК ✅

Когда: 15.08 12:00 МСК
Уровень: Middle.
Требуемые навыки: Понимание принципов работы распределённых систем, брокеры сообщений, базовые отличия СУБД.
Кол-во участников: до 4.
Длительность: ~4 часа.
Программа:
✅ Все этапы решения задач;
✅ Общие паттерн system design;
✅ Мои лайфаки по проектированию :)

Практика:
✅ Проектируем простую систему (аналог задач с собеседования);
✅ Проектируем различные модули одной большой системы;
✅ Совместно с другими участниками проектируем интеграции модулей друг с другом.

P.S. Слоты на эту тему обычно быстро разбирают😉

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

✅ Запись открыта ✅

15.08 12:00 МСК System Design

Для записи жмите сюда 👈

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️CDN на пальцах❗️

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

Постарался очень коротко и понятно рассказать, что такое Content Delivery Network и для чего он нужен🫡

Да простят меня инфраструктурные магистры за такое упрощение☹

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

Ставьте жабу 🐸, если тоже считаете, что так удобнее.

P.S. А больше кастомных реакций я добавить не могу, поэтому, если такой формат хуже, то пишите комментарий :)

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❓Когда CDN не нужен?❓

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

В видео рассказал, в каких случаях CDN не просто будет бесполезен, а может навредить вашему проекту.

P.S. Главная мысль вообще "Не усложнять там, где это не нужно". Подобные моменты касаются не только CDN 😉

🔝 Паблик VK
😀 Системный анализ и архитектура| Дмитрий Помаскин