**Собеседование Системный Аналитик | Компания Astion (2026) — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/system-analyst-interview-astion-company-2026/

Разбор собеседования системного аналитика в компанию Astion: кандидат заявил о фулстек-опыте, но провалил вопросы по REST, HTTPS и нормализации БД. Оценка ответов и действий интервьюера.

## Key Takeaways

- Системный аналитик в финтехе часто совмещает роли: требования, проектирование БД и интеграций
- Оркестрация концентрирует логику процесса в одном сервисе, хореография распределяет её через события (например, Kafka), у каждого подхода свои риски
- Знание принципов REST, HTTPS, нормализации и нефункциональных требований критично для системного аналитика
- Неясное распределение ролей архитекторов в компании может сигнализировать о организационном хаосе
- Уверенная самопрезентация не компенсирует пробелы в базовой теории

## What the video covers

- Разбор собеседования на позицию системного аналитика в компанию Astion (Aston) с четырьмя этапами: самопрезентация, теория, лайв-кодинг и рассказ о компании
- Кандидат называет себя фулстек-системным аналитиком: сам собирает требования, проектирует БД и интеграции
- Обсуждение архитектуры микросервисов проекта «Банк Авангард» и разница между оркестрацией и хореографией сервисов
- Ведущий отмечает неясность ролей архитекторов в компании (солюшн- и энтерпрайз-архитектор) как возможный red flag
- Разбор принципов REST: кандидат назвал stateless и uniform interface, но забыл остальные принципы (клиент-сервер, кэшируемость, многослойность и др.)
- Ответ про SOAP и WSDL оценён положительно как доказательство реального опыта работы с протоколом
- Вопросы по проектированию баз данных: денормализация, влияние индексов на вставку данных
- Пример нефункционального требования (доступность 99,9%) и различие функциональных и нефункциональных требований
- Кандидат провалил вопросы по HTTPS и перепутал нормализацию с денормализацией
- Ведущий даёт оценки самопрезентации и разбирает, стоит ли идти в такие компании, а также анонсирует вердикт о получении оффера

## Chapters

1. 00:00 Вступление и представление кандидата
2. 01:00 Проект «Банк Авангард» и опыт кандидата
3. 03:00 Архитектура микросервисов: оркестрация и хореография
4. 05:00 Роли архитекторов и red flags компании
5. 05:45 Принципы REST и SOAP
6. 08:40 Проектирование баз данных и индексация
7. 10:55 Нефункциональные требования и HTTPS
8. 12:50 Итоги и вердикт по офферу

Answers

## Questions about this video

Какой проект обсуждался на собеседовании?

Обсуждался проект «Банк Авангард» — сервис создания расчётного счёта для юрлица, с большой формой на фронтенде, которую заполняет директор компании. Архитектура построена на микросервисах с API Gateway и онбординг-сервисом как оркестратором.

В чём разница между оркестрацией и хореографией сервисов?

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

Какие ошибки допустил кандидат в теоретических вопросах?

Кандидат назвал только два из шести принципов REST (stateless и uniform interface), не ответил про HTTPS и перепутал нормализацию с денормализацией. Ведущий отметил эти пробелы как критичные для аналитика.

## Full Transcript — Download SRT & Markdown

00:00

Speaker A

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

00:14

Speaker A

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

00:24

Speaker A

Мы разберём самые интересные моменты в каждом из этапов. Я буду объяснять всё простыми словами.

00:37

Speaker A

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

00:49

Speaker A

И в конце мы узнаем, смог ли кандидат реально получить оффер или нет.

01:00

Speaker A

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

01:10

Speaker A

Итак, погнали.

01:19

Speaker A

Кандидат начинает рассказывать про свой опыт. Пока что это звучит как стандартная задача системного аналитика. Есть какая-то форма, которую нужно спроектировать. Но слушаем дальше, сейчас он раскроет свою роль.

01:34

Speaker A

Я был единственным системным аналитиком, но выполнял задачи, можно сказать, как фулстек. То есть сам собирал требования и технически проектировал БД, интеграции.

01:47

Speaker A

Вот это поворот. Слышите? Он назвал себя фулстек-системным аналитиком.

02:05

Speaker A

Если вы думаете, что аналитик — это человек, который просто рисует квадратики в Miro и пишет ТЗ, то вы глубоко ошибаетесь.

02:22

Speaker A

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

02:30

Speaker A

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

02:45

Speaker A

Далее техлид решил погонять кандидата по тому, знает ли он про оркестрацию и хореографию данных.

02:59

Speaker A

Давайте посмотрим, как кандидат выкрутился.

03:13

Speaker A

Архитектура — микросервисы. Там у нас API Gateway, дальше оркестрирующий сервис — это онбординг-сервис. Он там ходит, отправляет данные на проверку, отправляет дальше данные на скоринг, если все проверки прошли, он дёргает сервис по генерации документов.

03:26

Speaker A

Смотрите, как красиво кандидат описывает архитектуру. Он произнёс ключевое слово «оркестрирующий сервис».

03:33

Speaker A

В микросервисах есть два пути, как можно заставить системы работать вместе: оркестрация и хореография. Разница между ними фундаментальная, и её обожают спрашивать на собесе.

03:48

Speaker A

Представьте себе съёмку фильма. Оркестрация — это как работа режиссёра. Есть один главный сервис, онбординг-сервис, и он сам говорит остальным, что делать. Так, сервис проверок, проверь паспорт. Проверил? Отлично, идём дальше. Так, теперь сервис скоринга, считай риски. Так, посчитал. Теперь сервис документов, печатай договор. То есть все команды идут через одного босса.

04:02

Speaker A

Хореография — это когда главного режиссёра нет. Актёры танцуют сами, реагируя друг на друга. Один сервис сделал работу и закинул событие в Kafka, типа «я проверил паспорт», например. Сервис скоринга услышал это событие и сам забрал данные, посчитал риски и скинул событие «я посчитал» и так далее.

04:06

Speaker A

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

04:16

Speaker A

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

04:24

Speaker A

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

04:40

Speaker A

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

04:52

Speaker A

Честно говоря, он у вас один и вы никак его не называли?

04:59

Speaker A

Да, мы никак его не называли. Он был вообще на несколько команд.

05:09

Speaker A

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

05:22

Speaker A

А кандидат отвечает, что мы его никак не называли. Так почему же это red flag? Для системного аналитика критически важно понимать, с кем именно согласовывать свои технические решения. Если в компании нет чёткого распределения ролей, то неизбежно начинается хаос. Кандидат, конечно, в этом не виноват. Он работал в той структуре, которая уже была до него.

05:34

Speaker A

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

05:47

Speaker A

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

05:57

Speaker A

Далее кандидат неплохо рассказал про монолиты и сервисно-ориентированную архитектуру. И именно поэтому интервьюер и копнул глубже и спросил про принципы REST, на которых держится 90% современных интеграций. И вот тут наш уверенный аналитик, к сожалению, посыпался.

06:09

Speaker A

Ну, подробнее про REST теперь расскажи.

06:15

Speaker A

Это набор соглашений и правил, чтобы API называлось REST и было RESTful, чтобы оно было масштабируемо, поддерживаемо. У нас есть шесть принципов REST.

06:23

Speaker A

Пока что всё хорошо. Кандидат знает, что этих принципов шесть. Это уже неплохо, на самом деле. Но интервьюер хочет услышать сами принципы. Слушаем.

06:37

Speaker A

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

06:50

Speaker A

Отлично. Он назвал самый главный принцип — stateless, то есть отсутствие состояния. Сервер не должен помнить, что вы делали секунду назад. Вся информация приходит в одном запросе. И это действительно позволяет легко масштабировать бэкенд.

07:03

Speaker A

Но что дальше? А дальше ничего. Тишина. Кандидат смог назвать только uniform interface, что означает, что для каждого ресурса должен быть свой URL. А остальные четыре принципа он, к сожалению, забыл. И для системного аналитика это критический пробел.

07:13

Speaker A

Давайте пробежимся по тому, что именно он упустил. Клиент-сервер: логика фронта и бэка разделена. Кэшируемость: сервис должен говорить клиенту, можно ли кэшировать ответ. Без этого ваш сервис умрёт от нагрузки. Многослойность: между клиентом и сервером может стоять 10 прокси-серверов, но клиент об этом не должен знать. И не знать про кэширование — это всё равно что спроектировать медленную и очень дорогую систему. Это просто жирный минус в карму кандидата.

07:23

Speaker A

Но нужно отдать ему должное. На следующий вопрос про SOAP он смог реабилитироваться и показать свой Enterprise-опыт. И, кстати, если тебя уже достал hh.ru, а ты не знаешь, где ещё можно искать работу, переходи в мой Telegram-канал. Там я выкладываю уникальные вакансии, которых нет на HeadHunter'е. Ссылка в описании. Подписывайся, там есть куча пользы по трудоустройству в IT.

07:29

Speaker A

Про SOAP теперь. Что за такое взаимодействие? Это у нас уже протокол, то есть уже более строгий, стандартизированный набор правил.

07:43

Speaker A

Всё верно. Если REST — это свободный архитектурный стиль, то SOAP — это жёсткий протокол. Его до сих пор обожают в банках, госсекторе и телекоме за его надёжность и строгий контракт. И сейчас кандидат покажет, что он не просто слышал это слово, а реально с ним работал. Сервис предоставляет файл WSDL. Он состоит из частей Types, Message, Port Type, Binding. Это уже добавляется протокол. И последнее — это Service Port. Соответственно, это уже набор эндпоинтов.

07:50

Speaker A

Браво. Честно говоря, я такого ответа даже не ожидал. Потому что девять из десяти современных разработчиков на этом вопросе скажут: «Ну, это что-то

08:01

Speaker A

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

08:12

Speaker A

Давайте я вам объясню, что же хотел услышать интервьюер за 30 секунд. Буква S в HTTPS означает secure, то есть безопасный. Эта безопасность обеспечивается криптографическими протоколами SSL и TLS. То самое хитрое рукопожатие, это TLS handshake. Это процесс, когда клиент и сервер

08:28

Speaker A

договариваются о том, как именно они будут шифровать данные. И не знать это в 2026 году, это всё равно что проектировать систему, из которой хакеры унесут все деньги клиентов. Это жирный минус. Слои сети и API оказались для кандидата американскими горками. Но

08:43

Speaker A

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

08:56

Speaker A

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

09:04

Speaker A

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

09:13

Speaker A

Ну, это джой, там если осуществляю какую-то выборку, то у нас нужно джойн между тремя таблицами делать. Это такая ресурсоёмкая операция достаточно.

09:22

Speaker A

Пока что всё идёт отлично. Кандидат правильно описывает проблему. Связь многие ко многим реализуется через промежуточную третью таблицу. И чтобы собрать эти данные, СУБД придётся делать два тяжёлых джойна. Это дорого для процессора и долго. Но послушайте, как он предлагает решить эту проблему.

09:37

Speaker A

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

09:47

Speaker A

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

10:02

Speaker A

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

10:19

Speaker A

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

10:28

Speaker A

Интервьюер проглотил оговорку про нормализацию и перешёл к оптимизации. Он спросил про индекс. И тут кандидат смог немножечко отыграться.

10:35

Speaker A

Как ты считаешь, применение индексации на что повлияет в базе данных? Если мы часто осуществляем там вставку, какие-то манипуляции с данными в нашей таблице, то, наверное, индексы не предпочтительно использовать, вот, потому что каждый раз будет пересчитываться индекс, то есть,

10:51

Speaker A

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

11:01

Speaker A

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

11:14

Speaker A

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

11:26

Speaker A

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

11:35

Speaker A

Приведи пример какого-нибудь нефункционального требования. Прежде система должна быть доступна 99,9% времени. Коротко и абсолютно верно. Любое техническое задание делится на два лагеря требований: функциональные ФР и нефункциональные НФ. Разница между ними часто объясняется слишком сложно, но по факту всё элементарно. Функциональные

11:54

Speaker A

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

12:09

Speaker A

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

12:23

Speaker A

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

12:36

Speaker A

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

12:51

Speaker A

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

13:05

Speaker A

интонацию интервьюера. Он его не душит и не отправляет учить матчасть. Он говорит: "Ну, нормально. Ты же не мог знать всего. У тебя есть конкретный практический опыт". И почему же так происходит? Потому что наш кандидат уверенный практик. Вспомните, как он в

13:18

Speaker A

начале рассказал про VHDL и SOA, как чётко разложил работу с монолитами и микросервисами, как он объяснял индекс.

13:24

Speaker A

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

13:41

Speaker A

legacy. Раз ты посмотрел это скучное видео полностью, то значит, ты реально хочешь устроиться на работу в IT.

13:46

Speaker A

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

13:57

Speaker A

мог начать всё сначала, после обучения я бы откликался на middle вакансии сразу, пропустив грейд джуна. Почему так? У меня есть отдельное видео. Но главный секрет в другом. Чтобы сразу выйти на уровень мидла, нужно создать вокруг себя особую обстановку. Такую, где рядом есть

14:11

Speaker A

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

14:26

Speaker A

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

14:40

Speaker A

настолько уверен в результате, что даю стопроцентную гарантию. Но и это ещё не всё. Ты бесплатно получишь мини-курс с подробным планом по трудоустройству в IT за 4-6 месяцев с нуля, который сэкономит тебе минимум год жизни. Для этого перейди по ссылке в описании и за- полни

14:55

Speaker A

короткий опрос в течение пяти минут после просмотра этого видео. У тебя будет ровно 5 минут, поэтому сделай это сразу, как только закончишь просмотр данного видео. А теперь давай наконец узнаем, получил ли кандидат оффер. В общем, мой вердикт. Кандидат очень

15:08

Speaker A

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

15:15

Speaker A

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

15:21

Speaker A

Пишите в комментариях, а взяли бы вы такого аналитика себе в команду? Ставьте лайки, подписывайтесь на канал и обязательно учите базу. До встречи в новых разборах. Всем пока. А теперь скорее переходи по ссылке в описании и забирай бесплатный мини-курс. Твои 5 минут пошли прямо

15:37

Speaker A

сейчас.

Topics: системный аналитик собеседование микросервисы REST SOAP оркестрация хореография проектирование БД нефункциональные требования IT карьера

Учить по этому видео

- [Карточки по этому видео](https://sozai.app/ru/tools/flashcard-maker/?from=transcript&id=87592)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=87592)
- [Кроссворд по этому видео](https://sozai.app/ru/tools/crossword-maker/?from=transcript&id=87592)
- [Филворд по этому видео](https://sozai.app/ru/tools/word-search-maker/?from=transcript&id=87592)
- [Шпаргалка по этому видео](https://sozai.app/ru/tools/study-guide-maker/?from=transcript&id=87592)

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.


---
This is the markdown twin of https://sozai.app/transcript/system-analyst-interview-astion-company-2026/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/