🔥 Резюме дороже денег 4! 🔥

Заключительная часть вопросов и ответов с Андреем.

1. Какие технические навыки чаще всего спрашивали?

— Чаще всего задавали вопросы про сбор требований, ТЗ, UML-диаграммы и функциональные требования. Особое внимание уделяли интеграциям через REST. По архитектуре интересовались микросервисами и интеграциями через брокеры сообщений, и часто в виде кейса просили набросать верхнеуровневую модель системы.

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

2. Насколько полезной оказалась консультация по подготовке к собеседованиям?

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

3. Сколько предложений ты получил и как выбирал финальную компанию?

— По итогу 22 собеседований получил 3 классных оффера. Выбирал по стеку технологий и специализации — финтех и телеком были в приоритете.

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

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

4. Насколько выросла твоя зарплата по сравнению с предыдущей работой?

— Зарплата стала х2.

5. Какие уроки ты вынес из всего этого опыта?

— Главный урок — необходимость тщательной подготовки и понимания рынка перед началом поиска работы. Если в чём-то есть пробелы — не стесняйтесь обратиться к коучу или ментору. Это реально может ускорить процесс и помочь избежать ошибок.

6. Что ты посоветуешь тем, кто волнуется перед собеседованиями?

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

💬 Вот так Андрей справился с выходом на рынок и получил желаемый оффер. А что помогло вам в вашем карьерном пути? Делитесь в комментариях!

IT АНАлитика

Хорошо поставленная задача есть? А если найду? 🕵️‍♂️: Часть 7 — Архитектор

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

Когда аналитик может поставить задачу архитектору?

🔸 Интеграция нового сервиса — если проекту нужно добавить внешнюю систему или API, аналитик инициирует обсуждение архитектурных решений (если интеграция сложная и влияет на общую архитектуру системы*).

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

🔸 Рефакторинг или обновление технологий — когда нужно модернизировать устаревшую инфраструктуру без риска для текущих процессов.

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

Что важно учитывать при постановке задачи архитектору?

1. Контекст и бизнес-цели🚶‍♂️
Архитектору нужно понимать не только технические аспекты, но и бизнес-цель. Например, если задача — повысить производительность системы или выйти на новые рынки, эта информация поможет выбрать правильное архитектурное решение.

2. Текущая инфраструктура и ограничения☺️
Архитектор должен знать, что уже есть в проекте и какие ограничения или зависимости могут повлиять на его решение. Если в системе есть узкие места или легаси-компоненты — укажите это.

3. Технические и нефункциональные требования🤨
Задача архитектора — спроектировать систему, которая будет не только работать, но и отвечать требованиям производительности, безопасности и надёжности.
Пример: «Интеграция должна поддерживать 10 000 запросов в минуту, шифрование данных и резервные копии в режиме реального времени.»

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

5. Сроки и приоритеты😡 куда же без них
Как и другим специалистам, архитектору нужно знать сроки и приоритеты задачи.
Пример: «Архитектура должна быть готова к концу месяца, так как интеграция критична для следующего релиза.»

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

А как часто вы взаимодействуете с архитекторами? Есть ли вообще у вас архитекторы? Делитесь опытом в комментариях! 👇

Да, было📞


IT АНАЛитика

Хорошо поставленная задача есть? А если найду? 🕵️‍♂️: Часть 8 — DevOps

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

Когда аналитик может поставить задачу девопсу?

🔸 Создание сертификатов для интеграции
Для некоторых интеграций сертификаты необходимы не только для безопасности, но и для корректной работы соединений. Если требуется подключение к стороннему сервису с использованием сертификатов — это задача девопса в инструкции к интеграции обычно пишут о необходимости сертификатов

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

🔸 Создание CI/CD пайплайна для микросервиса
При появлении нового микросервиса девопсу часто нужно создать CI/CD пайплайн, который будет автоматически деплоить и тестировать сервисы. Это помогает ускорить разработку и снизить риск ошибок.

Что важно учитывать при постановке задачи девопсу?

1. Контекст задачи и цель
Девопсу важно знать не только "что" нужно сделать, но и "зачем". Например, задача может звучать так: "Создать сертификаты для интеграции с внешним сервисом, чтобы обеспечить безопасное соединение и соблюдение требований безопасности."

2. Текущая инфраструктура
Если есть специфические ограничения, существующие системы или архитектурные особенности, девопс должен знать об этом заранее. Пример: "У нас уже работает существующая Kafka, но нужен новый кластер для потоковой обработки данных."

3. Сроки и приоритеты
Сроки в таких задачах — один из ключевых моментов. Например: "Нужно завершить настройку конфигурации для Nginx до конца недели, чтобы успеть протестировать систему перед релизом."

Хотя аналитик не всегда взаимодействует с девопсом напрямую, задачи, связанные с инфраструктурой, интеграцией и безопасностью, часто требуют тесного сотрудничества. Четко сформулированная задача ускоряет процесс и делает работу более эффективной.

А вы часто ставите задачи девопсам? Делитесь опытом в комментариях! 👇

Нас стало больше! 😎
Для всех новеньких и тех, кто пропустил, вот, что можно почитать на канале:

Профессиональный рост и эффективность💼:
Как эффективно решать проблемы в IT: 10 шагов для начинающих аналитиков
Как получить оффер на 180к с помощью ChatGPT?
Дорожная карта тимлида
Нужен ли аналитику SQL?
Всё, что нужно знать про SQL

Введение в IT для начинающих🖥:
У России три пути и один из них IT Часть 1
Резюме дороже денег
Резюме дороже денег 2
Резюме дороже денег 3
Резюме дороже денег 4

Работа в IT📞:
Хорошие и плохие компании
Да кто такие эти ваши Agile, Scrum и Kanban
Возраст в IT: препятствие или преимущество?
Как определить, подходит ли тебе компания?
Интеграции мои интеграции
Про работу с требованиями

Коммуникация и обратная связь🗣:
Качественная обратная связь: Часть 1
Качественная обратная связь: Часть 2

Постановка задач в IT📝:
Хорошо поставленная задача есть? А если найду? : Часть 1 - Почему важно
Хорошо поставленная задача есть? А если найду? : Часть 2 - Общий шаблон задач
Хорошо поставленная задача есть? А если найду? : Часть 3 - Frontend
Хорошо поставленная задача есть? А если найду? : Часть 4 - Backend
Хорошо поставленная задача есть? А если найду? : Часть 5 - Тестировщик
Хорошо поставленная задача есть? А если найду? : Часть 6 - Дизайнер
Хорошо поставленная задача есть? А если найду? : Часть 7 - Архитектор

Так же не забудьте посмотреть все посты под хэштегом #поддержка

IT АНАЛитика

Хорошо поставленная задача есть? А если найду? 🕵️‍♂️: Часть 9 — Аналитик

Итак, финал… правильная постановка задачи для аналитика:

А никак. Достаточно лишь небольшого заголовка и аналитик сам, как цепной пес возьмет след и все разузнает по задаче😂

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

История о том, как HR смог перейти в системные аналитики! Читать📖

Честно, не представляю, каково это — вкатиться в аналитику без техбэкграунда⚰️.

А как у вас?
Если тоже вкатывались, как гуманитарий и смогли освоиться, делитесь своими историями в комментариях — интересно, как прошёл ваш путь!☠️

Виды АНАЛитиков💬

Когда меня спрашивают, кем я работаю, я обычно отвечаю: «Аналитик». Если человек не из IT, объяснять, что ты системный аналитик, и бизнес-аналитик, да и вообще-то фулстак, ноооо и еще частично задачи дата-аналитика выполняешь — душно.

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

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

1. Системный аналитик 🔍
Лучший друг команды разработки. Он всегда знает, как надо делать. Отлично понимает, как устроена система изнутри, и делает так, чтобы весь новый и старый функционал работал четко. Так же анализирует требования, создает документацию и иногда общается с бизнесом. Роль для тех, кто не боится «покопаться в кишках» системы и всегда ищет, как улучшить её работу.

2. Бизнес-аналитик 🤝
Правая рука бизнеса. Он всегда знает, что надо делать. Собирает требования, описывает процессы, глубоко погружен в работу компании. Похож на системного аналитика, но без глубокого погружения в технические детали. Человек, который переводит хотелки бизнеса в понятные для команды задачи.

3. Фулстак аналитик 😆
Человек-оркестр. Знает, что и как делать на проекте. Держит всё под контролем, в равной степени общаясь с бизнесом и разработкой. Такой аналитик совмещает в себе роли системного и бизнес-аналитика, а иногда и других.

Чаще всего эдакий универсал — мечта любого работодателя. Даже если в вакансии написано другое ищут всегда его.

"А почему бы не взять и системного, и бизнес-аналитика?" — спросит юный читатель

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

4. Дата-аналитик (Data Analyst)🤓
SQL-мастер и гуру отчётов. Его задача — собирать, обрабатывать и анализировать данные, чтобы бизнес мог видеть реальные цифры и принимать решения по своим задачам. Работает с SQL, Excel, BI-инструментами и превращает данные в красивые картинки.

5. Продуктовый аналитик🍎
Сосредоточен на продукте и пользователях. Исследует, как продукт используется, анализирует метрики и помогает команде понимать, что улучшить. Главный кореш продуктовых команд, который помогает принимать решения на основе данных.

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

6. Data Scientist 🤖
Киборг-убийца, который выходит за рамки обычного анализа данных. Строит прогнозные модели, работает с ML и помогает компании видеть будущее. Это роль для тех, кто не боится математики и любит моделей данных🥰

Узнали? Согласны? Делитесь в комментариях, какой путь выбрали и почему.

IT АНАЛитика

🔤🔤🔤🔤🔤: что это и зачем знать аналитикам?

В последнее время всё чаще слышу от разрабов фразы вроде: «Ну мы дергаем их фейн…», «Там фейн запросы делает…». Кажется, что в контексте диалога всё понятно — особенно когда тебе шарят экран и вы обсуждаете задачу.

Но если попытаться объяснить своими словами, выходит что-то вроде: «Ну, это такая штука в коде…» 🤔

Давайте разберёмся, что же такое Feign на самом деле, как он работает и почему о нём стоит знать.

Что такое Feign?
Feign — это декларативный HTTP-клиент для Java, который придумали в Netflix, чтобы упростить взаимодействие с RESTful веб-сервисами. С Feign можно написать пару строк кода вместо полноценного запроса, оставляя остальную логику библиотеке. Всё делается через аннотации в интерфейсах, так что работать с внешними API становится намного проще.

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

@FeignClient(name = "credit-history-client", url = "https://api.creditcheck.com")
public interface CreditHistoryClient {

    @GetMapping("/history")
    CreditHistoryResponse getCreditHistory(@RequestParam("userId") String userId);
}

Здесь FeignClient указывает базовый URL, а GetMapping настраивает конкретный запрос. Теперь, чтобы узнать кредитную историю клиента, достаточно вызвать метод getCreditHistory() — Feign автоматически сделает всю работу за кулисами.

Зачем это знать аналитикам? 🤔
✅Во-первых, чтобы быть в одной плоскости с разработчиками и лучше понимать, как работают интеграции между системами.

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

А вы сталкивались с Feign в своей работе? Часто ли вообще приходится смотреть в код? Делитесь опытом в комментариях👇

И снова здравствуйте💋

Если кто-то не знает, когда-то давно я работал в тех.поддержке и с тех времен осталось много рофлов пользователей. Их можно посмотреть под тэгом #поддержка

IT АНАЛитика

Тут на примерах с кодом объясняют, что такое микросервисы для аналитиков.

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

Ознакомиться📕

🔤🔤🔤🔤🔤🔤🔤🔤🔤: что это и зачем?

В продолжении поста про Feign, есть ещё одна вещь, о которой стоит знать аналитикам — ConfigMap. Если вы работаете с проектами, где используется Kubernetes, то наверняка слышали фразу: «Эта настройка лежит в конфигмапе».

Что такое ConfigMap?
ConfigMap — это объект в Kubernetes, который хранит конфигурационные данные приложения. Это ключевой инструмент для управления настройками, такими как:

➡️адреса API,
➡️ключи доступа,
➡️параметры подключения,
➡️другие переменные, которые могут меняться в зависимости от среды (разработка, тестирование, прод).

Вместо того чтобы "хардкодить" эти параметры в приложении и пересобирать код при каждом изменении, их выносят в ConfigMap. Это даёт возможность обновлять настройки, без остановки работы приложения.

Пример📄
Представьте, у вас есть сервис для отправки уведомлений клиентам. В зависимости от окружения (тест, прод) он должен использовать разные SMTP-серверы для отправки писем. Вместо того чтобы каждый раз менять настройки прямо в коде, эти данные выносят:

apiVersion: v1
kind: ConfigMap
metadata:
  name: smtp-config
data:
  SMTP_SERVER: "smtp.mailserver.com"
  SMTP_PORT: "587"
  SMTP_USER: "noreply@example.com"

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

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

IT АНАЛитика

Иногда конечно бывает смешно, когда в резюме у тебя написано одно, а предлагают совершенно другое😐


IT АНАЛитика

Прибейте меня, я веду проект с нуля. Часть 1🍑

Вы — аналитик, и вам поручили вести новый проект или большую задачу с нуля. Что делать? С чего начать? Объём работы душит, глаза разбегаются, хочется плакать.

Но на самом деле всё не так страшно, как кажется. Недавно на консультации разбирал подобный вопрос, и захотелось сделать серию постов, чтобы разложить всё по полочкам. Let's go🚬

Шаг 1. Первичное погружение 🧐
Хорошо, если у бизнеса есть чёткая постановка. Ещё лучше, если она понятная. И мега кайф, когда он точно знает чего хочет.

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

1. Цели проекта: Зачем он нужен бизнесу? Какую проблему решает?
2. Конечные пользователи: Кто они? Что для них важно?
3. Интеграции: Есть ли системы, с которыми проекту нужно взаимодействовать?

Первичной инфой может поделиться человек давший вам задачу, PO или кто-то непосредственно из бизнеса. Главное — не стесняйтесь задавать вопросы, чтобы собрать максимум контекста на старте.

Шаг 2. Заводим раздел под документацию 📂
Документация — ваш главный бро. Организуйте место, где вы будете:

А. Хранить протоколы встреч.
Б. Описывать функционал.
В. Фиксировать все важные детали проекта.

Используйте Confluence, Google Docs или любую другую систему, удобную для всей команды. Главное, чтобы всё было доступно, структурировано и понятно другим участникам проекта.

Шаг 3. Работаем с требованиями 🙅‍♂️
Мы и до этого с ними считай работали, но теперь все серьезно:

🤟Если требования есть:

1. Тщательно изучаем.
2. Ищем пробелы и неясности.
3. Назначаем встречу с заказчиком для уточнений.

😡Если требований нет:

1. Назначаем встречу с заказчиком.
2. Выясняем его ожидания, цели и текущие проблемы.
3. Фиксируем все подряд — иногда неожиданные комментарии становятся ключевыми.

Шаг 4. Доуточняем и согласовываем требования🔫

⭐️Решаем все нерешенные вопросы - лучше потратить время на уточнения сейчас, чем переписывать всё потом.

⭐️Разделите требования на функциональные и нефункциональные, чтобы было проще работать.

⭐️Согласуйте требования с бизнесом просим расписаться кровью.

В следующей части разберём, как выглядит итоговый документ, и что в нём обязательно должно быть.
А как вы начинаете вести проект? Делитесь своим опытом в комментариях! 🧐

IT АНАЛитика

vot blin😵
#поддержка

IT АНАЛитика