**CV | Как рассказывать о проектах на собесе СА — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/how-to-talk-about-projects-in-system-analyst-interview/

Мок-собеседование системного аналитика: кандидатка рассказывает о своём опыте в банковских проектах, микросервисной архитектуре, требованиях и интеграциях, а интервьюер даёт обратную связь.

## Key Takeaways

- Системный аналитик на собеседовании должен чётко структурировать опыт: проекты, роль, артефакты и технологии.
- Важно уметь объяснять бизнес-цель фичи и затем техническую реализацию.
- Знание терминологии (BFF, сериализация, git-ветвление) должно быть точным, иначе это вызывает вопросы интервьюера.
- Обратная связь на мок-интервью помогает выявить слабые места в ответах и улучшить коммуникацию.

## What the video covers

- Видео — прогон (мок-интервью) собеседования на позицию системного аналитика на русском языке.
- Ведущая работает системным аналитиком около года, ранее была фронтенд-разработчиком и переучилась на аналитика.
- Обсуждается роль аналитика как эксперта по проекту и отличие от роли разработчика, которая более узкая.
- Кандидатка описывает два банковских проекта: мобильное приложение для физлиц (БТА банк) и веб-приложение для юрлиц (Паритетбанк), работа ведётся по Scrum с двухнедельными спринтами.
- В описании опыта: работа с требованиями, приоритизация, диаграммы UML и BPMN, use case и epic, sequence-диаграммы, описание API в Swagger и тестирование в Postman.
- Технологический стек проекта: Java, React, микросервисы, интеграция через REST и Kafka, базы данных PostgreSQL и MongoDB.
- Разбирается пример разработки фичи отображения кредитов клиента с фильтрацией и детальной информацией.
- Обсуждаются git-ветки (test для интеграционной среды, master для прода), роль архитектора и документы, на основании которых аналитик ведёт работу.
- Интервьюер дает обратную связь: советует уточнять детали, избегать неточностей в терминах (например, BFF) и готовить более структурированные ответы.
- Затрагиваются вопросы сериализации и десериализации, пагинации, работы с кешем и разделения запросов на группы по стадии продукта.

## Chapters

1. 00:00 Знакомство и настройка прогона собеседования
2. 03:00 Переход из фронтенда в системный анализ
3. 09:00 Рассказ о банковских проектах и опыте
4. 20:00 Технологический стек и базы данных
5. 30:00 Пример разработки фичи и архитектуры
6. 40:00 Git-ветвление, архитектура и документация
7. 50:00 Вопросы по интеграциям и обратная связь

Answers

## Questions about this video

Какой опыт работы у кандидатки в системном анализе?

Более 3 лет в системном анализе, два проекта в банковской сфере: мобильное приложение БТА банка и веб-приложение Паритетбанка для юрлиц. Работа велась по Scrum.

Какие инструменты и артефакты использует системный аналитик по её словам?

UML и BPMN диаграммы, use case и epic, sequence-диаграммы, Swagger для описания API, Postman для тестирования, работа с тест-кейсами и проектирование БД.

Какой технологический стек указан на проекте?

Java и React для разработки, микросервисная архитектура с интеграцией через REST и Kafka, базы данных PostgreSQL и MongoDB, где Postgres хранит данные о клиентах и картах, а Mongo — документы и выписки.

## Full Transcript — Download SRT & Markdown

00:01

Speaker A

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

00:24

Speaker A

Скажи, это у тебя первый опыт прогона по севе? А был уже прогон по севере и в целом понимаю, как это всё будет. Скажи ещё, пожалуйста, как у меня дела со звуком? Мне кажется, у меня наушники хребят. Если я их сниму, возможно, ты

00:37

Speaker A

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

00:52

Speaker A

Хорошо, всё нормально слышно. Я думаю, что всё будет о'кей. Тут никто не потревожит. Ну супер. А значит, ты знаешь, что начинаем мы с твоего рассказа. После этого я тебе позадаю вопросы, как будто бы я настоящий стекхолдер для тех лит,

01:07

Speaker A

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

01:22

Speaker A

Вот реально какой у тебя опыт? А связан с IT не связан? А системным анализом может быть или бизнес-анализом был в прошлом реальный опыт а на каком-то там учебном проекте. Ну в общем, всё, что хочешь.

01:37

Speaker A

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

02:00

Speaker A

уже закончился. Ну, о'кей. А перешла ты на аналитика? А сколько месяцев или дней назад?

02:10

Speaker A

А, перешла не так кажется давно, но вышла в стафинг я достаточно быстро. Блин, ну я не знаю, мне кажется, пару месяцев, наверное, я в этом в целом.

02:22

Speaker A

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

02:33

Speaker A

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

02:45

Speaker A

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

03:02

Speaker A

просто этот разработчик, он сидит там в своём выделенном кусочке задач, и, в принципе, особо ему ничего не надо другого. Вот поэтому, да, аналитикам как бы это прикольное, но сложнее, скажем так. Определённо то, что ты говоришь, да, фронт - это достаточно тоже

03:18

Speaker A

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

03:36

Speaker A

Угу. Главное, чтобы ты не попала на проект, где вообще нету никакого фронта. Что такое тоже бывает.

03:44

Speaker A

Ну вот я, например, с фронтом очень плотно работаю. Это вот приложениечески и веб ещё. Поэтому у меня вот куча контентразработчиков в команде. Я с ними как бы постоянно вот только что сидела от них, можно сказать. [фыркает] А, о'кей. А-а, а знаешь ли ты что-то по

04:06

Speaker A

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

04:31

Speaker A

посмотрю. Как-то он звучал про оптимизацию счетов. Вот хотела как раз с тобой посоветоваться, потому что а достаточно быстро нужно было реагировать на эту вакансию. Блин, где сообщение? У меня и в приоритете кандидаты, имеющие опыт или хотя бы понимание фондового рынка и

04:57

Speaker A

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

05:14

Speaker A

описание какое всё-таки верное? Походу тут просто в задаче приложено описание старойкасии. Я предполагаю. Это хорошо, на самом деле, для тебя это гораздо проще. Хорошо.

05:29

Speaker A

Но это тоже ско то, что я назвала. Да. Да. Вот. Хорошо. О'кей, я поняла. А давай тогда плавно переходить к твоему рассказу.

05:44

Speaker A

Вот. Расскажи, пожалуйста, какой у тебя опыт работы в качестве системного аналитика, на каких проектах ты работала.

05:52

Speaker A

Угу. А так ещё раз здравствуйте. Я работаю системным аналитиком более 3 лет. За это время у меня было два проекта в банковской сфере. Первый мой проект - это БТА банк, мобильное предложение для физических лиц, а, с функционалом, а, оформления платёжных

06:13

Speaker A

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

06:23

Speaker A

А в команде были бизнес-аналитик, системный аналитик, фронт-разработчики, архитектор, разработчик, тестировщики, продукт owур, PM и дизайнер. А второй мой проект - это Паритетбанк. Это уже веб-приложение для юридических лиц, а, с сервисами кредитования депозитов а платежей также онлайноофорния банковских карт. А

06:47

Speaker A

моя команда занимается кредитным сервисом, а работа также ведётся в покрам. а, двухнедельными спринтами. Здесь команда уже побольше, а, два системных аналитика: QA инженеры, автоматизатор а разработчики фронд-разработчики, также архитектор и дизайнер по запросу и prodctwer. А на проекте у меня микросервисная

07:10

Speaker A

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

07:27

Speaker A

А требования для разработчиков, а описываю в формате юзкейсов, эполкты, а их описания с помощью sequence диаграмм, а работу над нпоинтами, веду в Swager и тестирую в Postman. запросы.

07:44

Speaker A

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

08:04

Speaker A

Угу. Да, конечно, такой серьёзный, обширный опыт. А скажи, пожалуйста, а какой технологический сек у вас на проекте?

08:15

Speaker A

А у нас Java, React, а, ну, джависты - это разработчики и фронты пишут на реакцию.

08:25

Speaker A

Угу. На код линии сейчас не пишут у вас? У нас нет. Нет, нет. Угу. А базы данных какие есть? С какими работаете? И Монго.

08:37

Speaker A

Угу. А какие данные вы сохраняете в постгрес? Какие в монго? А так постгре мы используем для данных, например, о клиентах, картах. А монго использован для документов, выписок о счёте и прочему.

09:00

Speaker A

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

09:17

Speaker A

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

09:27

Speaker A

И можно сказать, что, ну, много чего разрабатывала уже с моим участием команда. Угу. [фыркает] То есть была и доработка, и новая задача.

09:40

Speaker A

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

09:53

Speaker A

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

10:04

Speaker A

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

10:35

Speaker A

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

10:53

Speaker A

Вот. И, соответственно, ээ как это было, а, организовано в плане архитектуры. А, то есть у нас был микросервис, ну, клиент делал запрос на микросервис кредитов, тот, в свою очередь, делал запрос на базу данных, получал оттуда данные и передавал это всё на фронт.

11:13

Speaker A

Угу. Это были кредитные предложения, которые доступны, а, клиенту или уже оформленные кредиты? Уже. Уже, да, кредиты клиента.

11:23

Speaker A

Кредиты клиента. А над кредитными предложениями вы над списками не работали? Ну, тоже работали, но мне почему-то это впервые вспомнилось, что, ну, то же самое можно проделать и с кредитными приложениями банка. Будет, в принципе, то же самое. Это будет гетзапрос

11:42

Speaker A

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

11:58

Speaker A

Хотя, в принципе, это может быть и, ну, не наверняка это не будет кредитном профиле, да? Предложения будут где-то там на главном.

12:06

Speaker A

А, хорошо. Использовали ли вы погинаться? То есть кредитов-то может быть много? Мм, ну, мы не использовали, но, наверное, я должна сказать, что использовали, да, погуглить.

12:20

Speaker A

Учитывая, что ты ответила, что вы действующие кредиты выводила, их не будет 50. Ну, это редкий человек. Вот если бы кредитное предложение, тогда да, их может быть и 3.000.

12:32

Speaker A

Вот и их уже там можно фильтровать и так далее. А свои там, в принципе, что их фильтровать?

12:39

Speaker A

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

12:43

Speaker A

Угу. Ну, что такое пагинация в целом? Ты знаешь, конечно. Да. Это когда мы делим наш огромный список на какое-то отображаемое количество, там по 10 на Да, да, да.

12:57

Speaker A

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

13:13

Speaker A

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

13:33

Speaker A

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

13:51

Speaker A

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

14:11

Speaker A

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

14:30

Speaker A

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

14:48

Speaker A

наверное, 40. Вот взять их типа всех перевести на бейказ, но это типа довольно такая рутинная, скучная задача.

14:56

Speaker A

Вот. Хорошо. А были, а были ли у вас вот на проекте тех целей, которые устанавливал Техлит, и над какими вот техцелями тебе понравилось работать?

15:11

Speaker A

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

15:26

Speaker A

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

15:36

Speaker A

Э вот даже не знаю, возможно, а что это могут быть за цели? Например, изучить что-то, с чем мы сейчас не работаем, но в перспективе можем использовать, да, писать документацию в другом формате, например, потом же по той же Open Appе, а GTA писать документацию, а

15:56

Speaker A

сохранять её. А всякие таски типа перехода на Пайпзипи - это что-то типа, а как тебе объяснить? Статусная модель.

16:13

Speaker A

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

16:27

Speaker A

Там, а, например, как это, какой-то стандарт банка, например, или насколько разный может быть формат?

16:35

Speaker A

Как как вот хочет тех, всё, что он решит. Ну, должно это быть что-то интересное.

16:43

Speaker A

Угу. Изучить что-то новое, вот что-то внедрить, не знаю, это может быть всё, что угодно там.

16:54

Speaker A

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

17:00

Speaker A

Ну, это, наверное, меня ещё выдаст, да, если я возьму какой-то твой формат, то станет ясно, что куда-то взяла это.

17:08

Speaker A

А если у меня, например, не было такого, что мне не ставили техцеле или это подозрительно?

17:13

Speaker A

Ну, это как-то печально звучит, да? Можешь сказать, что да, были техски, но по факту нам ставились просто туда техдолги. В основном редко бывало что-то интересное. Мы там А можешь сказать, что приведение документации к единому формату это тоже техск?

17:34

Speaker A

Угу. Ревю документации и Угу. Вот что-то такое. Можешь сказать про аутентификацию тоже, потому что это частая история в банке.

17:49

Speaker A

Угу. Так. Хорошо, с этим у меня всё понятно. А скажи, пожалуйста, вот как фиксились у вас баги?

18:01

Speaker A

Две группы. Первая, которая ещё не попала на прод и вторая группа, которые уже пришли к вам от саппорта с продом.

18:10

Speaker A

Баги, какой был процесс в команде? Так, ну, те, которые не попали на прот, я бы сказала, что, а, заводили задачи под, ну, типа сами баги заводили тестировщики. А если я сама, как пользователь замечала какой-то баг, как и все там участники разработки, мы

18:30

Speaker A

сообщали в отдел тестирования и ребята заводили задачи и справляли. Если были какие-то несоответствия, непонимания, недопонимания там касаемо документации, обращались за уточнениями ко мне. А мы это всё проговаривали и исправлялись.

18:50

Speaker A

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

19:07

Speaker A

смотрели например логирование то есть, э, смотрели какие-то вопросики э с использованием Елк стека. И в соответствии с этим уже тоже, в общем, исправляли и дорабатывали.

19:23

Speaker A

Угу. А этим тестировщик занимался или аналитик? Ну, с исправлением багов тестировщик, а аналитик больше как команда.

19:37

Speaker A

Этот разъяснительная бригада, наверное. Сапорт приходил изначально к аналитику, он уже анализировал, баг - это или не баг, потому что не всегда то, что саппорт считает баком, является багом.

19:50

Speaker A

Поэтому аналитик - это типа первое звено, которое может сказать: "Нет, стояночка, всё так и должно работать".

19:56

Speaker A

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

20:08

Speaker A

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

20:29

Speaker A

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

20:45

Speaker A

Вот. А как понять? А вот что пришёл нам баг. А как нам понять, это баг а бека или это баг фронта?

20:58

Speaker A

Как понять? Ну, как понять? Хм, ну, всегда в команде это решается, да, если какая-то, ну, типа, насколько критичная ситуация сейчас рассматривается.

21:12

Speaker A

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

21:20

Speaker A

Вот как ты поймёшь, к Лёше тебе идти или к Диме с с этой проблемой?

21:26

Speaker A

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

21:40

Speaker A

Угу. [откашливается] А если мы говорим про логи, ну и по логированию тоже можно определить.

21:48

Speaker A

Можно определить скорее, что, а, что приходит с медла или что на фронте происходит. А, хороший вопрос. Я знаю, что там есть время, ну, типа лога, да, и какую-то, честно говоря, не знаю, что содержит лог. Надо этот момент доизучить, но я

22:07

Speaker A

думаю, что с БКА информация туда поступает. Не с фронта. Это тебе домашнее задание, но ты думаешь правильно.

22:14

Speaker A

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

22:33

Speaker A

И для этого ты, в общем-то, логи смотришь. А это тебе, кстати, и в будущем пригодится после того, как ты видишь проект, чтобы понимать хотя бы, ну, типа, с чего, да? А-а, хорошо. А, с этим понятно.

22:49

Speaker A

Расскажи пожалуйста. Ладно, ставим архитектуру архитектуру на десерт. [смех] Мой любимый вопрос. А какой у вас был тфлоу?

23:05

Speaker A

А так тфлоу. Но у нас была мастер ветка, в которую не делаются комиты, в которую поступает код только с помощью РGжей.

23:18

Speaker A

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

23:33

Speaker A

А вот я думаю, что ещё нужна ветка для прода. Я не знаю, нужна ли, но я думаю, что нужна.

23:41

Speaker A

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

23:55

Speaker A

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

24:15

Speaker A

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

24:35

Speaker A

даже сама, и оттуда протестить. Вот. И м ветки, которые фича, а они не мёжатся в D, а они создаются а ветление от мастера. Как раз-таки, когда ты на тесте уже протестила, например, что действительно убедились, всё работает, ты тебе не обязательно использовать

24:54

Speaker A

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

25:13

Speaker A

Вот в деп её или в тест мёжить не надо. А тест, ещё раз, он для чего? Кто им пользуется? Аналитики и да, аналитики не особо не пользуются. Ну типа редко. Я могу там на тесте картинки какие-то поменять, но это может делать

25:30

Speaker A

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

25:37

Speaker A

Вот. Но понимание, как это происходит, такое типа базовое должно быть. И вот если ты в тест несла, да, вот у тебя есть например а ну вот как у нас есть AM Alpha Mobile, то есть мобильное приложение, есть АО,

25:51

Speaker A

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

25:59

Speaker A

Вот. И под это есть как бы специальные тестовые стенды или тестовые сборки. То есть вот есть определённый урол, по которому ты можешь перейти, и это тестовая среда для АО, например. Или ты можешь закинуть тестовую сборку в Bстекс или в какой-то

26:17

Speaker A

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

26:36

Speaker A

Угу. Вот. То есть тест - это ветка для интеграционной или тестовой среды. Угу. Вот. А мастер - это ветка для прода. А так и называется мастер.

26:55

Speaker A

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

27:08

Speaker A

Вот так. В основном в целом ты всё правильно ответила. Вот толь только по ветке фичи немножко, что типа вот их нужно в деф сливать. Вот это мне немножко насторожило. В остальном всё хорошо.

27:22

Speaker A

Вот. А были ли у вас на проекте диплинки? Использовались ли? Мм диплинки. Напомни, пожалуйста, что это не могу сейчас что-то сообразить.

27:36

Speaker A

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

27:45

Speaker A

А это это так и есть. Там ничего сложного нет. Это просто ссылка, которая ведёт на определённый новый экран. Ну, новый, не старый, неважно. В общем, есть реестр диплинков, там где содержится а сам deплинк и экран его изображения, куда он ведёт.

28:03

Speaker A

И если тебе нужно создать новый экран, тебе нужно создать новый плинк, и он будет туда вести.

28:11

Speaker A

Угу. И когда ты, например, получаешь Ну, то есть как же обычно переход? Переход-то по кнопке, да, но в то в ты запрашиваешь а данные, ну как бы спонс не не в тот момент, когда ты кликаешь по кнопке, а

28:27

Speaker A

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

28:41

Speaker A

просто пользуем. Я поняла. Угу. А, а знаком ли ты с такой концепцией, как SDUI или BDUI? Backend Driven UI?

28:54

Speaker A

BD, ээ, не воспроизведу, но так я знаю BFF, но я также слышала, что есть вот этот Backend Driven.

29:08

Speaker A

Блин, ты сказала Backend Driven UI, да? А что это? Может быть, это возможно о том что так, ну, это, наверное, не про Я могу фантазировать, но, наверное, нужно знать точно. Я, ну, не сталкивалась. Я я что-то читала, но сама

29:27

Speaker A

с этим не работала. Возможно, это что-то типа аа что у нас как бы фронт глупый, да, а всё происходит на бэкэнде, а фронт просто изображает.

29:39

Speaker A

Да, это оно именно есть. Бдуй, [откашливается] сдуй, как у нас. Да, это ты можешь про это, в принципе, и не знать. В своём банке используется такой подход, когда кэнд высылает полностью все параметры, которые нужны для отрисовки фронта.

30:01

Speaker A

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

30:16

Speaker A

тебе приходит аа напоминалка, что скачайте новую версию Facebook или скачайте новую версию Инсты, вот это как раз означает, что релиз фронта, то есть обновление фронта. И так как сейчас все российские банки исключены из App Store и Google Play, естественно, что релиз

30:35

Speaker A

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

30:51

Speaker A

То есть поменять текст, поменять картинку, поменять расположение, то есть это всё присылается с БКА. И это типа супер круто, на самом деле.

31:01

Speaker A

Вот. Но в связи с этим другой вопрос. Приходилось ли тебе составлять джерсоны большого объёма, больше 300 строк, например?

31:10

Speaker A

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

31:25

Speaker A

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

31:49

Speaker A

какое расстояние, какой цвет шрифта и так далее. Вот. И считается, что аналитик должен прописать вот такой жез.

31:58

Speaker A

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

32:11

Speaker A

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

32:24

Speaker A

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

32:31

Speaker A

Спасибо. Вот. Ээ, хорошо, давай пойдём дальше. Какие основные артефакты, аналитика ты составляла? И вот как какие в основном для БКА приходилось делать, какие для фронта?

32:45

Speaker A

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

33:11

Speaker A

sequнсдиаграммы. Аа, да sequнсдиаграммы вот в таких форматах. Угу. О'кей. Чего-то не хватало. Ну так просто немножко замешала мухи с котлетами, но в целом всё правильно.

33:39

Speaker A

Вот. А как почему? Почему замешала? А, ну ты сказала, что вот есть макеты, да?

33:48

Speaker A

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

34:10

Speaker A

пользователя. И контракт пронту этого достаточно. Вот. Ак там, да, будет SEнс, будет его описание алгоритма.

34:23

Speaker A

А, ну понятно, там название метода, мм, в чём его типа основная цель. А, и в принципе, а, и мапинг данных. Вот это обязательно. Что? Мапинг данных. Да, ну всё.

34:41

Speaker A

Вот. Ну, в целом, короче, всё. Так, ну и по архитектурным задачам. Как вообще у вас часто происходило взаимодействие с архитектором? По каким вопросом?

34:55

Speaker A

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

35:09

Speaker A

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

35:30

Speaker A

Только он вам должен, ну, там типа не просто прийти на словах объяснить, он может наоборот, ему даются какие-то бизнес-требования, он может ещё и к тебе спросить: "А как это работает сейчас?" Потому что архир, ну, может, тоже не знает, там всех не порас.

35:44

Speaker A

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

36:03

Speaker A

Я думаю, что компонентов нет. Он Угу. Да, всё верно. Это может называться как угодно, там Vision, Татар, реестр, но по сути он всегда включает в себя, ну, везде диаграмма компонентов и какое-то её там текстовое описание. Ну, м суть в том, что, да,

36:27

Speaker A

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

36:45

Speaker A

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

36:59

Speaker A

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

37:16

Speaker A

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

37:35

Speaker A

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

37:47

Speaker A

Вот. То есть, в принципе, так это работает. Не то, чтобы вы там бы общались с ним каждый день. [смех] В основном это по новым фичам происходит.

37:57

Speaker A

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

38:02

Speaker A

Ну вот если, например, мы берём систему, в которой Ага. То есть это его будут решения. Угу.

38:08

Speaker A

Да. Ну ты тоже, конечно, можешь предложить. То есть тебя позовут навстречу. Это не то, что он скажет.

38:13

Speaker A

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

38:31

Speaker A

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

38:48

Speaker A

систему, и она может не выдержать такой нагрузки". Угу. То есть, как правило, это связанный вопрос с нагрузкой, когда он понимает, что нагрузка будет увеличена там в, ну, там понятно, что 100 запросов погоды не сделают, но если там идёт речь о том,

39:06

Speaker A

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

39:27

Speaker A

за данными. Вот эти тоже нужно учитывать. Вот. То есть у нас была не онлайн установка, а оффлайн.

39:39

Speaker A

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

39:50

Speaker A

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

40:06

Speaker A

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

40:19

Speaker A

Угу. Вот. А, хорошо. Мы, в принципе, с тобой так быстренько идём. Очень даже. Можно я спрошу, пока не сла? У меня есть в СV мобильное приложение. Как вообще, как ты думаешь, как меня захотят спрашивать по какому из проектов и что

40:42

Speaker A

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

40:57

Speaker A

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

41:07

Speaker A

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

41:21

Speaker A

что там было с ABS, то есть вот это вот всё, да? А с какими командами ты взаимодействовала? Давай обсудим.

41:28

Speaker A

Или с какими сервисами? А на примере какого из проектов это лучше делать? А ты рассказывала про кредиты? Да, по-моему. Вот продолжай тогда лучше про кредиты.

41:42

Speaker A

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

42:03

Speaker A

который сообща кого-то слышала сервис, сообщающийся с АС, но я не поняла, что это значит, потому что у меня Меня на одном из прогонов сказали, что, а, если мы разрабатываем по паттерну БФ, ну, ты же знаешь, наверное, про паттерн БФ, и вот,

42:20

Speaker A

например, я была как бы фронтовым аналитиком, то есть я разрабатывала вот фронт-систему и midle, то есть вот это было моим бком. И была какая-то команда, которая занималась той стороной.

42:34

Speaker A

Ещё мне сказали, что бывает в архитектуре так, что роль ABS-системы, ну, то есть вот роль этого БКА, который за моим как бы вот этими двумя слоями лежит, как конечный БК, скажем так, вот роль его может выполнять либо микросервисы, либо ABS,

42:53

Speaker A

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

43:06

Speaker A

Более реалистично будет, что вы логировали данные в и сохраняли в ABS через шинный обработчик.

43:16

Speaker A

Шинный обработчик. А тогда в моей Хорошо в моей зоне ответственности был фронт. Вот этот midл система, которая была бком. А где машина идёт? За вот этим уровнем или у нас с фронта идут на шину запросы?

43:34

Speaker A

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

43:48

Speaker A

Да, фронт. Понятно. Фронт есть. Фронт. Дальше midл. Что это у тебя было? какой-то микросервис тоже, ну, говоришь, что это был там микросервис кредитапи, условно, я не [смех] знаю, что может быть, потому что когда ты говоришь: "А, ну ты сказала сервис". Да, ну, сервис

44:05

Speaker A

нормально. Аа хорошо, а потом ты, скорее всего, взаимодействовала, если это идёт отправка заявки на кредит с какими-то антифрот и скоринговыми системами, правильно?

44:17

Speaker A

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

44:40

Speaker A

либосервис, либо это может быть SWсвис на самой шине. Вот примерно так. Ну, на самом деле, всё, что ты сказала, кроме BFF, это имеет смысл. BFF - это уже что-то тебя немножко запутать решили, потому что это А, ну я поняла, у

45:00

Speaker A

тебя типа вот эти вот множество кредитных приложений. А BFF - это вот когда тебе нужно собрать данные совершенно из разных источников и там формат даже разный. То есть Угу.

45:15

Speaker A

Да. А ты что-то получаешь, например, из модуля ABS напрямую, что-то из шинного сервиса, который на Суапе, третью часть информации из микросервиса, который на Росте, и четвёртую там из очереди, а, MQ, например. Вот в таком случае тебе нужен BFF, который это будет всё

45:36

Speaker A

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

45:47

Speaker A

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

46:05

Speaker A

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

46:20

Speaker A

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

46:39

Speaker A

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

46:48

Speaker A

Вот. И, как правило, я взаимодействую с ними. Либо, если эта информация нет ни там, ни там, я иду в шинный сервис.

46:57

Speaker A

Угу. Всё, короче, то, что придумаю, то то и будет моим проектом. Я поняла, что нужно просто что-то определиться и рассказать.

47:08

Speaker A

Да, всё верно. Они же не знают, как у вас там в банке всё на самом деле было.

47:14

Speaker A

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

47:25

Speaker A

Вот. Хорошо. У меня даже, честно говоря, особо и вопросов к тебе нет. А по платёжным карточкам я ещё думала, как вариант, у меня просто два банка, и нужно что-то в мобильном приложении сказать, чем занималась моя команда. Я посмотрела,

47:40

Speaker A

раз проект связан со счетами, то я боюсь заходить на эту территорию, потому что они захотят в этом покопаться. А вот типа онлайн оформление карт и вот выпуск их, вот это вот всё. Поэтому у тебя есть какой-то опыт, чтобы подсказать,

47:56

Speaker A

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

48:16

Speaker A

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

48:30

Speaker A

А что-то интересное, это вот, например, любую задачу какую-то, вот как мы, например, начали, я как пример, ты спрашивала про Фичу, да, и я вот говорила про, например, кредиты компании, то есть в идеале рассказать, что ко мне пришёл заказчик с таким-то

48:45

Speaker A

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

49:04

Speaker A

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

49:23

Speaker A

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

49:42

Speaker A

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

49:57

Speaker A

формате, а, XML данные получали, с помощью библиотек Java переводили в а Jon дальше уже обрабатывали в Jсонеoneне в своём микросервисе, как обычно.

50:11

Speaker A

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

50:23

Speaker A

Типа оформленные кредит. Ну, о'кей. А про катку тебе что-нибудь рассказать или нет вопросов? Пров. Так, расскажи мне, в каком формате передаются данные в очередь и что такое сериализация и десериализация?

50:39

Speaker A

В таком формате, по-моему, протобав и сериализация, дисериализация. Ну, сериализация - это то, что приходит в Угу. Короче, здесь реализация - это когда мы для клиента преобразовываем в нормальный вид. А все реализация - это получается наоборот, господи, как это звучит? Нормальный,

51:02

Speaker A

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

51:30

Speaker A

Вот. А, а ещё ты спросила, как какой формат. А, ну я сказала про Табав, но, возможно, у меня уже всё в голове перемешалось.

51:39

Speaker A

У, это JRPC. Ты ответила вообще не в ту сторону. Хорошо. А какой формат? А что-то я я знаю, что пока расскажи ты, потому что я сегодня много смотрела и читала про кавку, но вот про формат я как-то не упустила информацию.

51:58

Speaker A

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

52:13

Speaker A

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

52:27

Speaker A

А, а консюмер а на входе должен сначала десерлизовать, а потом уже сопоставить вот эти вот параметры. То есть он сначала переводит Джерсон, а потом смотрит: "Ага, что это у меня пришло?

52:41

Speaker A

Есть ли там такое-то поле?" Угу. Вот. И в кафке всё идёт, на самом деле, в в байтах в очереди, но есть такие инструменты, как в Set Explorer, кавка Tool, они позволяют, э, ну, то есть человека читаемый формат переводить. То есть по умолчанию, если

53:01

Speaker A

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

53:13

Speaker A

Угу. Сработчиком, да, это надо знать. Вот. То есть, по сути, это просто шифрование и перевод в байтовый формат.

53:22

Speaker A

Не, не более того. Угу. Вот. А чем отличается АИ от сервиса? А от сервиса?

53:35

Speaker A

Угу. М. ПМ-пум-пум апи от сервиса. А, наверное, ничем, потому что сервис - это совокупность методов и а - это то же самое.

53:53

Speaker A

Угу. Ну, просто сервис может не иметь определённого URL, где он будет лежать. Это может быть просто набор кода.

54:02

Speaker A

Угу. Файбе предполагается, что у него есть определённый endpint, где он располагается. Угу. Вот, в принципе, у тебя всё хорошо и очень не нарита. Ну, видно, что ты уже подготовленная. тебя раньше проводили прогоны по CV, потому что ты уже

54:25

Speaker A

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

54:36

Speaker A

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

54:55

Speaker A

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

55:13

Speaker A

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

55:23

Speaker A

Угу. Вот как-то так. Угу. У, соответственно, та система, которая принимала решение, там, не знаю, там CRМ для менеджеров, что-нибудь такое, а она должна была вам передать статус, то, что удобрено, а вы через кавку этот статус получали как консюмер

55:43

Speaker A

и меняли статус в мобильном приложении. Угу, [откашливается] поняла. В принципе, у меня

Topics: системный аналитик собеседование мок-интервью IT-карьера UML микросервисы требования банковские проекты Scrum подготовка к собеседованию

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

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

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


---
This is the markdown twin of https://sozai.app/transcript/how-to-talk-about-projects-in-system-analyst-interview/ — 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/