Speaker A
Привет ещё. А я работаю системным аналитиком на проек А вот а работаю уже около года. А точно не помню, начинала слабые, так же как, наверное, и ты. Вот. А и а сегодня я буду у тебя проводить прогон по севи.
Мок-собеседование системного аналитика: кандидатка рассказывает о своём опыте в банковских проектах, микросервисной архитектуре, требованиях и интеграциях, а интервьюер даёт обратную связь.
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
- 00:00Знакомство и настройка прогона собеседования
- 03:00Переход из фронтенда в системный анализ
- 09:00Рассказ о банковских проектах и опыте
- 20:00Технологический стек и базы данных
- 30:00Пример разработки фичи и архитектуры
- 40:00Git-ветвление, архитектура и документация
- 50:00Вопросы по интеграциям и обратная связь
Full Transcript — Download SRT & Markdown
Speaker A
Скажи, это у тебя первый опыт прогона по севе? А был уже прогон по севере и в целом понимаю, как это всё будет. Скажи ещё, пожалуйста, как у меня дела со звуком? Мне кажется, у меня наушники хребят. Если я их сниму, возможно, ты
Speaker A
меня будешь плохо слышать. Они немножко тят. Давай попробуем снять. Да, очень. Давай. Так, раз-раз, раз-раз.
Speaker A
Хорошо, всё нормально слышно. Я думаю, что всё будет о'кей. Тут никто не потревожит. Ну супер. А значит, ты знаешь, что начинаем мы с твоего рассказа. После этого я тебе позадаю вопросы, как будто бы я настоящий стекхолдер для тех лит,
Speaker A
который будет на собесе. И после этого обсудим. Я обычно сразу даю какую-то обратную связь и рекомендации, и в конце ты можешь тоже что-то спросить, то, что тебе интересно. Вот. А расскажи, пожалуйста, для начала просто о себе.
Speaker A
Вот реально какой у тебя опыт? А связан с IT не связан? А системным анализом может быть или бизнес-анализом был в прошлом реальный опыт а на каком-то там учебном проекте. Ну в общем, всё, что хочешь.
Speaker A
Аэ так в Астон я заходила как фронтенд-разработчикло решение переучиться на системный анализ, потому что в целом мне это было интересно направление, и решила попробовать. Вот, а сейчас я на проекте учебном, а, про бизнес и, ээ, боже, это должен был быть длинный рассказ, но он
Speaker A
уже закончился. Ну, о'кей. А перешла ты на аналитика? А сколько месяцев или дней назад?
Speaker A
А, перешла не так кажется давно, но вышла в стафинг я достаточно быстро. Блин, ну я не знаю, мне кажется, пару месяцев, наверное, я в этом в целом.
Speaker A
Угу. И кем больше нравится: НТН разработчикам или аналитикам? Я бы их не сравнивала, потому что это две разных сферы моей жизни были. Вот.
Speaker A
Ну пока как бы интересно. Реального опыта нет. Я думаю, что когда я выйду на настоящую работу, я, может быть, по-другому как-то буду всё ощущать. Пока это больше учебные процессы.
Speaker A
Ну да. Аналитик - это эксперт по всем вопросам. Поэтому, если, а, например, какой-то новый процесс или вообще, а, из команды никто не знает, где какие-то креды достать, как это всё работает, как подключиться, это всё равно всё будет сваливаться на аналитика, к сожалению. А
Speaker A
просто этот разработчик, он сидит там в своём выделенном кусочке задач, и, в принципе, особо ему ничего не надо другого. Вот поэтому, да, аналитикам как бы это прикольное, но сложнее, скажем так. Определённо то, что ты говоришь, да, фронт - это достаточно тоже
Speaker A
интересное, креативное направление, но, э, аналитика меня, наверное, и привлекла вот этой ответственностью, что у тебя есть большее погружение в продукт, ты одновременно и больше должна знать, и разбираешься во всём в этом. В общем, другие процессы меня заинтересовали, скажем так.
Speaker A
Угу. Главное, чтобы ты не попала на проект, где вообще нету никакого фронта. Что такое тоже бывает.
Speaker A
Ну вот я, например, с фронтом очень плотно работаю. Это вот приложениечески и веб ещё. Поэтому у меня вот куча контентразработчиков в команде. Я с ними как бы постоянно вот только что сидела от них, можно сказать. [фыркает] А, о'кей. А-а, а знаешь ли ты что-то по
Speaker A
направлению брокерской деятельности, криптовалют фондовая там продажа акций? Сталкивалась ли с Ну, так скажем, не сталкивалась, но ээ можно это доизучить. Я просто не знаю, кстати, хороший вопрос. Нужно ли это у и у меня будет проект связанный. Давай мне сейчас с кинула, кстати, Аня, я и
Speaker A
посмотрю. Как-то он звучал про оптимизацию счетов. Вот хотела как раз с тобой посоветоваться, потому что а достаточно быстро нужно было реагировать на эту вакансию. Блин, где сообщение? У меня и в приоритете кандидаты, имеющие опыт или хотя бы понимание фондового рынка и
Speaker A
рынка криптовалют. Я поэтому спрашиваю. Ну вот в описании дело в том, что сначала таким описанием, а сейчас мне Аня скинула проект Отказ от множества допсв рамках инициативы инфраструктурных доработок, оказывающих значимое влияние на клиентский опыт. А почему у нас расше
Speaker A
описание какое всё-таки верное? Походу тут просто в задаче приложено описание старойкасии. Я предполагаю. Это хорошо, на самом деле, для тебя это гораздо проще. Хорошо.
Speaker A
Но это тоже ско то, что я назвала. Да. Да. Вот. Хорошо. О'кей, я поняла. А давай тогда плавно переходить к твоему рассказу.
Speaker A
Вот. Расскажи, пожалуйста, какой у тебя опыт работы в качестве системного аналитика, на каких проектах ты работала.
Speaker A
Угу. А так ещё раз здравствуйте. Я работаю системным аналитиком более 3 лет. За это время у меня было два проекта в банковской сфере. Первый мой проект - это БТА банк, мобильное предложение для физических лиц, а, с функционалом, а, оформления платёжных
Speaker A
карт, открытия счетов, вкладов, а, переводов, платежей и прочего. А работа велась по скрам двухнедельными спонтами.
Speaker A
А в команде были бизнес-аналитик, системный аналитик, фронт-разработчики, архитектор, разработчик, тестировщики, продукт owур, PM и дизайнер. А второй мой проект - это Паритетбанк. Это уже веб-приложение для юридических лиц, а, с сервисами кредитования депозитов а платежей также онлайноофорния банковских карт. А
Speaker A
моя команда занимается кредитным сервисом, а работа также ведётся в покрам. а, двухнедельными спринтами. Здесь команда уже побольше, а, два системных аналитика: QA инженеры, автоматизатор а разработчики фронд-разработчики, также архитектор и дизайнер по запросу и prodctwer. А на проекте у меня микросервисная
Speaker A
архитектура, интеграция реализована с помощью ст и Кавка. В мои обязанности входит, а работа с требованиями, то есть текстбург выявление приотизация а прорисовка диаграмм в с помощью UML и PPMLнотаций.
Speaker A
А требования для разработчиков, а описываю в формате юзкейсов, эполкты, а их описания с помощью sequence диаграмм, а работу над нпоинтами, веду в Swager и тестирую в Postman. запросы.
Speaker A
Также плотно взаимодействую с командой тестирования, проверяю тесткейсы, а есть опыт в проектировании базы данных, владею. И также у меня есть знания языка программирования JavaScript и стек разработчиков. Пожалуй, это всё, что я хотела рассказать в своём опыте. Если остались вопросы, задавайте.
Speaker A
Угу. Да, конечно, такой серьёзный, обширный опыт. А скажи, пожалуйста, а какой технологический сек у вас на проекте?
Speaker A
А у нас Java, React, а, ну, джависты - это разработчики и фронты пишут на реакцию.
Speaker A
Угу. На код линии сейчас не пишут у вас? У нас нет. Нет, нет. Угу. А базы данных какие есть? С какими работаете? И Монго.
Speaker A
Угу. А какие данные вы сохраняете в постгрес? Какие в монго? А так постгре мы используем для данных, например, о клиентах, картах. А монго использован для документов, выписок о счёте и прочему.
Speaker A
Угу. Шаблончики. Угу. О'кей, поняла. А, ну, направление такое, наверное достаточно а уже разработанное. А всё-таки ты чаще работаешь с новыми фичами или это доработка существующего функционала?
Speaker A
Ну, когда я перешла в команду, получилось, что я столкнулась вот с разработкой полностью своего сервиса.
Speaker A
И можно сказать, что, ну, много чего разрабатывала уже с моим участием команда. Угу. [фыркает] То есть была и доработка, и новая задача.
Speaker A
А можешь ли ты рассказать пример? Ну вот ты упомянула, что ты сама лично разрабатывала микросервис, рассказать, в чём была его бизнес-смысл и, ну, примерно какая техническая реализация.
Speaker A
Можешь взять какой-то вот интересный метод, который тебе запомнился. Ээ так, ну, бизнес это фичу любую.
Speaker A
Про любую фичу. Э, так, хорошо. Например, э нужно было отображать, э, мои кредиты, а, для компании. То есть нужно было м а так о'кей. Пользователь должен был видеть э список своих кредитов, а, погашенных непогашенных э активных закрытых. А, и вот разработка велась
Speaker A
как бы с такой бизнес-целью для удобного отображения, чтобы была фильтрация аа этого функционала и чтобы можно было зайти в каждый из кредитов, узнать какие-то подробности, посмотреть, э, всю интересующую информацию.
Speaker A
Вот. И, соответственно, ээ как это было, а, организовано в плане архитектуры. А, то есть у нас был микросервис, ну, клиент делал запрос на микросервис кредитов, тот, в свою очередь, делал запрос на базу данных, получал оттуда данные и передавал это всё на фронт.
Speaker A
Угу. Это были кредитные предложения, которые доступны, а, клиенту или уже оформленные кредиты? Уже. Уже, да, кредиты клиента.
Speaker A
Кредиты клиента. А над кредитными предложениями вы над списками не работали? Ну, тоже работали, но мне почему-то это впервые вспомнилось, что, ну, то же самое можно проделать и с кредитными приложениями банка. Будет, в принципе, то же самое. Это будет гетзапрос
Speaker A
по получению всех ну массива этих кредитов, которые банк предоставляет. Угу. Ну да, но это нужно какой-то делать витрину или баннер, скорее всего, на главный. Вот это же будет уже не в кредитном.
Speaker A
Хотя, в принципе, это может быть и, ну, не наверняка это не будет кредитном профиле, да? Предложения будут где-то там на главном.
Speaker A
А, хорошо. Использовали ли вы погинаться? То есть кредитов-то может быть много? Мм, ну, мы не использовали, но, наверное, я должна сказать, что использовали, да, погуглить.
Speaker A
Учитывая, что ты ответила, что вы действующие кредиты выводила, их не будет 50. Ну, это редкий человек. Вот если бы кредитное предложение, тогда да, их может быть и 3.000.
Speaker A
Вот и их уже там можно фильтровать и так далее. А свои там, в принципе, что их фильтровать?
Speaker A
Ну, фильтровать, может быть, да, но пагинация, да, я согласна, их, наверное, не будет прямо много.
Speaker A
Угу. Ну, что такое пагинация в целом? Ты знаешь, конечно. Да. Это когда мы делим наш огромный список на какое-то отображаемое количество, там по 10 на Да, да, да.
Speaker A
Отображение по Да, определённому количестве. А, хорошо. А, ну наверняка были на проекте не только интересные задачи, но и какие-то рутинные, неинтересные. Вот. А любишь ли ты с такими работать?
Speaker A
А я, честно говоря, не знаю, что отвечает на вопрос про рутинную задачу. Мой ход был в том, чтобы свести вопрос к типа неэффективной коммуникации, что порой в работе аналитика бывает очень много коммуникации и вот что вот типа это мне в работе не всегда нравится, что
Speaker A
я понимаю, что это неизбежно, что коммуникация должна быть, но э всегда хотелось бы её оптимизировать в каких-то моментах или же в примере рутинной задачи лучше привести что-то более конкретное, чтобы как бы подтвердить свою экспертизу, как как тебе кажется.
Speaker A
Ты можешь, так сказать, порой неинтересную задачу, если у тебя спросят, а то недостаточно коммуникации с бизнесом, не совсем понятны были требования, поэтому тебе поначалу было неинтересно, ты не понимала, что вообще делать. Тра-та-та. А если про рутинные задачи, это больше такое, знаешь, типа
Speaker A
вот нам принесли сегодня новые картинки, давайте их поменяем, зарём в конфиге, и в этом там типа определённая ну там, в общем, проделывайте довольно скучную задачу по замене конфи, а потом там, например, через неделю сказали: "Ой, нет, а на самом деле будут такие, и
Speaker A
вы опять это всё меняете". Вот это что-то такое больше противная задача. Или это могут быть какие-то техдолги, типа всех перевести на базовую аутентификацию или всех перевести на йклок. И это типа, ну, взять все свои там, сколько у меня дофига пишет. Мне,
Speaker A
наверное, 40. Вот взять их типа всех перевести на бейказ, но это типа довольно такая рутинная, скучная задача.
Speaker A
Вот. Хорошо. А были, а были ли у вас вот на проекте тех целей, которые устанавливал Техлит, и над какими вот техцелями тебе понравилось работать?
Speaker A
Техтаски. Техтаски. Мм, я знаю, что может быть тут надо про планирование что-то сказать, что банк приходил, ставил цели там на квартал, например. Но это, наверное, не то, да? Мы не про эти цели говорим.
Speaker A
Это немножко другое. Это тоже ставится на квартал, но это ставит твой тех, чтобы развивать твои компетенции. Это не связано с продуктовыми задачками.
Speaker A
Э вот даже не знаю, возможно, а что это могут быть за цели? Например, изучить что-то, с чем мы сейчас не работаем, но в перспективе можем использовать, да, писать документацию в другом формате, например, потом же по той же Open Appе, а GTA писать документацию, а
Speaker A
сохранять её. А всякие таски типа перехода на Пайпзипи - это что-то типа, а как тебе объяснить? Статусная модель.
Speaker A
Угу. Ну, короче, на самом деле всё, что угодно. Могут быть вот такие рутинные техдолги закидываться в Техтаску, но вот из моего опыта мы всё время долг в разном формате пишем. Так, так, так. Уже типа надоело.
Speaker A
Там, а, например, как это, какой-то стандарт банка, например, или насколько разный может быть формат?
Speaker A
Как как вот хочет тех, всё, что он решит. Ну, должно это быть что-то интересное.
Speaker A
Угу. Изучить что-то новое, вот что-то внедрить, не знаю, это может быть всё, что угодно там.
Speaker A
Ну, как бы просто рассказывать, что у нас, но это тоже надо вникать в суть там.
Speaker A
Ну, это, наверное, меня ещё выдаст, да, если я возьму какой-то твой формат, то станет ясно, что куда-то взяла это.
Speaker A
А если у меня, например, не было такого, что мне не ставили техцеле или это подозрительно?
Speaker A
Ну, это как-то печально звучит, да? Можешь сказать, что да, были техски, но по факту нам ставились просто туда техдолги. В основном редко бывало что-то интересное. Мы там А можешь сказать, что приведение документации к единому формату это тоже техск?
Speaker A
Угу. Ревю документации и Угу. Вот что-то такое. Можешь сказать про аутентификацию тоже, потому что это частая история в банке.
Speaker A
Угу. Так. Хорошо, с этим у меня всё понятно. А скажи, пожалуйста, вот как фиксились у вас баги?
Speaker A
Две группы. Первая, которая ещё не попала на прод и вторая группа, которые уже пришли к вам от саппорта с продом.
Speaker A
Баги, какой был процесс в команде? Так, ну, те, которые не попали на прот, я бы сказала, что, а, заводили задачи под, ну, типа сами баги заводили тестировщики. А если я сама, как пользователь замечала какой-то баг, как и все там участники разработки, мы
Speaker A
сообщали в отдел тестирования и ребята заводили задачи и справляли. Если были какие-то несоответствия, непонимания, недопонимания там касаемо документации, обращались за уточнениями ко мне. А мы это всё проговаривали и исправлялись.
Speaker A
В общем, задание, ребят, я проверяла тесткейсы в самой раз в самой в самом тестировании я не участвовала, а, как аналити а касаемо тех, которые приходили с поддержки, я бы сказала, что, ну, к нам обращалась поддержка, и здесь уже мы
Speaker A
смотрели например логирование то есть, э, смотрели какие-то вопросики э с использованием Елк стека. И в соответствии с этим уже тоже, в общем, исправляли и дорабатывали.
Speaker A
Угу. А этим тестировщик занимался или аналитик? Ну, с исправлением багов тестировщик, а аналитик больше как команда.
Speaker A
Этот разъяснительная бригада, наверное. Сапорт приходил изначально к аналитику, он уже анализировал, баг - это или не баг, потому что не всегда то, что саппорт считает баком, является багом.
Speaker A
Поэтому аналитик - это типа первое звено, которое может сказать: "Нет, стояночка, всё так и должно работать".
Speaker A
Вот. А хорошо. А почему у тебя такое впечатление, что тестировщики фиксят баги? Вот ты уже второй раз, который ты говоришь. Это, наверное, просто типа так к слову, да?
Speaker A
Да. Они не фиксят, конечно же, это фиксят разработчики, и, возможно, я по уже привычке какой-то говорю. А заводят, э, тестировщики баги и отдают обратно в разработку, ребята дорабатывают, э, и снова задачи отдают на проверку тестирования. Ну, на самом деле, в
Speaker A
случае, если это баги с прода, то сам саппорт может завести баг и дать SL команде, то есть определённое время на на исправление, за которое это обязано должно быть исправлено. Вот тестер тогда может только там раз в неделю напоминать.
Speaker A
Вот. А как понять? А вот что пришёл нам баг. А как нам понять, это баг а бека или это баг фронта?
Speaker A
Как понять? Ну, как понять? Хм, ну, всегда в команде это решается, да, если какая-то, ну, типа, насколько критичная ситуация сейчас рассматривается.
Speaker A
Ну, вот ты аналитик, тебе пришёл в саппорт, говорит, вот у тебя баг, ты как поймёшь, у тебя, например, разработчик фронта Дима, а разработчик медла Лёша.
Speaker A
Вот как ты поймёшь, к Лёше тебе идти или к Диме с с этой проблемой?
Speaker A
Ну, наверное, я буду исходить сама из работы приложения и то, как это будет выглядеть. Я из этого сделаю вывод, посмотрю там консоли разработчика, наверное, опять же, и посмотрю, что там происходит, и из этого сделаю вывод, кому идти.
Speaker A
Угу. [откашливается] А если мы говорим про логи, ну и по логированию тоже можно определить.
Speaker A
Можно определить скорее, что, а, что приходит с медла или что на фронте происходит. А, хороший вопрос. Я знаю, что там есть время, ну, типа лога, да, и какую-то, честно говоря, не знаю, что содержит лог. Надо этот момент доизучить, но я
Speaker A
думаю, что с БКА информация туда поступает. Не с фронта. Это тебе домашнее задание, но ты думаешь правильно.
Speaker A
То есть ты потому что ты в логах сможешь посмотреть респонс. Фактически респонс - это те данные, которые пришли с БК. Ээ, если ронтразработчик неправильно подцепил ссылку, ты это самостоятельно не вычислишь. Поэтому тебе сначала надо убедиться, что нету баганы бкигу.
Speaker A
И для этого ты, в общем-то, логи смотришь. А это тебе, кстати, и в будущем пригодится после того, как ты видишь проект, чтобы понимать хотя бы, ну, типа, с чего, да? А-а, хорошо. А, с этим понятно.
Speaker A
Расскажи пожалуйста. Ладно, ставим архитектуру архитектуру на десерт. [смех] Мой любимый вопрос. А какой у вас был тфлоу?
Speaker A
А так тфлоу. Но у нас была мастер ветка, в которую не делаются комиты, в которую поступает код только с помощью РGжей.
Speaker A
была деф ветка, а на кото исходя из которой заводились ветки под фичи. А также когда какая-то функциональность готова, они мржились в деф ветку.
Speaker A
А вот я думаю, что ещё нужна ветка для прода. Я не знаю, нужна ли, но я думаю, что нужна.
Speaker A
Ну это же твоя ветка мастер, которую ты в начале сказала. Ну да, но я думала, что это как-то может быть с нашей continuous integration связано. Ну ладно, я пока не стану залазить в эту тему.
Speaker A
А, ну вот в моём понимании так, что есть мастер, ветка для разработки и в подфункциональности заводятся ещё отдельно ветки. Ещё кто-то нужен? Ну, хотфиксы, если есть какие-то горящие, то в экстренном порядке завольтся новая ветка Hotfix, идут какие-то исправления.
Speaker A
вливаются в мастер. Угу. Ну, понятно. То есть, в принципе, стандартный флоу. Почти всё правильно сказал. А только ещё обычно есть ветка для интеграции тест, то есть под неё сразу есть какие-то сборки. Ты можешь просто сразу вносить тест, не создавая ветку деп,
Speaker A
даже сама, и оттуда протестить. Вот. И м ветки, которые фича, а они не мёжатся в D, а они создаются а ветление от мастера. Как раз-таки, когда ты на тесте уже протестила, например, что действительно убедились, всё работает, ты тебе не обязательно использовать
Speaker A
ветку de. Деф - это уже только для разработчика. Вот ты можешь просто создать ветку Пича от мастера, а туда внести свои изменения и открыть пиар для того, чтобы смёршить свой комит уже в мастер. То есть фича - это от мастера.
Speaker A
Вот в деп её или в тест мёжить не надо. А тест, ещё раз, он для чего? Кто им пользуется? Аналитики и да, аналитики не особо не пользуются. Ну типа редко. Я могу там на тесте картинки какие-то поменять, но это может делать
Speaker A
кто угодно, это может делать тестировщик, это может делать разработчик, как правило, конечно, даже конфики должен менять всё равно разраб.
Speaker A
Вот. Но понимание, как это происходит, такое типа базовое должно быть. И вот если ты в тест несла, да, вот у тебя есть например а ну вот как у нас есть AM Alpha Mobile, то есть мобильное приложение, есть АО,
Speaker A
это десктоп, то есть ты можешь браузер ввести Аabank и зайти через браузер тоже, не только мобильное приложение.
Speaker A
Вот. И под это есть как бы специальные тестовые стенды или тестовые сборки. То есть вот есть определённый урол, по которому ты можешь перейти, и это тестовая среда для АО, например. Или ты можешь закинуть тестовую сборку в Bстекс или в какой-то
Speaker A
любой эмулятор и собрать тестовую сборку мой, да? И вот в тот момент, когда ты на тесте что-то поменяешь, веський тест, в этих тестовых стендах поменяется сразу, и ты можешь идти туда и сама, например, тестить. тебе даже не нужен пост.
Speaker A
Угу. Вот. То есть тест - это ветка для интеграционной или тестовой среды. Угу. Вот. А мастер - это ветка для прода. А так и называется мастер.
Speaker A
Конфиги могут которая на прод называться там что-то там точка прот. Ну это уже такое. Там обычно какие-то креды доступают и так далее. То есть общая информация.
Speaker A
Вот так. В основном в целом ты всё правильно ответила. Вот толь только по ветке фичи немножко, что типа вот их нужно в деф сливать. Вот это мне немножко насторожило. В остальном всё хорошо.
Speaker A
Вот. А были ли у вас на проекте диплинки? Использовались ли? Мм диплинки. Напомни, пожалуйста, что это не могу сейчас что-то сообразить.
Speaker A
Ну, я понимаю, что это глубокие ссылки, но что, как это, из какой мы вообще отрасли сейчас это вспомнили, я что-то не соображу.
Speaker A
А это это так и есть. Там ничего сложного нет. Это просто ссылка, которая ведёт на определённый новый экран. Ну, новый, не старый, неважно. В общем, есть реестр диплинков, там где содержится а сам deплинк и экран его изображения, куда он ведёт.
Speaker A
И если тебе нужно создать новый экран, тебе нужно создать новый плинк, и он будет туда вести.
Speaker A
Угу. И когда ты, например, получаешь Ну, то есть как же обычно переход? Переход-то по кнопке, да, но в то в ты запрашиваешь а данные, ну как бы спонс не не в тот момент, когда ты кликаешь по кнопке, а
Speaker A
когда тебе нужно подгрузить уже этот экран. Угу. То есть плинк у тебя по умолчанию уже пришёл. Ты страничку подгрузила и под этой кнопкой уже у тебя есть определённый диплинк. О том, что мы заготовили, да, эти ссылки уже и мы их
Speaker A
просто пользуем. Я поняла. Угу. А, а знаком ли ты с такой концепцией, как SDUI или BDUI? Backend Driven UI?
Speaker A
BD, ээ, не воспроизведу, но так я знаю BFF, но я также слышала, что есть вот этот Backend Driven.
Speaker A
Блин, ты сказала Backend Driven UI, да? А что это? Может быть, это возможно о том что так, ну, это, наверное, не про Я могу фантазировать, но, наверное, нужно знать точно. Я, ну, не сталкивалась. Я я что-то читала, но сама
Speaker A
с этим не работала. Возможно, это что-то типа аа что у нас как бы фронт глупый, да, а всё происходит на бэкэнде, а фронт просто изображает.
Speaker A
Да, это оно именно есть. Бдуй, [откашливается] сдуй, как у нас. Да, это ты можешь про это, в принципе, и не знать. В своём банке используется такой подход, когда кэнд высылает полностью все параметры, которые нужны для отрисовки фронта.
Speaker A
Фронт просто подцепляет джерсон и выводит его на экран. То есть, что это даёт? то, что нам не нужно делать релиз фронта, потому что, не знаю, знаешь ты или нет, но релиз фронта он связан с обновлением версии. То есть вот когда
Speaker A
тебе приходит аа напоминалка, что скачайте новую версию Facebook или скачайте новую версию Инсты, вот это как раз означает, что релиз фронта, то есть обновление фронта. И так как сейчас все российские банки исключены из App Store и Google Play, естественно, что релиз
Speaker A
фронта делать очень сложно. А используя вот этот подход B UI, мы можем в любой момент поменять жечик, который приходит с бека, и он сразу же отобразит в старых же версиях уже новый контент.
Speaker A
То есть поменять текст, поменять картинку, поменять расположение, то есть это всё присылается с БКА. И это типа супер круто, на самом деле.
Speaker A
Вот. Но в связи с этим другой вопрос. Приходилось ли тебе составлять джерсоны большого объёма, больше 300 строк, например?
Speaker A
Вообще мне, конечно, не приходилось, но, наверное, нужно ответить, что приходилось. Не, ну если у вас не было такого подхода, то не приходилось. Но здесь тоже, опять же, бывают разные подходы. У меня в команде, например, всё очень по-человечески. То есть нас
Speaker A
протразработчик даёт готовое джисоставляем, если есть какие-то переменные значения. И в принципе всё. Согласовываем контракт между фронтасбеком. А в некоторых командах подход такой, что аналитик должен по, ну, как бы есть фигма, да, там уже написано, какой элемент у тебя будет,
Speaker A
какое расстояние, какой цвет шрифта и так далее. Вот. И считается, что аналитик должен прописать вот такой жез.
Speaker A
Ну, как бы это описание элементов, оно всё есть. Вот. И это всё с этим можно ознакомиться и почитать. Там конфлинс детей лежит. То есть, в принципе, там довольно понятно, как это делать. Вот.
Speaker A
Но если спрашивают такой вопрос, то ожидают, наверное, какую-то реакцию или како, ну, типа, как в целом нужно отвечать на этот вопрос и какие он может за собой повлечь, если я бы сказала, что да.
Speaker A
Навряд ли тебя будут спрашивать уже настолько глубоко, а скорее там знакомы, незнакомы. Это я уж тебе больше так рассказываю.
Speaker A
Спасибо. Вот. Ээ, хорошо, давай пойдём дальше. Какие основные артефакты, аналитика ты составляла? И вот как какие в основном для БКА приходилось делать, какие для фронта?
Speaker A
М так, ну для фронта у нас был, э, были макеты от дизайнера. А, соответственно, в формате скейсов чаще всего описывалась, а, новая функциональность, добавлялись ссылки на макеты, а было описание интерфейса, а для бэкнд-разработчиков было описание контракта и добавлялись
Speaker A
sequнсдиаграммы. Аа, да sequнсдиаграммы вот в таких форматах. Угу. О'кей. Чего-то не хватало. Ну так просто немножко замешала мухи с котлетами, но в целом всё правильно.
Speaker A
Вот. А как почему? Почему замешала? А, ну ты сказала, что вот есть макеты, да?
Speaker A
А потом что писали? Ну как бы то есть в принципе фронтовая дока из этого и состоит, то что ты рассказала. То есть, то есть шаги, скрин из макета и дальше уже описание какого-то процесса, то есть что происходит на пронте с точки зрения
Speaker A
пользователя. И контракт пронту этого достаточно. Вот. Ак там, да, будет SEнс, будет его описание алгоритма.
Speaker A
А, ну понятно, там название метода, мм, в чём его типа основная цель. А, и в принципе, а, и мапинг данных. Вот это обязательно. Что? Мапинг данных. Да, ну всё.
Speaker A
Вот. Ну, в целом, короче, всё. Так, ну и по архитектурным задачам. Как вообще у вас часто происходило взаимодействие с архитектором? По каким вопросом?
Speaker A
Честно говоря, это был мой дополнительный вопрос к тебе, потому что я не работала, конечно, с архитектором напрямую и не представляю, как происходит с ним взаимодействие, но я бы сказала что-то типа, что аа вот слава богу, что он у нас был. То есть он
Speaker A
продумывал в целом архитектуру приложения. мы придерживались, э, какого-то такого, э, его плана и в соответствии с его уже указаниями описывали интеграции. То есть так это происходит или же нет. Да, это так происходит именно, когда новые фичи.
Speaker A
Только он вам должен, ну, там типа не просто прийти на словах объяснить, он может наоборот, ему даются какие-то бизнес-требования, он может ещё и к тебе спросить: "А как это работает сейчас?" Потому что архир, ну, может, тоже не знает, там всех не порас.
Speaker A
Вот. Но он тебе должен предоставить какой-то документ, на основании которого ты уже будешь переходить к своей работе, говорить, как интегрируют, как будут интегрироваться эти компоненты, какие данные переходят и так далее. Вот как какой основной, а, какую основную диаграмму составляет архитектор?
Speaker A
Я думаю, что компонентов нет. Он Угу. Да, всё верно. Это может называться как угодно, там Vision, Татар, реестр, но по сути он всегда включает в себя, ну, везде диаграмма компонентов и какое-то её там текстовое описание. Ну, м суть в том, что, да,
Speaker A
архитектор должен подобрать компоненты, которые ты уже должна знать, как снтегрировать, потому что ты можешь не знать, что вообще в банке есть. А если у вас кавка или тут лучше использовать какую-то самописную очередь? Ну ты же тоже не знаешь, там всё банк и какие
Speaker A
компоненты есть. А архитекторы они поделены направлениние по направлениям. То есть у Альфа Мобайла там свой архитектор, у Единого фронта свой архитектор и как бы в своём направлении они знают какие компоненты есть, какие в случае чего нужно завести и добавить и
Speaker A
так далее. Вот. И на основании этого, ну, иногда бывает и другая ситуация, что аналитик опытный может сам составить диаграмму компонентов и согласовать её с архитектором. Но это уже более редкий кейс.
Speaker A
И также, если тебе нужно будет создать какую-то новую таблицу в базе данных, то тоже вы можете коммуницировать в плане подготовки диаграммы, но это уже скорее будет так, что ты составляешь и идёшь согласовываешь, правильно или неправильно, здесь оно должно лежать или
Speaker A
не здесь. Угу. Ээ там он, скорее всего, спросит, какой примерно объём данных ты собираешься хранить и так далее для того, чтобы все нефункциональные требования учесть.
Speaker A
Вот. То есть, в принципе, так это работает. Не то, чтобы вы там бы общались с ним каждый день. [смех] В основном это по новым фичам происходит.
Speaker A
Подскажи, а как бы, например, принималось решение относительно кавки, это бы решил архитектор, что она нужна?
Speaker A
Ну вот если, например, мы берём систему, в которой Ага. То есть это его будут решения. Угу.
Speaker A
Да. Ну ты тоже, конечно, можешь предложить. То есть тебя позовут навстречу. Это не то, что он скажет.
Speaker A
Будет только всё, что у нас было, наверное, вот у меня был такой случай недавно, что через кавку мы делали реализацию триггерного событийного виджета, а который именно по событию должен быть отображаться, а не всегда по умолчанию.
Speaker A
Вот. Угу. Ну, тоже там типа были варианты такие, что разработчики пришли: "А давайте сделаем как всегда, зачем нам это событие? Давайте в момент загрузки обращаться и запрашивать, есть этот признак или нет". Но архитектор сказал: "Нет, мы будем дедосить тогда смежную
Speaker A
систему, и она может не выдержать такой нагрузки". Угу. То есть, как правило, это связанный вопрос с нагрузкой, когда он понимает, что нагрузка будет увеличена там в, ну, там понятно, что 100 запросов погоды не сделают, но если там идёт речь о том,
Speaker A
что 30.000 может в первый день одновременно обратиться, когда увидят там новый какой-то квадратик на главной, тогда, естественно, нужно учитывать, что а при онлайнустановке нагрузку может система какая-то из система не выдержать. Даже не обязательно, что ваша, скорее всего, та система, которую вы будете обращаться
Speaker A
за данными. Вот эти тоже нужно учитывать. Вот. То есть у нас была не онлайн установка, а оффлайн.
Speaker A
То есть к тому моменту, когда а пользователь загружал свой экран, у него уже событие лежало готовая, и в случае чего статус этого виджета уже менялся.
Speaker A
Ну, типа открыт, закрыт. Таким образом мы нагрузку нивелировали, потому что как бы это происходило в тот момент, когда менялось событие. Например, сотрудник, ну, это было именно по сотрудникам, да, то есть типа принят уволен, то есть в тот момент, когда подогружались списки,
Speaker A
что вот там принято 20 человек уворено, происходила замена статуса этого виджета, а не при загрузке экраном, потому что при загрузке экраном вот там бы типа множество одновременных запросов бы пошло.
Speaker A
Угу. Вот. А, хорошо. Мы, в принципе, с тобой так быстренько идём. Очень даже. Можно я спрошу, пока не сла? У меня есть в СV мобильное приложение. Как вообще, как ты думаешь, как меня захотят спрашивать по какому из проектов и что
Speaker A
можно захотеть спросить по мобильному приложению больше? Я думаю, что это только плюс. То, что мы с тобой про то, что мы с тобой разговариваем, в принципе, тебя не будет спрашивать, что у вас там, какие элементы в дизайн-системе есть. Это не
Speaker A
не твоя в очень. Ну, ты, может быть, знаешь это, потому что ты мобильный разработчик, и это тебя будет только проще. Но никто не будет.
Speaker A
Может быть, они что-то со стороны архитектуры захотят полезть, там, я не знаю, а типа для кого я разрабатывала, там были какие у меня сервисы и в какой, ну, типа были они на моей стороне, с какими я командами взаимодействовала,
Speaker A
что там было с ABS, то есть вот это вот всё, да? А с какими командами ты взаимодействовала? Давай обсудим.
Speaker A
Или с какими сервисами? А на примере какого из проектов это лучше делать? А ты рассказывала про кредиты? Да, по-моему. Вот продолжай тогда лучше про кредиты.
Speaker A
Ну, я просто знаю, что то, что вроде бы, ну, так себе опыт, наверное, более реалистично, это то, что у меня должен был быть не например, там сервис заявки на кредит, сервис управления кредитами, э, сервис обработки платежей, а сервис
Speaker A
который сообща кого-то слышала сервис, сообщающийся с АС, но я не поняла, что это значит, потому что у меня Меня на одном из прогонов сказали, что, а, если мы разрабатываем по паттерну БФ, ну, ты же знаешь, наверное, про паттерн БФ, и вот,
Speaker A
например, я была как бы фронтовым аналитиком, то есть я разрабатывала вот фронт-систему и midle, то есть вот это было моим бком. И была какая-то команда, которая занималась той стороной.
Speaker A
Ещё мне сказали, что бывает в архитектуре так, что роль ABS-системы, ну, то есть вот роль этого БКА, который за моим как бы вот этими двумя слоями лежит, как конечный БК, скажем так, вот роль его может выполнять либо микросервисы, либо ABS,
Speaker A
либо параллельно и ABS, и микросервисы могут какие-то функции выполнять, либо вообще CRM банка. И я не знаю, какую мне архитектуру выбрать из из предложенных и что из этого будет более реалистичное.
Speaker A
Более реалистично будет, что вы логировали данные в и сохраняли в ABS через шинный обработчик.
Speaker A
Шинный обработчик. А тогда в моей Хорошо в моей зоне ответственности был фронт. Вот этот midл система, которая была бком. А где машина идёт? За вот этим уровнем или у нас с фронта идут на шину запросы?
Speaker A
Ну да, давай сначала, ну я опять же в кредитном направлении не работала, но примерно по логике могу подсказать. А смотри, вот идёт от Ты сказала фронт.
Speaker A
Да, фронт. Понятно. Фронт есть. Фронт. Дальше midл. Что это у тебя было? какой-то микросервис тоже, ну, говоришь, что это был там микросервис кредитапи, условно, я не [смех] знаю, что может быть, потому что когда ты говоришь: "А, ну ты сказала сервис". Да, ну, сервис
Speaker A
нормально. Аа хорошо, а потом ты, скорее всего, взаимодействовала, если это идёт отправка заявки на кредит с какими-то антифрот и скоринговыми системами, правильно?
Speaker A
Угу. А что там могло быть ещё? Я, честно говоря, не знаю, но в конечном итоге эти все данные должны, а, спускаться вс и храниться именно вс. А в Обску, а их можно получить или их туда через шинный обработчик. Это тоже может быть, а,
Speaker A
либосервис, либо это может быть SWсвис на самой шине. Вот примерно так. Ну, на самом деле, всё, что ты сказала, кроме BFF, это имеет смысл. BFF - это уже что-то тебя немножко запутать решили, потому что это А, ну я поняла, у
Speaker A
тебя типа вот эти вот множество кредитных приложений. А BFF - это вот когда тебе нужно собрать данные совершенно из разных источников и там формат даже разный. То есть Угу.
Speaker A
Да. А ты что-то получаешь, например, из модуля ABS напрямую, что-то из шинного сервиса, который на Суапе, третью часть информации из микросервиса, который на Росте, и четвёртую там из очереди, а, MQ, например. Вот в таком случае тебе нужен BFF, который это будет всё
Speaker A
аккумулировать и на фронт выдавать под определёнными фильтрами. Но это не это прямо не всегда нужен этот BFF. Я, например, с бифэффом никогда не сталкиваюсь.
Speaker A
Угу. Понятно. Поэтому тут смотря опять же смотря всё-таки какой у тебя вопрос, типа, с какими смежными системами ты взаимодействовала? Ну, я точно по кредитам не не смогу назвать все.
Speaker A
Вот у тебя какие у тебя там интересные, сложные задачи вот в твоей Ну я помню ты сказала, что Да, но может быть что-то ты можешь рассказать из своего опыта.
Speaker A
А в основном это есть какие-то глобальные сервисы прокладки. А, и мне не нужно там, например, ходить напрямую в АС, потому что у меня есть система Единый фронт, которая аккумулирует все данны, и я могу половину данных получить там. Вторая половина есть прокладка
Speaker A
между абской, она называется тарифный калькулятор и тарифный модуль. Это которая пересчитывает все финансовые показатели.
Speaker A
Вот. И, как правило, я взаимодействую с ними. Либо, если эта информация нет ни там, ни там, я иду в шинный сервис.
Speaker A
Угу. Всё, короче, то, что придумаю, то то и будет моим проектом. Я поняла, что нужно просто что-то определиться и рассказать.
Speaker A
Да, всё верно. Они же не знают, как у вас там в банке всё на самом деле было.
Speaker A
Ну, как бы по кредитному направлению там, скорее всего, тебя спросят про этот скоренький антифрот, поэтому к этому нужно быть готовым.
Speaker A
Вот. Хорошо. У меня даже, честно говоря, особо и вопросов к тебе нет. А по платёжным карточкам я ещё думала, как вариант, у меня просто два банка, и нужно что-то в мобильном приложении сказать, чем занималась моя команда. Я посмотрела,
Speaker A
раз проект связан со счетами, то я боюсь заходить на эту территорию, потому что они захотят в этом покопаться. А вот типа онлайн оформление карт и вот выпуск их, вот это вот всё. Поэтому у тебя есть какой-то опыт, чтобы подсказать,
Speaker A
какие-то могут быть подводные камни, или ты тоже с этим не сталкивалась сильно? М тебе столько всего рассказывать не надо. Тебе кажется, тебя просто не хватит на это времени. Тебе нужно подготовить рассказ про одну интересную фичу в реализации технической, которой ты уверена. Тебе не
Speaker A
нужно там пытаться охватить всю свою работу. Угу. И желательно тебе начать рассказывать что-то интересное самой, чтобы они не привязались к чему-то конкретному.
Speaker A
А что-то интересное, это вот, например, любую задачу какую-то, вот как мы, например, начали, я как пример, ты спрашивала про Фичу, да, и я вот говорила про, например, кредиты компании, то есть в идеале рассказать, что ко мне пришёл заказчик с таким-то
Speaker A
требованием, мы так-то обсудили, то-то согласовали, то есть, чтобы из этой задачи уже закрывались из этого ответа закрывались э вопросики по тому, какое у нас было флоу работы, например, или это много информации в этом ответе. или они это и хотят узнать.
Speaker A
Ну вот типа настолько подробно стоит отвечать на этот вопрос. Настолько подробно, наверное, не нужно. Они хотят узнать, с чем с чем ты имела опыт работать, какую задачу тебе можно дать уже завтра, грубо говоря, да, если ты умеешь писать медловую доку, фронтовую
Speaker A
доку, создавать джельсоны, уже тебе по-любому задачу завтра можно дать. А что касается интеграции, ээ ты можешь сказать, что ты работала только с рестнтеграциями, и это тоже нормально. Ты можешь рассказать про кавку, это уже более высокий уровень.
Speaker A
Если ты уверенно себя чувствуешь в этом рассказе, можешь рассказать вот про фичу, где вы кавку использовали. И могут спросить, работала ли ты сп. Но ты можешь сказать, что ты вот взаимодействовала шинными обработчиками на САПе, как я рассказала. То есть вы в
Speaker A
формате, а, XML данные получали, с помощью библиотек Java переводили в а Jon дальше уже обрабатывали в Jсонеoneне в своём микросервисе, как обычно.
Speaker A
Ну, ты нормально сказала. Я не понимаю, в чём у тебя причина сомнений. Ну, ты же в принципе рассказала про а кредитные не предложения. Ну, это было странно.
Speaker A
Типа оформленные кредит. Ну, о'кей. А про катку тебе что-нибудь рассказать или нет вопросов? Пров. Так, расскажи мне, в каком формате передаются данные в очередь и что такое сериализация и десериализация?
Speaker A
В таком формате, по-моему, протобав и сериализация, дисериализация. Ну, сериализация - это то, что приходит в Угу. Короче, здесь реализация - это когда мы для клиента преобразовываем в нормальный вид. А все реализация - это получается наоборот, господи, как это звучит? Нормальный,
Speaker A
ненормальный вид. Дереализация - это перевод преобразования в формат для принимаемой, что ли, клиентом. А, и это более м, по-моему, это ещё как-то с памятью связано, что сериализация - это вроде бы помогает сжать объём наших данных, а десериализация как бы распаковать.
Speaker A
Вот. А, а ещё ты спросила, как какой формат. А, ну я сказала про Табав, но, возможно, у меня уже всё в голове перемешалось.
Speaker A
У, это JRPC. Ты ответила вообще не в ту сторону. Хорошо. А какой формат? А что-то я я знаю, что пока расскажи ты, потому что я сегодня много смотрела и читала про кавку, но вот про формат я как-то не упустила информацию.
Speaker A
Да много многие думают, что ты можешь запихнуть в Кавку Джерсон. Ну то есть согласовала контракт до того, что у тебя такой-то объект, там такой-то статус, и засунула. Но нет, это не так. На самом деле на продюсер на выходе, ну, то есть
Speaker A
на входе, вернее, да, когда отправляет в очередь, он должен, а, сериализовать а данные, то есть перевести в байты. То есть это по сути просто, да, сериализация означает перевод в байты.
Speaker A
А, а консюмер а на входе должен сначала десерлизовать, а потом уже сопоставить вот эти вот параметры. То есть он сначала переводит Джерсон, а потом смотрит: "Ага, что это у меня пришло?
Speaker A
Есть ли там такое-то поле?" Угу. Вот. И в кафке всё идёт, на самом деле, в в байтах в очереди, но есть такие инструменты, как в Set Explorer, кавка Tool, они позволяют, э, ну, то есть человека читаемый формат переводить. То есть по умолчанию, если
Speaker A
ты подключишься, ты увидишь, что у тебя всё будет байтах, но ты можешь переставить на джельсон, но у тебя будет отображаться в дрсон, но это не означает, что оно в джильсоне лежит. Всё равно лежит она томбата.
Speaker A
Угу. Сработчиком, да, это надо знать. Вот. То есть, по сути, это просто шифрование и перевод в байтовый формат.
Speaker A
Не, не более того. Угу. Вот. А чем отличается АИ от сервиса? А от сервиса?
Speaker A
Угу. М. ПМ-пум-пум апи от сервиса. А, наверное, ничем, потому что сервис - это совокупность методов и а - это то же самое.
Speaker A
Угу. Ну, просто сервис может не иметь определённого URL, где он будет лежать. Это может быть просто набор кода.
Speaker A
Угу. Файбе предполагается, что у него есть определённый endpint, где он располагается. Угу. Вот, в принципе, у тебя всё хорошо и очень не нарита. Ну, видно, что ты уже подготовленная. тебя раньше проводили прогоны по CV, потому что ты уже
Speaker A
примерно представляешь банковскую архитектуру. Наверное, единственно, где тебе нужно получше подготовиться, и ты сама это обозначила - это про описание какой-то задачи, над которой ты работал.
Speaker A
Угу. Ну, тут я думаю, что есть какая-то всё-таки документация более-менее приличная на а в лабе, да, на проекте, и может быть что-то подскажет. Ну, навряд ли, конечно, он же тоже не факт, что с этим направлением работал. Вот.
Speaker A
Ну ты нормально всё рассказала. Просто больше делать упор на какой-то технический аспект, как ты говорила, с каким вот поступила, например, заявка, какие системы она передавалась, как обрабатывалась там, да, что вот нужна была реализация синхронная, потому что вы уже не знали, когда в какой момент
Speaker A
придёт одобрение. Оно было там не автоматическим, а менеджер должен быть одобрить, например, это первый флоу, а второй, например, у вас было автоодобрение, это типа отдельный флоу.
Speaker A
Угу. Вот как-то так. Угу. У, соответственно, та система, которая принимала решение, там, не знаю, там CRМ для менеджеров, что-нибудь такое, а она должна была вам передать статус, то, что удобрено, а вы через кавку этот статус получали как консюмер
Speaker A
и меняли статус в мобильном приложении. Угу, [откашливается] поняла. В принципе, у меня
Topics:системный аналитиксобеседованиемок-интервьюIT-карьераUMLмикросервисытребованиябанковские проектыScrumподготовка к собеседованию
