Загрузка…
Загрузка…
analyst / junior / tech_deep
Формат
online
Стадия
tech_deep
Когда
within_quarter
Длительность
—
01
Теория
Представьте, что в обучающей системе (LMS) ваша задача — разработать новый модуль. Как бы вы собирали требования на этот модуль и какими артефактами стоит их задокументировать?
Блок 1 — требования и документирование. Follow-up: как именно вы бы описывали бизнес-процесс (ценность, ключевые функции, диаграмма BPMN).
02
Теория
В чём отличие use case (юскейс) от user story (юзер стори) и что лучше работает, в каком случае?
Интервьюер также упомянула job story как то, о чём стоит знать.
03
Кейс
Приведите пример, с чего можно начать составлять user story для пользователя в новом модуле тестирования.
04
Кейс
Заметки
Публичное демо-собеседование на канале Next Way на позицию системного аналитика в Т-Банк. Кандидат — Валерия Синюгина (выпускница финтех-обучения Т-Банка), интервьюер — Зоя Степчева, ведущий — Андрей. Это первый (теоретический) этап из 2-3 частей; вопросы объединены вокруг единой предметной области — обучающая система (LMS) с ролями администратор/преподаватель/студент, интеграциями с видеохостингом и платёжными системами, НФТ: высокая доступность, масштабируемость, до 10 000 студентов одновременно. Структура: 3 блока — (1) требования и документирование, (2) интеграции/микросервисы, (3) базы данных и SQL. Оценка интервьюера: уровень junior; сильная сторона — продуктовый vision и понимание impact на бизнес; зоны роста — нефункциональные требования и их трассировка, способы интеграции, масштабирование и проектирование хранилищ. Кандидат прошла первый этап, предстоит второй этап (проектирование предметной области).
Подготовка
Рекомендации интервьюера: расширять кругозор по способам интеграции систем и оценивать impact решений на нефункциональные требования/архитектуру; разбираться в трассировке требований и форматах их описания (use case, user story, job story); больше практики с разными базами данных — пробовать разные запросы, анализировать планы запросов (EXPLAIN), понимать сканирование таблиц и индексы. В конце собеседования кандидату выдан QR-код со ссылками на материалы по затронутым темам. Для трудоустройства джуна-аналитика в Т-Банк важны: умение проектировать, видеть проблему бизнеса, взаимодействовать и с бизнесом, и с разработкой, владение инструментами (docs, нотации моделирования), умение читать код.
Стиль интервьюера
Доброжелательный, структурированный стиль: интервью разбито на блоки, каждый вопрос сопровождается уточняющими follow-up'ами и наводящими подсказками, когда кандидат затрудняется. Интервьюер подталкивает рассуждать вслух, оценивает аргументацию, даёт развёрнутую обратную связь и резюме после каждого блока, обозначает зоны роста и ставит ориентир по уровню. Поощряет альтернативные точки зрения и дискуссию.
Требования на модуль тестирования от двух групп ролей (преподаватели и студенты) противоречат друг другу. Как бы вы действовали в такой ситуации, как «подружить» стейкхолдеров и что в итоге запишете в артефактах / техническом задании?
Кандидат рассказала про переговоры, версионирование и приоритизацию MoSCoW. Follow-up: как учитывать бизнес-цели и impact на бизнес при приоритизации.
05
Теория
Система должна поддерживать видеолекции через внешний сервис. Какие нефункциональные требования были бы актуальны для такого модуля в данном контексте?
Контекст: нагрузка до 10 000 студентов одновременно. Follow-up: на что повлияет невыполнение требований производительности.
06
Теория
Как сформулировать требование к производительности в цифрах? Приведите пример числового требования производительности.
07
Теория
Зачем регламентировать выполнение требований (зачем стремиться к 100% и максимально регламентировать показатели)?
08
Кейс
Что делать (как «лечить»), если мы не можем уложиться в заданные цифры по производительности?
09
Теория
Перечислите, какие ещё нефункциональные требования (помимо производительности) вы предъявляли к системам или с которыми сталкивались.
10
System design
Если бы вам довелось спроектировать LMS как микросервисную систему, какие ключевые микросервисы вы бы выделили, по какому принципу и как разделили бы их зоны ответственности?
Блок 2 — интеграции. Follow-up: по какому принципу выделены сервисы (кандидат группировала вокруг сущностей/доменов).
11
Теория
Какие ещё существуют способы выделения (декомпозиции) микросервисов, кроме группировки вокруг сущности/домена?
Интервьюер подсказала: по способу масштабирования и вокруг бизнес-задачи.
12
System design
Система поддерживает платежи через внешний шлюз оплаты. Какой тип интеграции стоит выбрать именно в сценариях платежа (синхронный, событийный, асинхронный)?
Follow-up: в чём профит событийно-асинхронной интеграции для бизнеса и с точки зрения доставки ценности пользователю (отложенный доступ к курсу).
13
Теория
Что это за диаграмма (на экране) и для чего нужно рисовать sequence-диаграмму?
Диаграмма сгенерирована ChatGPT через инструмент контура Т-Банка.
14
Кейс
Где на этой sequence-диаграмме есть ошибки на ваш взгляд? (в частности — всё взаимодействие выполнено только в асинхронном виде)
15
Теория
Корректно ли описан процесс аутентификации с учётом того, что у пользователей есть роли? (роли предполагают не только аутентификацию, но и авторизацию/права)
16
System design
Что бы вы поменяли в процессе обновления прогресса студента? (кто инициирует процесс, синхронно/асинхронно, событийно)
Намёк: интеграция должна быть не от студента, а на основе событий в асинхронном режиме.
17
Теория
Доводилось ли вам работать с брокерами сообщений?
Кандидат не работала, только читала — углубление не проводилось.
18
System design
Какие данные стоит хранить в базе по студентам и их активности (просмотры видео, выполнение тестов, завершение модулей)? Предложите структуру таблиц.
Блок 3 — базы данных. Кандидат проектировала таблицы курсы, лекции, просмотры, студенты на стикерах.
19
Теория
Нарисуйте связи между сущностями (просмотры, лекции, курсы, студенты). Какая это связь и как она называется (многие-ко-многим через смежную/pivot-таблицу)?
20
Теория
Помните ли вы про нормальные формы? Сколько их и перечислите первые три нормальные формы.
Интервьюер отметила: количество форм зависит от источника (3 основные, до 6 на Хабре, до 8 в вузовских учебниках).
21
Теория
Реляционная база данных стала демонстрировать снижение производительности при росте числа студентов и масштабировании в разные регионы. Какие шаги стоит предпринять? Что вы знаете про способы увеличения производительности?
Кандидат назвала индексы, кэширование, шардирование. Follow-up: что имеется в виду под «независимыми объектами» при шардировании.
22
Теория
Как работать с шардированной базой данных: при записи (новый курс, новый студент) как определить, в какую из физических баз писать? (ключ шардирования)
Кандидат вспомнила про разделение операций чтения/записи и репликацию, но не про ключ шардирования.
23
Код
Что это за SQL-запрос и для чего он нужен? (создание таблицы студента с первичным ключом, типами данных, ограничениями (CHECK на gender), и INSERT с заполнением данными)
Задание на чтение кода. Поля: student_id (PK), фамилия, имя, email, academic_leave, gender (с CHECK-ограничением).
24
Теория
Для чего нужны индексы, что они позволяют сделать хорошего и что плохого?
25
Теория
По какому полю таблицы студентов поиск по индексу будет самым оправданным? (учитывая уникальность и распределение данных, например academic_leave и gender)
Интервьюер подсказала про partial-индекс для academic_leave (~5%) и неэффективность индекса по gender (50/50).
26
Теория
На что может повлиять индекс — какие операции мы ускоряем, а какие замедляем, навешивая индексы необоснованно на разные поля?
27
Теория
Есть таблица транзакций с большим объёмом данных. Как можно ускорить выполнение аналитического запроса (с агрегациями)?
Интервьюер дополнила: индексы, колоночные базы, партиционирование таблицы по датам.