Что меня поразило в английском, когда я начала работать тех. писателем. Часть 1

⏳ 4 мин | 🟡🟡⚪️

Читать статью | Analyst IT

Как мы храним 20000+ метрик и миллиарды комбинаций разрезов в одной таблице

⏳ 22 мин | 🟡🟡⚪️

Читать статью | Analyst IT

Салют! Сегодня разберем еще один из любимых вопросов от моих подписчиков: «Как пройти техническое собеседование на ИТ-аналитика (системный/бизнес-аналитик): поделитесь опытом или советами»

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

1️⃣ Что проверяют на техническом собеседовании? Для чего вообще его проводят:

Вас будут оценивать по нескольким ключевым направлениям и тут уже не важно какой у вас стаж:

1.1. Понимание процессов разработки

- SDLC (Software Development Life Cycle) – какие этапы, кто за что отвечает. Если уже с опытом, попросят поделиться им и рассказать как было на ваших проектах.

- Методологии (Agile, Scrum, Kanban, Waterfall) – не просто названия, а как они применяются в реальных проектах. Спросят что и для чего выберете вы сами, с чем работали, с чем сталкивались.

- Роль аналитика в команде – взаимодействие с PM, разработчиками, тестировщиками. С чем были трудности, как решали конфликты.

❌ Ошибка новичка: Путать обязанности аналитика и проджект-менеджера.

1.2. Работа с требованиями

- Виды требований (BRS, SRS, User Stories, Use Cases).
- Как писать четкие, нефтогенерящие требования.
- Техники сбора требований (интервью, workshops, прототипирование).

✅ Совет: Будьте готовы разобрать кейс – например, как вы будете собирать требования для нового функционала в мобильном приложении.

1.3. Документирование и моделирование

- Диаграммы (BPMN, UML, ER, DFD) – хотя бы базовое понимание.
- Инструменты (Confluence, Jira, Figma, Miro, draw.io) – если не знаете, скажите, что быстро освоите.

❌ Ошибка новичка: Говорить, что вы "отлично знаете BPMN", но не суметь нарисовать простой процесс. А это точно проверят)))

1.4. SQL и данные (часто спрашивают!)

- Базовый SQL (SELECT, JOIN, GROUP BY, подзапросы).
- Нормализация БД, ключи, индексы – хотя бы основы.
- NoSQL vs SQL – когда что применяется.

✅ Совет: Если не уверены в SQL, потренируйтесь на leetcode.com или sql-ex.ru.

1.5. API и интеграции

- REST vs SOAP.
- Что такое Swagger/OpenAPI.
- Форматы данных (JSON, XML).

❌ Ошибка новичка: Путать PUT и POST в REST API.

2️⃣ Как готовиться к собеседованию?

📌 2.1. Разберите типовые вопросы

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

Пробегитесь по часто-задоваемым вопросам, которые я описывала: Часть 1 и Часть 2

📌 2.2. Практика на кейсах

Вас могут попросить:
- Описать процесс "Оформления заказа" в интернет-магазине.
- Написать User Story для функции "Поиск по фильтрам".
- Нарисовать схему взаимодействия систем.

📌 2.3. Повторите основы
- SQL (хотя бы SELECT + JOIN).
- Протоколы HTTP, методы API.
- Основы тестирования (что такое smoke-тесты, регресс?).

3️⃣ Как вести себя на собеседовании?

🎯 3.1. Говорите структурированно
Используйте метод STAR (Situation, Task, Action, Result) для ответов:
- "Был проект Х, задача Y, я сделал Z, результат – W".

🎯 3.2. Не бойтесь говорить "не знаю"
Лучше честно сказать *"Я с этим не сталкивался, но могу разобраться"*, чем врать.

🎯 3.3. Задавайте вопросы
- "Как в вашей компании строится процесс работы с требованиями?"
- "Какие инструменты вы используете?"
- "Какие сложности бывают в проектах?"

4️⃣ Что делать после собеседования?

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

Вместо вывода:

Главное – практика и уверенность. Даже если не знаете ответ, покажите ход мыслей. IT-аналитика – это не про зазубренные ответы, а про умение разбираться в процессах и доносить идеи.

Источник: @ba_and_sa

Удачи на собеседовании! 🚀 Если есть вопросы – пишите в комментарии👇

Компрессия требований, распад бизнес-логики. Разбираемся, почему архитектура не спасает от эрозии смыслов

⏳ 4 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

От проекта к программе: масштабирование внедрения Camunda в вашей компании

⏳ 18 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

Профиль компетенций команды проекта

⏳ 18 мин | 🟡🟡⚪️

Читать статью | Analyst IT

Эволюция веб-приложения PREMIER: от legacy к современной архитектуре

⏳ 12 мин | 🟡🟡⚪️

Читать статью | Analyst IT

AI в помощь системному аналитику: от скепсиса к практике

⏳ 26 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

Camunda и Flowable — платформы автоматизации процессов и воркфлоу

⏳ 8 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

Семантическое моделирование. Проектирование БД с помощью ER-модели

⏳ 9 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

Основные команды GIT

⏳ 23 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

Docs as Code — это подход к созданию документации, при котором:

- Документация пишется как код (в текстовых форматах: Markdown, reStructuredText, AsciiDoc).
- Хранится в системе контроля версий (Git).
- Сборка и публикация автоматизируются через CI/CD (например, GitHub Actions, GitLab CI).
- Изменения проходят ревью, как код.

📎И небольшая подборка статей на эту тему:

- Docs as Code: введение в предмет
- Инструменты подхода Docs-as-code
- Как перейти на Docs-as-a-Code и какие инструменты для этого использовать
- Docs As Code: Документация как Код

@ba_and_sa

Неработающие принципы Agile. Когда Agile не принесет ожидаемого эффекта

⏳ 6 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

Большой гайд по CJM — зачем, где и как его строить

⏳ 9 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

Передаем документацию заказчику: Markdown, Git, CI/CD и почти полная автоматизация

⏳ 5 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

Headless и API-First: как ускорить e-commerce и не утонуть в монолите

⏳ 6 мин | 🟡⚪️⚪️

Читать статью | Analyst IT