**ОФФЕР на 300к за 30 минут! Собеседование cистемного аналитика — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/offer-300k-30-minutes-systems-analyst-interview/

Мок-собеседование системного аналитика: вопросы по REST, HTTP-кодам, SQL, Kafka и проектированию. Разбор ответов кандидата и условия оффера.

## Key Takeaways

- Системный аналитик должен уверенно владеть REST-семантикой, HTTP-кодами и форматами API-контрактов
- Ключевой практический навык — проектирование идемпотентных операций и корректной обработки повторных запросов
- Собеседование демонстрирует типичный набор тем: API, SQL, брокеры сообщений, проектирование систем
- Качество ответов кандидата неровное: уверенно в артефактах, слабее в деталях Kafka и SOAP

## What the video covers

- Видео — запись собеседования на позицию системного аналитика с кандидатом, опытом 3 года в банковском финтехе
- Кандидат описывает роль: декомпозиция бизнес-требований, sequence-диаграммы в PlantUML, API-контракты и формат асинхронных сообщений
- Технические вопросы: различия PUT и PATCH, использование GET и POST, почему опасен DELETE, вложенные объекты и массивы в контрактах
- Разбор HTTP-кодов 404 и 409 и вопрос о том, где допустим автоматический retry
- Вопросы по SQL (джойны, группировки), по реляционным (PostgreSQL) и нереляционным (Redis, MongoDB) базам
- Блок про асинхронное взаимодействие, Kafka (топики, партиции, офсеты) и механизмы идемпотентности
- Задача на проектирование системы и обсуждение роли системного аналитика в команде и взаимодействия с заказчиком
- Обсуждение условий: срок отработки 14 дней по трудовому договору, задачи расширения проектов
- В видео есть рекламные вставки о платном обучении и Telegram-канале автора, не относящиеся к содержанию собеседования

## Chapters

1. 00:00 Начало собеседования и знакомство
2. 01:55 Опыт кандидата и артефакты системного аналитика
3. 07:00 Вопросы по SQL, REST и HTTP-кодам
4. 10:50 Асинхронное взаимодействие и Kafka
5. 19:50 Задача на проектирование системы
6. 27:00 Условия работы и обязанности
7. 32:40 Вопросы кандидата и завершение

Answers

## Questions about this video

Какой опыт и обязанности описывает кандидат?

Кандидат 3 года работал системным аналитиком в проекте автоматизации для банка по Scrum. Он декомпозировал требования на задачи, создавал API-контракты, sequence-диаграммы в PlantUML и частично выполнял функции Team Lead и PM.

Какие вопросы по HTTP и REST задавались?

Обсуждались различия PUT и PATCH, назначение GET и POST, почему небезопасно использовать DELETE, и выбор между кодами 404 и 409 для автоматического retry. Правильный вывод: retry допустим для 404, а для 409 — нет, так как он указывает на конфликт данных.

Какие условия работы обсуждались в конце?

Упоминался срок отработки 14–30 дней по договору, а также расширение проектов и рост команды. Заказчиками обычно занимаются руководитель проекта и бизнес-аналитики, а системный аналитик задаёт уточняющие вопросы по требованиям.

## Full Transcript — Download SRT & Markdown

00:05

Speaker A

Вот поэтому, если интересно, если думаешь дальше развиваться, буду рад тебя видеть в команде. Welcome on board.

00:11

Speaker A

Я понял. Спасибо. Всё, на связи. Ты молодец. Да, спасибо. [музыка] Я тебе сейчас напишу по дальнейшим шагам.

00:18

Speaker A

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

00:33

Speaker A

Здравствуйте. Можно на ты?

00:40

Speaker A

Добрый день. Да, можно без проблем.

00:56

Speaker A

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

01:16

Speaker A

А, ну, получается, последние три года в роли именно системного аналитика выступал в команде, проект по автоматизации формирования. У нас компания работала на банк, соответственно, это был домен финтеха в банке. Мы работали по Scrum, двухнедельные спринты. Состав был: четыре бэкенда, два фронта, два тестировщика, я системный аналитик, также бизнес-аналитик и со стороны банка архитектор. Он курировал несколько проектов, а также PM и Team Lead, что по большей части делал я.

01:34

Speaker A

Какие артефакты? Ну, соответственно, мне приходили по большей части бизнес-требования, возможно, какие-то критерии приёмки. Далее я декомпозировал эти требования на задачи на фронт, на бэк. Какие артефакты это могли быть? Различные: во-первых, описание функциональных и нефункциональных требований, в том числе если с интеграциями — это API-контракты. UML — это sequence-диаграммы. Также делал иногда BPMN, декомпозировал по user story, в основном задачи, иногда кейсы.

01:55

Speaker A

О'кей. Были ли интеграционные задачи с внешними системами, про API-контракт? Слышу, скорее всего REST, так как микросервисная архитектура?

02:11

Speaker A

Да, да, REST. Но ещё у нас была асинхронность, и я отвечал за формат сообщения. Я описывал, из чего оно состоит, откуда и куда идёт: кто у нас консьюмеры, кто продюсеры, что куда идёт и какой топик будет. Всё о'кей. Это сейчас тоже отдельно проговорим. Смотрите, что меня интересует: если было какое-то интеграционное взаимодействие, sequence-диаграмму рисовал?

02:30

Speaker A

Да.

02:43

Speaker A

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

02:56

Speaker A

Да, по большей части Plant UML, он там удобнее всего.

03:03

Speaker A

Лупы, альты, reference расписываешь?

03:15

Speaker A

Loop. Ну да, в принципе, было.

03:27

Speaker A

Угу. У нас просто сложное интеграционное взаимодействие, и у нас прямо sequence детализированы. Я просто сразу об этом говорю.

03:41

Speaker A

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

03:56

Speaker A

[музыка] Если ты хочешь прокачаться под моим руководством, приходи ко мне в Telegram-канал. У меня там есть бот в закреплённом комментарии. Начни с него, посмотри видео и приходи на бесплатную консультацию. Ссылка в описании.

04:13

Speaker A

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

04:24

Speaker A

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

04:32

Speaker A

Как дела с SQL, с селектами?

04:47

Speaker A

Селект, ну, как сказать, на уровне, ну, писали на уровне джойнов, группировок и сортировок.

04:56

Speaker A

На этом рука набита, правильно понимаю?

05:13

Speaker A

Ну, более-менее. Не скажу, что прямо суперчастый, мы пишем, но...

05:32

Speaker A

О'кей. Хорошо. Доступ к базе данных на текущем месте есть?

05:42

Speaker A

Да, ну, если надо, запрашивать.

05:51

Speaker A

Вот так. Давай по REST пройдёмся. Чем отличается PUT от PATCH запроса?

06:01

Speaker A

PUT, соответственно, у нас это полное обновление, и он идемпотентный, а PATCH — это не полное обновление, а обновление только части данных, и дополнительно не полное. Где данные в GET запрашиваются, где в POST передаются?

06:18

Speaker A

GET запрашиваются... ну, получается, это то, что в параметре, в URL, то, что мы в основном пишем, а в POST передаются в теле запроса.

06:36

Speaker A

Угу. Так, хорошо. Почему плохо использовать прямой метод DELETE в системе? По-моему, как-то грязное удаление, он не смотрит на то, используются ли там транзакции или нет, вроде. То есть с TRUNCATE, по-моему, оно сравнивается. Вот.

06:47

Speaker A

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

06:56

Speaker A

Всё правильно. Каскадное удаление данных у тебя по системе пойдёт.

07:09

Speaker A

Угу. Так, хорошо. Зачем используется объектная модель с массивами в контрактах?

07:26

Speaker A

Объектная модель с массивами, не совсем понял вопрос. Встречал, проектировал ли ты API, когда у тебя есть объект, внутри объекта есть массивы данных?

07:34

Speaker A

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

07:50

Speaker A

О'кей, хорошо. Я просто спрашиваю к тому, что писал: был ли такой опыт проектирования, потому что иногда встречаюсь, что некоторые ребята просто не знают, что такое объекты и массивы в API-контрактах.

08:07

Speaker A

Так, смотри, у меня есть 404 и 409 ошибки HTTP. Знаешь их?

08:23

Speaker A

Ну, 404 — это у нас не найден ресурс, а 409 — это, по-моему, конфликт методов.

08:31

Speaker A

Угу. Вопрос: у меня есть пользователь, у него есть... Он, допустим, пытается изменить какие-то данные в системе и на это получает 404 или 409 ошибку. Вопрос: на какой из этих типов ошибок можно сделать технический retry в системе, который не повлечёт дальнейшего взаимодействия с пользователем, например через техподдержку?

08:49

Speaker A

Так, автоматический retry. Угу. Он получает иногда и 404, и 409. Тебе нужно выбрать: либо на 404 сделать retry, либо на 409. На какую из них можно предусмотреть технический retry в системе?

08:53

Speaker A

А, ну, 409, логично, потому что в 404-м, получается, у нас, наверное, ресурса нет.

09:12

Speaker A

А, стоп, хороший вопрос. Подумай, подумай и ответь. Хороший вопрос. Да, сейчас нет, 409 — соответственно, у нас в целом что-то неправильно работает в системе, и это может привести к каким-то определённым последствиям, если у нас будут retry. А 404, соответственно, если не найдено, думаю, никаких последствий тогда не будет. Тогда, наверное, 404 retry.

09:21

Speaker A

Угу. Вот теперь правильно. На 404 ты можешь сделать retry, написать алгоритм в системе, cron-job какую-то, которая скажет: иди, сходи в другую табличку, обнови данные и переотправь запрос повторно, чтобы получить 200. А на 409 ты не можешь сделать этот retry, потому что ты не понимаешь, какие данные... Эти данные, которые пытается отправить клиент, уже есть в системе, и система не может создать дубликат. Поэтому она и пишет 409, конфликт, потому что у меня уже в системе лежат эти данные.

09:42

Speaker A

О'кей, хорошо, давай едем дальше. Работал ли когда-нибудь с протоколом SOAP?

10:05

Speaker A

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

10:16

Speaker A

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

10:32

Speaker A

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

10:43

Speaker A

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

10:55

Speaker A

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

11:05

Speaker A

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

11:17

Speaker A

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

11:26

Speaker A

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

11:42

Speaker A

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

11:59

Speaker A

А, ну хэш сумма понимаю, да. Ага. Ну так вот можно заложить. То есть, то есть зало, я понял. То есть заложить.

12:04

Speaker A

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

12:15

Speaker A

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

12:23

Speaker A

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

12:30

Speaker A

И монго. Хорошо. Функция constraint в базе данных. Помнишь, что это такое? Constraint. Constraint что-то знакомое, но затрудняюсь ответить сейчас.

12:41

Speaker A

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

12:59

Speaker A

логах системы при любом запросе пишется эта связка. Приходит информационная безопасность и говорит: "Ребятушки, э не можем хранить прямую связь и номера телефона защиты персональных данных 152 ФЗ". Как с точки зрения системного анализа решить данную задачу? Здесь множество есть разных способов. Что бы

13:20

Speaker A

ты предложил? Так, ещё раз. Можно? Это у нас получается есть, да? Fio, да. номер телефона и дата рождения.

13:29

Speaker A

Номер телефона и дата рождения. Да, соответственно, в сборе это всё персональные данные. Это у нас в одной таблице правильно хранится, да?

13:39

Speaker A

А, ну вариант приходятки, на что они ругаются просто, что это хранится в открытом виде, да?

13:47

Speaker A

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

14:11

Speaker A

тоже делается, например, фамилия и там имя, точка, к примеру, вот как-то так можно так.

14:17

Speaker A

Угу. А, о'кей. Маскироли ещё что можно использовать? Ну, шифрование этих данных. Давай посмотрим, какие типы шифрования, кэширования ты знаешь. Хэширование.

14:31

Speaker A

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

14:38

Speaker A

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

14:48

Speaker A

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

15:08

Speaker A

Вот у нас в симметричном используется один и тот же ключ, да, для шифрования и расшифровки.

15:15

Speaker A

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

15:37

Speaker A

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

15:50

Speaker A

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

16:11

Speaker A

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

16:29

Speaker A

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

16:48

Speaker A

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

16:59

Speaker A

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

17:13

Speaker A

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

17:23

Speaker A

Так, хорошо. Знаешь ли ты протокол авторизации AF2.0 войти через Яндекс, Google и что такое GVT токены?

17:35

Speaker A

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

17:48

Speaker A

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

18:06

Speaker A

авторизацию внутри системы. А2 - это стандартный протокол на рынке. Там есть access token и Permission token. Знаешь разницу?

18:16

Speaker A

Если это не имплементировал, не знаешь, что это протокол, просто скажи: "Нет, я тебя дальше мучить не буду задавать вопросы". Я тебе Ладно, я просто Да, я я же перепутал, мне оказалось вот как раз 2.0.

18:29

Speaker A

Ну, я понял, что там аess токен. О'кей. Смотри. с GVT токенами знаком, правильно? Да.

18:37

Speaker A

Делал когда-то дебак GVT токенов? Нет, тогда не настолько знакомы. Хорошо. Какие три уровня хранятся в GVT токенах?

18:50

Speaker A

Ну, получается, у нас вот это логин, пароль пользователя. Ээ, далее у нас вот сигнатура, которая Угу. Логин, пароль в открытом не хранятся. Угу. Не, не в открытом, да? То есть это хэш полезная нагрузка пользователя, потом вот сигнатура и

19:16

Speaker A

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

19:33

Speaker A

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

19:54

Speaker A

Ну, то, что, наверное, сорок срок экспира. Ок. Ладно, двигаемся дальше. Задачка на проектирование на systemдизаign. Смотри, у меня есть система, есть ядро системы, оно написано на ростах. Понятно, да? Изо. Ну, в данном случае зали мне говорит, мне нужно

20:10

Speaker A

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

20:26

Speaker A

Первый мой вопрос: как спроектировать данное решение между ядром системы и внешним партнёром, у которого интеграция на САП?

20:36

Speaker A

Ээ, через [откашливается] App Gateway, как будто бы, вроде, насколько я знаю, получается, у нас, ну, App Gateway отвечает за преобразование данных.

20:43

Speaker A

Соответственно, это у нас будет отдельный сервис, который будет валидировать и преобразовывать сейчас. Можно, прошу прощения. Подумай ещё. Там услышал и микросервис, и App Gateway. У них есть разница. Есть понятие Gateway, а есть понятие микросервиса. Мой второй наводящий вопрос: какие функции должны быть

21:02

Speaker A

заложены э в этих компонентов? Вот пока подумай, а я сейчас 2 секундочки мне надо ответить. Готов? Я готова.

21:10

Speaker A

М возможно, это речь об оркестраторе. Нет, смотри, давай разберёмся, зачем нужен IP Gateway и зачем нужен микросервис. Либо, либо я неправильно услышала и ты сказал, что либо нужен API Gateway, либо микросервис, либо и то, и то, либо вот,

21:27

Speaker A

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

21:43

Speaker A

Хорошо. Дальше что? Он ещё, ну, валидацию, соответственно, он проводит. Плюс он просто контролирует поступившие запросы и то, что мы отдали.

21:52

Speaker A

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

22:09

Speaker A

А, ну то, чтобы дешка своя должна быть, да? Ну, у микросервиса есть своя бдшка, конечно. Databersви.

22:17

Speaker A

Теперь теперь дальше раскручиваем IP Gateway. Как раз функция валидации логирования может стоять на App Gateway.

22:25

Speaker A

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

22:40

Speaker A

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

22:59

Speaker A

микросервис. Тем самым микросервис не нагружает ядро системы. Я тем самым circreaker, по-моему, правильно, правильно. Паттерн правильный, молодец. вспомни. Для этого выставляется, почему я спросила, либо либо, да, либо IPгей, либо микросервис.

23:16

Speaker A

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

23:33

Speaker A

далее которые ну, старать как минимум. Конечно, обработчик, ты молодец, справился с этим. Вот. ответила. Есть какие-то вопросы по проектированию?

23:42

Speaker A

Почему так лучше использовать? Но я думаю, здесь понятно. Разобрали. Дада. Да, разобрали. О'кей. Так, из глобального, что я ещё, наверное, не спросила. Скажи мне, пожалуйста, как у вас обычно проходило там проектирование А либо ещё что-то? Меня какой момент интересует?

24:00

Speaker A

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

24:09

Speaker A

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

24:23

Speaker A

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

24:39

Speaker A

Угу. Так, о'кей, хорошо. Так, скажи мне, пожалуйста, твои зарплатные ожидания на текущий момент пока от 250 на руки в окладе.

24:48

Speaker A

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

25:09

Speaker A

нумотиваций. Так, о'кей, поняла. Скажи мне, пожалуйста, ты работаешь на текущем месяце? Работай, да? Настоящее время работаю.

25:16

Speaker A

Угу. То есть 2 недели отработки нужно будет, правильно понимаю? Да, 14 тире 30 дней может быть. Ну, у нас заложено так, да, в договоре прописано. Я знаю, что это не совсем ПТК, но никто не жалуется, да, но по трудовому максимум 14. Так,

25:35

Speaker A

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

25:54

Speaker A

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

26:02

Speaker A

Значит, смотри, проект здравоохранение [откашливается] делится на два больших блока: поликлиники, стационары. Поликлиники - это личный кабинет. И если, значит, у нас гибридный формат работы, э, объясню сразу, 3 дня офис, 2 дня удалёнка, на испытательном сроке, full house офис.

26:21

Speaker A

Дальше по проекту личный кабинет - это поликлинический. Ты как пользователь чаще всего встречаешься с ним. Наш блог отвечает за стационары. стационары - это большие крупные клиники Москвы, больницы спкой и так далее. У нас более 70.000 оцифрованных процессов, начиная видео

26:38

Speaker A

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

27:01

Speaker A

анализы, не анализы. В общем, всё, что есть внутри больницы, мы цифровые. Давай так. В целом, это большой глобальный проект, достаточно крупный. Дальше. М какие ещё вопросы? На что ещё ответить?

27:12

Speaker A

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

27:21

Speaker A

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

27:39

Speaker A

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

27:47

Speaker A

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

28:05

Speaker A

Ну, понял, да? Ну, в смысле, имеется в виду C4, да? Угу. Почему? Потому что система очень сложная, большая. Для того, чтобы протащить иногда какую-то доработку, нужно доработать, я не знаю, там 20 сервисов, да, адаптеры. Не забыть где-то, чтобы из точки А в точку Б

28:22

Speaker A

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

28:40

Speaker A

Понятно да? Угу. И далее уже детализация на задачи, которые идут на разработку. Соответственно, в этих задачах там уже проектирование как апи контрактов и так далее. Значит, из важного у тебя инхаусная разработка. То есть у тебя разработчики сидят в контуре. У нас-то

28:56

Speaker A

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

29:03

Speaker A

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

29:19

Speaker A

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

29:30

Speaker A

Ответила на вопрос. М, да. Тогда вытекающий по какой методологии? 2 недели. Скрам. А, Скрам.

29:39

Speaker A

Ну, как правило, 2 недели. Как правило, 2 недели. Но у нас бывают срочные задачи.

29:47

Speaker A

и так далее. Вот это это ни во что не вписывается. Это просто надо завтра 2 дня умри на делай. Ну такое бывает.

29:54

Speaker A

Переприоритизация. Спринт не пересматривается, я так понимаю. Ещё как. На этой неделе мы просто пригораем на всех фронтах. Вот.

30:04

Speaker A

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

30:21

Speaker A

с точки зрения управления, в котором мы работаем, управление по развитию программного обеспечения, у нас три отдела: отдел бизнес-аналитиков, отдел РП и отдел системной аналитики и архитектуры. Значит, к нам поступают уже структурированные требования от бизнеса, описанный BPменко и так далее. Тут не

30:40

Speaker A

фкнали, тут именно техническо системного анализа. Мы не отвечаем за бизнес-часть, мы не общаемся с заказчиками. Вот нам как приносят, так мы и берём. Понятно?

30:50

Speaker A

Мы можем задать вопросы, комментировать и так далее, если требования не до конца проработаны. Вот. Но с заказчиками общаются обычно РП либо БА бизнес-аналитики.

30:59

Speaker A

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

31:14

Speaker A

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

31:26

Speaker A

Дальше точно будет будут задачи на проектирование апи. Я акцент на объектные модели, массивы и так далее сделала во время собеседования. Важно на это обращать внимание. Точно дам попробовать задачу на проектирование архитектуры. Если потянешь, будешь дальше в этом ключе развиваться. Если

31:45

Speaker A

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

32:00

Speaker A

Так, ну, в принципе, тогда плюс-минус всё в целом понятно. Так, из важного тоже сразу подсветить.

32:06

Speaker A

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

32:21

Speaker A

Угу. Это бывают такие, ну, бывают вещи, которые запущены 100 лет назад по какой-то причине, неважно по какой, но документов нет. Ну, такое бывает. Я предупреждаю сразу на входе о таких вещах.

32:36

Speaker A

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

32:51

Speaker A

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

33:01

Speaker A

Ну, у меня на самом деле тоже 80 на20, наверное, где-то, даже больше. Так, о'кей, хорошо. Заполдурам идите, пожалуйста. Что у вас там? Ладно.

33:11

Speaker A

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

33:28

Speaker A

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

33:41

Speaker A

Я понял. Спасибо. Всё, на связи. Ты молодец. Да, спасибо. Я тебе сейчас напишу по дальнейшим шагам.

33:48

Speaker A

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

33:55

Speaker A

Да, я понял. Спасибо большое. Да, за беседу, за интересное интервью. Всё на связи. Хорошего дня. Пока.

Topics: системный аналитик собеседование REST API HTTP коды Kafka SQL проектирование систем оффер IT карьера API контракты

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

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

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


---
This is the markdown twin of https://sozai.app/transcript/offer-300k-30-minutes-systems-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/