Skip to content
Start free
Get App

Собеседование на системного аналитика в беттинг - почему я не получил оффер? Попросил 320к

Разбор собеседования на системного аналитика в беттинг-компанию: кандидат рассказывает о своём опыте (BPMN, юзкейсы, проектирование БД, Kafka, UI) и разбирает, почему получил отказ.

Key Takeaways

  • Отказ на финальном этапе может быть связан с ожиданиями по зарплате и несоответствием резюме.
  • Для системного аналитика важно уверенно владеть BPMN, UML-диаграммами и структурированным описанием требований.
  • Интервьюеры проверяют не только теорию, но и практический опыт проектирования БД, API и интеграций.
  • Честность в анкетах и согласованность резюме важны для службы безопасности и HR.

What the video covers

  • Автор делится записью технического собеседования на позицию системного аналитика в беттинг-компании, где получил отказ после двух успешных этапов.
  • По его версии, возможные причины отказа: запрошенная зарплата 320 000 на руки и неполное указание мест работы в резюме.
  • Кандидат представляется системным аналитиком с более чем 5-летним опытом на международных и российских проектах.
  • Описывает рабочий процесс: декомпозиция эпиков, документация в Яндекс Вики, работа с микросервисами и переход от монолита.
  • Рассказывает о работе с PostgreSQL и MongoDB, в том числе о переносе пользовательских данных в коллекции MongoDB.
  • Описывает состав артефактов: цели, контекст, as-is и to-be процессы, юзкейсы, функциональные и нефункциональные требования, API, диаграммы последовательности и состояний.
  • Признаёт слабое знание нотации BPMN и путается в различии параллельного и исключающего шлюзов.
  • Интервьюер проверяет знание SQL, проектирование сущностей (например, сертификаты пользователя), работу с Kafka и требования к UI.
  • На практических примерах разбирается сценарий пополнения баланса с быстрыми суммами и требования к производительности.
  • Видео демонстрирует типичные вопросы технического интервью системного аналитика и слабые места кандидата.

Chapters

  1. 00:00Вступление и причины отказа
  2. 02:45Презентация опыта кандидата
  3. 05:23Артефакты и документация
  4. 10:20BPMN и юзкейсы
  5. 14:10Проектирование баз данных и SQL
  6. 22:00Kafka, микросервисы и архитектура
  7. 25:30Практический кейс: пополнение баланса и UI
  8. 38:00Вопросы о компании и заключение

Answers

Questions about this video

Почему кандидат считает, что получил отказ?

По его мнению, отказ связан с запрошенной зарплатой 320 000 на руки и неполным указанием мест работы в резюме. Сам он отмечает, что в анкете службы безопасности всё указывал честно.

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

Он описывал требования в Яндекс Вики, работал с PostgreSQL и MongoDB, применял диаграммы последовательности и состояний. BPMN он использовал редко и признался, что плохо помнит шлюзы.

С какими сложностями столкнулся кандидат на интервью?

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

Full Transcript — Download SRT & Markdown

00:00
Speaker A
Всем привет. Это запись моего собеседования на системного аналитика в крупный бетинг, где я не получил офер, хотя успешно прошёл два этапа технического собеседования. Первый этап - это то, что вы сейчас посмотрите, и ещё собеседование с командой, которая ждёт вас на бусте. После прохождения
00:18
Speaker A
двух этапов меня попросили заполнить анкету СБ. Позже я получил вот такое сообщение, что как бы, извините, отказ по совокупности факторов, что бы это не значило. Как мне кажется, у меня был мэтч на всех этапах, но, видимо, совокупностью факторов выступили
00:33
Speaker A
следующие моменты. Я попросил 320.000 на руки, что, скорее всего, было намного больше, чем мне могли предложить. И в резюме я не указал пару мест, где работал. Хотя в анкете SB я всё честно указал и всегда пишу в СB всё как есть.
00:48
Speaker A
Будет интересно узнать ваше мнение по поводу моего Сабеса. Может быть, не было никакого мэтча, и я сам его себе выдумал. А может быть, вы знаете, сколько готов платить бетинг. Всё, не смею вас задерживать. Приятного просмотра.
01:03
Speaker A
А у нас сегодня техническое интервью. Общаемся мы на Ты. Это формат беседы примерно на 45 минут. Ну, может быть, поменьше, может быть, чуть больше. Ну, плюс-минус вот такой вот у нас слот.
01:15
Speaker A
Обычно его достаточно. А как будет проходить эта встреча? Сначала я прошу тебя, а, рассказать о своём опыте. Нас интересует именно опыт в системном анализе. Что конкретно ты лично своими руками, как системный аналитик делал, какую документацию, какие инструменты использовал, да, а в каком виде там
01:38
Speaker A
требования поступали или, может, вообще ни в каком, да, у всех по-разному. А вот, ну, то есть подсветишь вот эти вот детали, дальше тебя поспрашивает конкретно, интересующие вопросы позадаёт.
01:50
Speaker A
А, и оставим минут 10 для того, чтобы то, что нас поспрашивал, мы поотвечали. А, то есть сегодня беседа больше там про технику. А если сегодняшняя встреча пойдёт успешно, удачно, если будет взаимтерес друг другу, тогда будет повторное интервью. Оно уже будет с
02:10
Speaker A
продуктунером команды, которую мы ищем сейчас аналитика, для того, чтобы он аа более предметно и подробно рассказал про продукт, состав команды, прямо примеры задачи и так далее. Потому что у нас каждая продуктовая команда сильно отличается друг от друга, везде свои
02:27
Speaker A
нюансы, своя специфика, ну и так далее. Вот так. Вижушь нам подключилась. Привет. Да, привет.
02:35
Speaker A
Привет. Да, давайте тогда начинать. Передаю тебе слово. Мы слушаем твою мини саму презентацию и дальше.
02:45
Speaker A
Да, хорошо. А, да, ещё раз, я системный аналитик, уже в системном анализе более 5 лет. А, работал как на международных проектах, так и на отечественных, на российских. А я буду начинать, наверное, с последнего места работы. Вот на последнем месте работы я был
02:59
Speaker A
единственный системный аналитик в команде. продукт у нас был это админка, которая переходила на новые рельсы, то есть просто инфраструктура. А по стеку у нас там был REST игра QL. А чем я обычно занимался? Мне приходили требования в формате эпика огромного от продукт
03:15
Speaker A
оунера или проjectт-менеджера. Я этот эпик декомпозировал, описывал задачи на разработчиков и потом уже у меня также были задачи на документацию, которую я оформлял в Яндексвике. В принципе, таким был э обычный вот флоу, можно сказать. А дальже я как системный аналитик
03:32
Speaker A
занимался практически всем. То есть там база данных, проектирование энпоинтов, я не знаю, какой-то UI на описать. Этим тоже занимался.
03:41
Speaker A
Ну и, соответственно, общался с заказчиками, выявлял бизнес-требования, потребности, если продукт owner не мог мне как-то подсказать. Вот на предыдущем месте работы я делал то же самое, только там уже была команда из системных аналитиков, у нас было пять человек, это
03:54
Speaker A
была страховая компания. А там я, в принципе, всё тем же занимался. архитектура была, что вот на последнем месте работы микросервисная, то есть переход от монолита к микросервисам, что на Да, или лучше. В принципе, как системный аналитик вот по сути вот с
04:09
Speaker A
этим и работал. А база данных и как и реляционная, так и нереляционная. Реляционная - это Пасгрят всегда была, а нереляционная вот последняя - это Монди DB. Из интересного могу сказать, что переносил из на переход делал на нереляционную базу данных, потому что у нас был личный
04:26
Speaker A
профиль, можно сказать, пользователя, то есть в админке было много данных по пользователю, их невозможно было уже в пост SQL держать, поэтому описывал коллекции Моong DB. Ну, это из последних таких больших задач.
04:39
Speaker A
В принципе, на этом всё. Угу. Тогда могу задавать вопросы, видимо. Да. Да. Угу. А нормально меня слышно?
04:47
Speaker A
Хорошо. Ага. А давай с самого начала пойдём. Ты говоришь, что приходилось уточнять бизнес-требования. Расскажи, а какие артефакты после уточнения рождались, в каком виде описывал. А, ну вот так.
05:05
Speaker A
Угу. Хорошо. А обычно, ну, например, мне задача она приходит там просто текст сплошной и есть userстори. Вот, соответственно, когда я хочу уточнить требования или что-то сделать, я уточняю, общаюсь с продуктом, с заказчиком. Потом я описываю обычно юзкейсы. А, ну, вообще в документации у
05:23
Speaker A
меня как идёт цель, контекст, процесс as is, process to be, как мы хотим это видеть в конце. И потом идут у менясы обязательно. После юзкейсов требования функциональные и нефункциональные. После этого уже проектирование. Если это что-то с апи связано, я описываю апи.
05:41
Speaker A
э-э с таблицами. Ну и ниже уже диаграммы, если это интеграция, диаграмма последовательности обычно была. А я ещё люблю диаграмму состояний просто для статусов. В принципе, обычно этого было достаточно.
05:54
Speaker A
А бизнеспроцессы рисовали где? В какой нотации? Вот бизнес-процессы я прямо вот BPMN, чтобы рисовать, я не рисовал. То есть можно было у нас на прошлой работе можно было просто, я не знаю, вдрова нарисовать эти прямоугольнички, описать, как это будет выглядеть, и всё. Без
06:08
Speaker A
шлюзов, без всего такого. Угу. А вообще с нотацией знаком? Я с ней знаком, но я с ней очень редко, вот за 5 лет я буквально два-три раза BPMN нарисовал, не более.
06:22
Speaker A
А, ну я спрошу тогда, может быть. Хорошо. По нотации BPMN. В чём разница между параллельным и исключающим шлёзом?
06:33
Speaker A
Ну давай я предположу. Я здесь наверняка не могу знать, честно. а-а параллельны, мне кажется, когда два процесса могут идти одновременно, исключающие когда один может проходить, а как, ну, какой-то есть фактор, почему невозможно дальше пройти. Я просто по шлюзам так
06:47
Speaker A
давно ничего не делал, что тут боюсь, могу глупость сказать. О'кей. А по поводу юзкейсов, ты сказала, что описывал юзкейсы. Когда описывал юзкейсы, какие, ну, разделы были, что описывал, что важное было? Конечно, ну это у меня всегда в формате таблицы есть
07:05
Speaker A
актор, кто это, например, там пользователь. Потом идут у меня постусловия и, соответственно, триггер, который происходит. Что там пользователь делает? Нажимает на какую-то кнопку.
07:14
Speaker A
Далее идёт основной поток, основной сценарий. Там я опишу последовательность действий пользователя. Потом есть альтернативный сценарий, да, если что-то пошло не так. И в конце уже результат, чего мы, собственно, добились.
07:27
Speaker A
Угу. А user story в каком формате пишете? А user story были просто я как пользователь хочу там видеть вот это там, я не знаю, свои баллы какие-то лояльности, вот что-то такое. Угу.
07:42
Speaker A
О'кей. Далее переходили к функциональным требованиям, к проектированию. Ты сказал что а занимался проектированием базы данных, да? А, и работал с реляционными и нереляционными базами. А проектировал нереляционную или реляционную тоже?
08:04
Speaker A
Реляционную я дописывал, ну, например, табличку я проектировал, да, и связи, соответственно. Ну, например, там из последней задачи нужно было сертификаты пользователя, чтобы они были в вебе, пользователь в своём личном кабинете их видел.
08:17
Speaker A
Такой таблицы не было. Я сделал таблицы и соответственно в таком формате. Угу. А когда проектировал, как описывал, что делал?
08:28
Speaker A
Угу. Ну, для начала я выяснял конкретно, какие нам необходимы сущности, да? То есть на таком уровне, можно сказать, логическом, как бы вот у нас нет сертификатов, значит, должны быть сертификаты. А а что такое сертификат? У них должны быть шаблоны, да? То есть как
08:42
Speaker A
бы не может же быть один какой-то. А, поэтому как бы логически рассуждал, как это делать. Потом, а, смотрел, какие могут быть связи с таблицей, например, с таблицей usеer, потому что сертификаты они могут быть у пользователя.
08:54
Speaker A
Вот. Ну и обдумывал сам с учётом требований, какие могут быть атрибуты в этой таблице. То есть, что нам нужно, там имя, э, мы берём у юзера, шаблон сертификата, ссылка на PDF-файл уже, когда сертификат сформируется. Он, кстати, хранился у нас в Битбакете.
09:12
Speaker A
Соответственно, ну, вот как-то так исходил из требований. Ну, описывал потом уже типы данных, которые будут в табличном варианте. И в принципе всё. И связи.
09:23
Speaker A
Диаграмму строили, конечно. Да. Угу. Для проектирования использовали. А какого уровня модель данных описывали на Рдиоаграмме?
09:31
Speaker A
Ну, уже физическую. То есть это уже конкретная таблица с атрибутами, со связями, как она выглядит, как общается.
09:39
Speaker A
Угу. Сейчас покажу одну такую схему. Так, видно экран? Да, всё видно. Всё видно. Вот смотри, на экране диаграмма. А какого уровня модель представлена?
09:59
Speaker A
Ну, там обычно бывают какие логические. Логическая модель, физическая модель и ээ мм вот какой я ещё не помню. Но э раздесь есть это, наверное, логическая, всё-таки это называется.
10:13
Speaker A
Угу. А посмотри просто на диаграмму и скажи, что здесь не так. Хорошо. Давай посмотрим слева направо пойдём. У нас есть издательство, у них есть в первичный ключ Unque ID. Он связан с один ко многим к книгам. О'кей. Жанры
10:36
Speaker A
тоже один ко многим к авторам. Ну вот тут вот у авторов не написано, да, что это как бы fork. Во-первых, непонятно.
10:46
Speaker A
Нкеев нет ни одной из таблиц, в принципе. Это первое, что увидел. Второе, а зачем нам, наверное, так?
11:06
Speaker A
Ну и Unque ID он как бы тоже идёт в primary K, то есть получается один ко многим в primaryке, наверное, не совсем э правильно, да, что один первичный ключ связан с другим первичным ключом. Они вроде как должны быть с внешним ключом
11:20
Speaker A
связаны связи в таблицах. Вот, собственно, ну да, здесь очень во всех практически таблицах не хватает внешних ключей.
11:40
Speaker A
И если есть ещё что-то, ну, тут как бы посвя по связям. Ну, тут везде практически, по-моему, один ко многим получается нарисовано.
12:09
Speaker A
Но здесь А в чём может быть дело? Ещё мало того, что это всё идёт как бы связано всё с primary K практически везде. А-э, то есть у одного жанра много книг.
12:23
Speaker A
О'кей. У издательства может быть множество книг. Действительно. А то, что у клиента может быть как бы то, ну, несколько заказов, это как бы должно быть, а не заказ.
12:39
Speaker A
Тут, наверное, нужна таблица всё-таки многие ко многим, ну, связь многие ко многим сделать jнt таблицу между заказами и клиентами, потому что у клиента может быть множество заказов.
12:50
Speaker A
А, хотя у одного заказа не может быть много клиентов. А, наверное, вот в этом, вот в этом проблема.
12:59
Speaker A
Значит, какая здесь связь должна быть? А здесь должна быть связь наоборот. То есть у одного клиента может быть множество заказов.
13:05
Speaker A
Угу. О'кей. Мм. Так, по поводу баз данных. А SQL запросы приходилось писать работу? В каком случае?
13:20
Speaker A
Приходилось. ээ, писал вот на последней работе прямо, честно говоря, в data Lens, потому что, ну, много прямо не нужно было писать. Писал самые простые, ничего там такого сверхъестественного не было. То есть я имею в виду там ни оконные функции, ничего такого. Если мне
13:33
Speaker A
нужна там какая-то агрегатная функция, да, там, то я её в интернете мог посмотреть. То есть так не всегда подзапоминаю их, потому что я не так часто с этим работаю.
13:42
Speaker A
Угу. А, ну, немножко по поспрашиваю. Ключевое слово distстин для чего используется? А для того, чтобы не было повторяющихся значений.
13:53
Speaker A
Анен у нас используется после групby, если я правильно помню. То есть это такая уже ээ ну как бы сказать, сортировка после группировки. Как-то так вот можно, наверное выразиться.
14:07
Speaker A
Угу. О'кей. А с хранимыми процедурами приходилось работать. Вот это, наверное, точно не приходилось делать.
14:23
Speaker A
Угу. О'кей. При а проектировании Ав кажется у тебя и граф QL. Да, да, у меня был игра. Угу.
14:36
Speaker A
Угу. когда описывал интеграцию через или через граф, в каком виде описании было, что учитывал при описании?
14:46
Speaker A
Конечно, а тут у меня такой же подход. Я сначала описываю цель, э, что это за интеграция, описание этой интеграции тоже у меня есть. И потом я начинаю уже подходить к самому проектированию.
14:57
Speaker A
Например, пусть это будет ростовый запрос, а это HTP метод, который у нас используется. Пусть будет get, а URL, который мы используем или endpoint, да?
15:07
Speaker A
А потом уже я описываю, какие будут заголовки, параметры входные, а какие вообще есть параметры, я не знаю, может, у нас погинация есть, сортировка, ещё что-то. И потом уже ответ успешный. Э что мы получаем, то есть в формате Jсона
15:21
Speaker A
какого-нибудь и коды ошибок в конце. В принципе, на этом, как правило, обычно было всё.
15:29
Speaker A
Угу. А ещё, извини, добавлю ограничения, которые могут быть на это апе. То есть там и это может делать только зарегистрированный пользователь или там ещё что-то в таком духе.
15:40
Speaker A
Угу. Внутреннюю логику методов приходилось описывать. Было были ли какие-то сложные запросы, которые состояли из, ну, там, не знаю, получить на UI нужно что-то?
15:53
Speaker A
И для этого происходило межсервисное взаимодействие от одного сервиса к другому. Это всё разные методы получались, данные какая-то логика внутри. Вот такие были запросы?
16:03
Speaker A
Конечно, были. Э там получить запрос как раз-таки на UI, потом проверить ещё что-то и так далее. Там один запрос потянуть, потом второй, третий. Было такое да?
16:14
Speaker A
Угу. Угу. По А с GRPC не работал? С GRPC, к сожалению, нет. Просто ни на одном месте работы не было.
16:24
Speaker A
Угу. Теоретически не, ну, не разбирался сам просто разбирался, но давненько. Я так понимаю, что JRPC он просто для более быстрого отклика, правильно я понимаю? То есть быстрее должен работать, нежели рест и игра в QL, например.
16:38
Speaker A
Угу. Это да. Ну, о'кей. А, ну на проекте интеграции были не только синхронные, а синхронные тоже. Да, безусловно.
16:53
Speaker A
Какие брокеры использовали? У нас был Ребит, была Кавка, а был Редис. Вот с Редисом вообще не потрогал его абсолютно. Кавка, да, Кавка была.
17:03
Speaker A
Угу. А Ребит и Кавка использовались и то, и другое на одном проекте. Да. Да.
17:09
Speaker A
А в каком случае? Почему использовали? в каком-то в каком-то RIT был при старой системе, при старой архитектуре. Вот. А когда мы переходили на новую в архитектурном комитете, я сам за это был, за то, чтобы у нас была всё-таки событийная архитектура, поэтому
17:24
Speaker A
мы уже стали кавку добавлять. Вот поэтому. А в чём плюс её был по сравнению с Ребетом? А плюс в том, что пропускная способность у неё гораздо больше, чем у Ребита. А, собственно, у Ребита на самом деле тоже есть и партиции, и очередь, всё то же
17:40
Speaker A
самое. Просто Кавка действительно более, а у неё большая пропускная способность. Мы можем логировать вот, э, ну, то есть мы не теряем наши сообщение, то, что поступало в Кавку. У Кавки есть как это называется? Да, то есть а то,
17:55
Speaker A
что мы доставили сообщение и Кавка его получила, то есть мы не потеряем его. Ну и плюс, ээ, как бы сказать, очень удобно, когда есть партиции с топиками, можно группу консюмеров или консюмеров подключить, и на одно событие у нас
18:08
Speaker A
сразу несколько каких-то мм процессов будет происходить. Ну, например, новый пользователь зарегистрировался в нашей системе. Одна система, когда это узнает, отправляет ему на email сообщения: "Спасибо, что подписались на нас".
18:20
Speaker A
Другая ему какие-то баллы начисляет, третья ещё что-то делает. Вот поэтому это удобнее. А когда описывал интеграцию через кавку, ну я так поняла, что новые топики приходилось создавать, да, раз вы переходили от Да. Угу. Да.
18:35
Speaker A
Угу. А что описывал в топике? Что описывал при интеграции ставкой? Да, я вот так прямо глубоко не смог погрузиться, потому что у нас обычно этим бэкэндеры прямо заправляли, можно сказать. Но я описывал именно, кто является продюсером, кто является
18:50
Speaker A
консюмером, как называется топик, в чём его основная идея, то есть тема этого топика, например, новый пользователь, а и, собственно, из какой партицы читается сообщение, но тут действительно мне не совсем давали этим всем позаниматься.
19:04
Speaker A
Это вот тимлидбека себе забрал, можно так сказать. А параметры топика не рассчитывали, да, вот эти ретеншены. Угу.
19:15
Speaker A
О'кей, я поняла. А так хотела спросить. Вот мы, значит, интегрируемся синхронно. А синхронно ты рисуешь диаграммой после этого, да, чтобы это показать. Где рисовали? В Pl.
19:34
Speaker A
А план мы тоже работаем. А подскажи, пожалуйста, как план, когда ты рисуешь sequнс, отличить визуальный синхронный и асинхронный запрос? Да. А синхронный - это просто стрелочка такая обычная, а асинхронная она заполненная будет. Вот сейчас ещё раз. У асинхронного какая?
20:00
Speaker A
А, наверное, наоборот. Я просто мог перепутать. Там дело в стрелочках вот этих, как бы наконечник этой стрелочки заполнены или не заполненный. Вот.
20:07
Speaker A
Угу. О'кей. А как добавить э нумерацию вызовов автоматическую в планкимейле? Хорошая, э, хорошая вещь. Я тоже недавно это делал. Сейчас, а, блин, ну, стрелочки, чтобы все пронумерованы были.
20:24
Speaker A
Дадададада. Э, забыл слово, которое это в самом начале пишется. После того, как мы объявили все всех акторов, можно сказать, всех participants это пишется перед этим. Слово забыл, к сожалению.
20:34
Speaker A
Угу. Ну, автор там, да? Автор. Угу. О'кей. А так, а ты сказал, что у вас на проекте или я не знаю, в команде был архитектурный комитет. То есть у вас архитекторы были выделены, да, под каждый проект или как это было?
20:52
Speaker A
У нас не было архитектора, у нас был техлит и были бэкндеры. А и Тимлит Бека, Тимлит фронта, Тимлит системных аналитиков и вот Техлита. Это и потом все остальные технические специалисты.
21:04
Speaker A
Это и был архитектурный комитет. И там уже принималось решение, как строить вот эту микросервисную архитектуру.
21:12
Speaker A
Ну, там был он раз в неделю по пятницу, условно. Ага. А в каком виде вот, ну, принималось, что какие-то артефакты у вас рождались, рисовали в каком-то виде архитектуру?
21:23
Speaker A
Да, в Яндекс досках, по-моему, рисовалась архитектура, но это не C4 было, это была просто схема, можно сказать, ээ, того, как должны взаимодействовать микросервисы. А вообще, что у нас происходит в нашей системе?
21:38
Speaker A
А чём отличие было от C4? Почему ты говоришь, что это был не C4? Ну, это было, наверное, не так подробно и не в таком формате, да? То есть это был свободный формат, отличающийся от C4, можно так сказать. То есть
21:51
Speaker A
Угу. О'кей. А ты можешь назвать, в чём недостатки микросервисной архитектуры? Да. А, наверное, можно вот о чём сказать. Вот тут, кстати, спорно.
22:04
Speaker A
Почему-то я очень часто это говорю, и многие мне говорят, что это не так. А микросерна микросервисная архитектура, она может быть медленнее, чем монолитная. В том случае, если монолит у нас не такой загруженный, да, например, а микросервисная там ведь есть вот это
22:17
Speaker A
время между, когда сервисами передаются данные, вот эти миллисекунды, немного есть задержка. В монолите такого нету, но это не такой прямо катастрофический минус, но можно сказать один из них. А второе - это сложность тестирований, потому что тестировать микросервисную архитектуру сложнее. Каждая команда свой
22:33
Speaker A
микросервис поддерживает или разрабатывает, и вместе это всё надо как-то скомпоновать. А третье, ну, дороговизна просто это дороже, чем монолит, например, да, поэтому тоже один из больших минусов. Ну и это сложно поддерживать, если микросервисов там 50 пс, условно там, условно у этого, как
22:52
Speaker A
его, у Нетфликса 800 микросервисов. Ну это тоже очень тяжело было бы поддерживать. Ну вот такие три могу выделить. А, может быть, что-то ещё есть? Ну, так нет, достаточно. А по поводу описания UI. Э, в каком виде ты описывала UI? Что
23:11
Speaker A
приходилось делать? Да, у нас вообще у нас был дизайнер. А, и когда я получал требования от продукта или там от менеджера или от кого-то ещё, я просто, ну, созванивался с дизайнером и описывал, что тут нам нужно, не знаю,
23:24
Speaker A
таблицу сделать или кнопку. У нас был общий стиль, который уже, ну, там в Фигме, которым можно было что-то делать.
23:31
Speaker A
Я таким образом ставил задачу на дизайнера, а потом я ставил задачу на то, чтобы фронтендер сверстал это. Ну, здесь такая же история, цель, описание, контекст и, соответственно, что необходимо сделать, в каком месте и прикладывал макет Фигмы.
23:48
Speaker A
А взаимодействие UI с бэком описываем? В каком? Что значит UI с бэком? То есть там кнопку нажали, там что-то появилось.
23:54
Speaker A
Это имеется в виду, ну, какой-то метод вызвался, метод там кто-то вернул, ко, конечно. Да, это как раз-таки в функциональных требованиях и описывал.
24:03
Speaker A
Угу. О'кей. А так сейчас, сейчас, сейчас. А какие процессы были выстроены? И, ну, не знаю, они выстроены, выстроились сами в ходе работы в команде. Приходилось ли ревю этот кейсы, например, тестировщиков, а участвовать в разборе инцидентов?
24:26
Speaker A
Ребью требований, может быть, у вас как-то было настроено? Да. А смотри, у нас как было, а, было три команды: Core, а, админка, в которой был я, и веб. На вебе два системных аналитика. Я один в админке и один ещё в
24:38
Speaker A
коре. Соответственно, мы каждый ревьюили друг друга, потому что нас так попросили, каждый смотрел чью-то документацию и говорил плюсы и минусы её. Это первое. Второе, с тестировщиками. А у нас было в команде два тестировщика. Если были какие-то проблемы, он мне писал, я подключался к
24:54
Speaker A
звонку и решались проблемы. Для него я также писал тест-кейсы, если прямо у меня время времени на это хватало, потому что задачи сыпались одна за другой. И просто тоже с ним созванивался. Если нужно было поставить задачу на доработку, я её ставил сразу
25:08
Speaker A
же. В основном коммуникация у нас была всё-таки это быстро подключись на звонок и там напиши задачу, например, да, если есть какая-то проблема, потому что у нас всё-таки что-то было всё очень быстро хотелось делать, поэтому так.
25:23
Speaker A
А расскажи какой-нибудь бизнес-процесс, который нужно было, ну, реализовать в системе какой-нибудь, не знаю, сложный такой вот чем можно похвастаться тебе было бы, что вот такой классный, сложный процесс там я описал полностью, и мы вот сделали какую-то фичу, и сложность была
25:40
Speaker A
там в том-то, том-то. Ну, это такой вопрос, он как-то вот спросили на награждении Золотого МЧА: "Какой гол ваш самый любимый у футболистов?" Вот Криштиану Роналду ответил: "Мой следующее". Я вот хочу сказать то же самое, что самая лучшая задача она следующая, но в принципе а,
25:57
Speaker A
наверное, вот одна из последних - это именно было интересно BD проектировать, именно Mongo DB, потому что я никогда до этого прямо так с нуля всё это не описывал. И здесь вот именно подход с того, что мы по сути, что такое
26:09
Speaker A
коллекция? Это табличка в базе данных, только она у неё нету жёсткой схемы. Мы можем как угодно её там описывать, какие угодно данные. Вот это было интересно.
26:18
Speaker A
Это, конечно, не бизнес-процесс, я понимаю, но из последнего, наверное, не ой, а в чём сложность была?
26:24
Speaker A
Сложность была в том, что у нас у нас была таблица usеer, состоящая из 80 или тире 100 полей, и надо было вычленить из них самые нужные, понять, зачем они нужны, потому что документации особо не было. А я созванивался постоянно с
26:37
Speaker A
кем-то, это всё прорабатывал. Потом связи между этими коллекциями и как это будет работать, потому что а вот у меня в резюме написано, да, согласно 152 ФЗ, мы должны были хранить личные данные иначе. Вот. И я проектировал, как общался с безопасниками, как нам хранить
26:54
Speaker A
эти личные данные, да, там пароль, хэш и отдельную таблицу для этого делал. Ну, то есть вот это была уже другая немного работа, скажем так, интересная.
27:06
Speaker A
Сейчас ещё одну картинку покажу. Угу. тоже такой же непонятный. Всё потерял секундочку. Вот, если видно.
27:36
Speaker A
Угу. Да, вижу. Ну такой сиквен sequквенс нарисован. Вот какие ошибки тут допущены. Что вообще скажешь по поводу этой схемы?
27:48
Speaker A
Ну вот этот фейспал в последнею- это интересно. Но тут нету линий жизни, да, во-первых. А по-моему, или они как-то А нет, они есть. Всё, увидел. А здесь, наверное, что нету. То есть у нас есть Да, нету их, на самом деле. Ну ты про
28:02
Speaker A
процессы, которые ограничивают. Ну нету, да. О'кей. Вот. Да. А зачем они нужны наконесе? Ну, чтобы понимать, когда мы используем тот или, ну, тот или иной объект или participant, он участвует в нашей схеме.
28:16
Speaker A
Угу. Да. Вот у нас вот engineers give up description for DHL Deutchland. О'кей. И это идёт в AI. Это получается синхронный процесс.
28:28
Speaker A
И потом я её WR code почему-то тут написано everything. Потом имидлигошит. И, ну, тут ответов, да, вообще никаких нету практически. То есть мы не знаем вообще, э, что получилось, какой-то ответ получить. И потом вот, э, ну, вообще, нужны ли здесь ответы? Здесь
28:52
Speaker A
тоже хороший вопрос. Вот как бы инженеры AI и everything. Ну, наверное, от AI надо получить ответ какой-то. Может, не работает VPN не включён, если вы в России. Так, аэ. А, а почему вот Face Palm там как ответ записан?
29:10
Speaker A
Ну вот почему-то так он записа, да. Я в принципе то, что недостаточно ответа, наверное, плетела или не жизни.
29:21
Speaker A
Так, а что я ещё хотела спросить? А про букмекеровся ты в курсе? Да. Так предметную область нашу.
29:29
Speaker A
Ну, конечно, ставок сам ставил. Ну там на киберспортивные события. Угу. Ну ты наш пользователь, оказывается. Да.
29:39
Speaker A
Да, да, я даже выиграл. То есть я этому рад. Так, сейчас я кое-что покажу. Для тебя, наверное, это не будет новым.
29:51
Speaker A
Говори, Тань. Я говорю, много выиграл, если не секрет. 3.000 руб. Я полторы поставил, три выиграл. Вот это был финал Лиги Легенд, потому что Лига Легенд есть только у ни у кого нет.
30:04
Speaker A
Понятно. Ну то есть это не в миллионах измеряется, как это бывает. Понятно. Я я не я не такой не игрок, на самом деле.
30:13
Speaker A
Понятно. Ну ладно, спасибо. Всё, Ась, продолжай. Так, смотри, а такая задачка кейс, ну, для тебя, наверное, знаком наш интерфейс нашего сайта. А это экран пополнения баланса. Тут способы пополнения, поле инпутамы, лимиты, кнопка пополнить баланс. И в какой-то момент productр приходит к нам
30:41
Speaker A
и говорит: "Я хочу на экран пополнения баланса добавить быстрые суммы, вот которые сейчас отображаются под инпутом".
30:49
Speaker A
Угу. Вот он принёс такой макет, сказал: "Просто хочу добавить быстрые суммы". У нас нету бизнес-аналитиков в команде.
30:57
Speaker A
Мы бизнес-требования прорабатываем вместе спродактом. А аналитику принесли макет, поставили задачу вот, ну, в таком в таком ключе. И дальше нужно проработать бизнес-требования с продактом, задать ему вопросы, ну, и затем функциональные и нефункциональные зо. Вот.
31:15
Speaker A
Угу. А мы сейчас говорим только про быстрые суммы, да? Только вот эти вот кнопки.
31:22
Speaker A
Ну, а, наверное, первое, что я бы спросил, если мне бы просто написали нож добавить быстрые суммы, да, первое - это где они должны находиться, потому что я, если экрана не видел, мне интересно, где, то есть, под чем, под каким?
31:34
Speaker A
Не макет. Макет принёс. Вот прямо вот такой экран, да, принёс. Маке супер. А тогда, э, наверное, один из первых вопросов, эти быстрые суммы, они фиксированы для всех или нет? То есть это всегда одна и та же сумма или
31:45
Speaker A
нет? По какой логике мы её отображаем? Почему? Ну, типа, всегда ли это стоит 500 или 1.000 руб., как на макете или они меняются в зависимости от каких-то факторов.
31:55
Speaker A
Угу. Это первое. Второе меняются. Могу отвечать, хочешь могу отвечать, хочешь могу не отвечать. Тогда давай я буду спрашивать, да, если они меняются, то по какой системе, да?
32:05
Speaker A
Есть ли какая-то логика изменений? Угу. Ну, какую-то можешь предположить. Ой, ну продукт такой: "Ой, не знаю, давайте, чтобы менялись".
32:13
Speaker A
наверное от баланса пользователя, да, если такое возможно, в зависимости от того, как бы сколько у него есть э денег на счету, если так можно посмотреть. Это, наверное, первое. Второе, а можно ли то есть, как я понимаю, пользователь нажимают на 500 руб., эти 500 руб.
32:33
Speaker A
появляются в инпуте. Угугу. Отлично. А если мы нажмём ещё раз на 500 руб., они не сложатся. Или сложатся.
32:44
Speaker A
Ага. То есть вот это тоже надо описать, что при повторном нажатии на один из на одну из быстрых. То есть если я 100 руб.
32:50
Speaker A
сейчас нажму, у меня появится 100 руб. в инпутели нет? Появится 100 руб., да, не 600.
32:56
Speaker A
Всё, я понял. Тогда это тоже надо будет описать, потому что, ну, чтобы фронтендер понимал, да, как он это будет тоже программировать и описывать.
33:03
Speaker A
Следующий момент, который здесь нужно уточнить, будет ли их всегда три, да? Хотим ли мы добавить их каких-нибудь потом побольше?
33:11
Speaker A
И, ну, тоже я бы это уточнил, да. Мне бы, наверное, сказали пока что три, типа, пока мы это выводим, пока три.
33:19
Speaker A
Ну, на самом деле нет. Нам сказали, что там до шести, да, надо, чтобы гибко всё было.
33:25
Speaker A
А, ну тогда я должен буду предусмотреть, ну, вместе с дизайнером, так, чтобы эти шесть они умещались под этим инпутом, да, чтобы это было просто симпатично выглядело.
33:35
Speaker A
Вот. И что бы я ещё узнал? Если пользователь А, кстати, я даже не знаю в Лиге ставок, если пользователь из Казахстана, у него ТНГ будут там написаны или другие суммы. Это как, если он с другой страны?
33:50
Speaker A
Не, у нас только ру только рубли. Ага, всё понял. Ну, соответственно функциональные требования, это требования, когда мы будем сейчас говорить о том, что пользователь нажимает на быструю сумму, эта сумма появляется в инпуте. Если он нажимает на другую, отличную от этой,
34:04
Speaker A
она меняется. при повторном нажатии на одну и ту же сумму сумма не суммируется. Угу.
34:10
Speaker A
А нефункциональные соответственно это требование уже к дизайну, да, что они все должны быть одно в одном таком вот окошечке, которым они нарисованы стандартные, не отличаться друг от друга. И что ещё? Да, наверное, ну, как бы больше и всё с
34:32
Speaker A
нефункциональными требованиями. Угу. А если, ну, начнём проектировать сейчас, а вот на этом экране вот способы пополнения забираются отдельным методом.
34:44
Speaker A
И все суммы мы решили тоже забирать отдельным методом и показывать пользователю. Вот этот метод, как он, ну, как бы он выглядел, я понял.
34:58
Speaker A
Какие у него входные параметры были бы? То есть ещё раз метод, когда мы нажимаем на одну из вот СПБ, СБП банковских.
35:07
Speaker A
Нет, нене не я просто говорю, что вот с это на этом экране вызывается метод, который получает способы пополнения весь список, потому что одному пользователю все доступны, другому две, третьему там три. Ну, разный набор для каждого пользователя. И мы решили спроектировать
35:23
Speaker A
систему так, чтобы показать вот эти, а, быстрые суммы, мы сделаем отдельный метод. У нас с одного экрана будет вызываться, чтобы показать способы пополнения, один метод, чтобы показать быстрые суммы, другой метод. Вот как бы этот метод выглядел, какой бы у него
35:38
Speaker A
был. Хорошо, я думаю, ну мы же хотим их получать, да? Получается, у нас есть должен быть get запрос, в котором было бы, я не знаю, там get я не знаю, personal folder с не знаю, deposit тут, да, вот написано
35:58
Speaker A
на в URL наверху и не знаю fast, я как-то так, я думаю, можно назвать. И у нас там был бы, собственно, просто Jсоon, в котором был бы массив с этими суммами.
36:14
Speaker A
В принципе, так бы мы, наверное, и получали, но нам надо было, наверное, прописать. Мы сначала показываем пользователю вот этот вот пополнение баланса, а потом вот этот запрос идёт на быстрые суммы.
36:26
Speaker A
Угу. А входные параметры какие были бы? Входные параметры нам на вход надо получить передать, если Угу. Мм, ну вот опять-таки, да, от чего зависят эти суммы? А-а, тут понять бы, ну, то есть какие у нас могут быть, в
36:43
Speaker A
принципе, в гете выходные параметры, да? Это, например, там погинация pageй, э, лимит какой-то, сортировка и дата, например, с какого по какого вот здесь, э, не знаю только, если это что-то связано с пользователем, и мы в заголовке передаём тот же какой-нибудь,
37:01
Speaker A
ну, тут, скорее всего, есть autentification токенen, да, токен авторизации как минимум его. И, ну, вот чтобы, а, ну, наверное, чтобы они вышли как Нет, 100, 500 и 1.000. Мы это и на фронте можно сделать. Тут не обязательно сортировку, но можно
37:17
Speaker A
так чисто Угу. сделать это. А к производительности мы могли бы, ну, опираясь на то, что у нас есть уже на этом экране вызов вот этих вот этого метода, мы можем выставить какие-то требования к производительности нового метода. На что мы могли бы опираться?
37:36
Speaker A
Мы могли бы опираться, если мы говорим про какие-то запросы в секунду, да, мы могли бы опираться на то, как часто пользователи вообще заходят сюда. То есть там, я не знаю, активность пользователей на этой странице, а, соответственно, среднее число обращений
37:52
Speaker A
пользователей сюда и, ну, в принципе, пиковая нагрузка, да, когда пользователи пополняют баланс и так рассчитать request per second.
38:03
Speaker A
Угу. А вообще вот вот такие требования к производительности вы часто рассчитываете к сервисам, к методам?
38:13
Speaker A
Проектируете вот на последнем месте? Нет, на предыдущем. Да, на предыдущем было. Угу. Угу. А я ещё, кстати, не уточнила. А приходилось участвовать в разборах инцидентов каких-то? Пользоваться графана и Локи?
38:28
Speaker A
Э, нет, вот графай Локи не пользовался, к сожалению. инцидентов. Только если вот произошёл какая-то произошла какая-то ситуация, я совместно созваниваюсь там с тестировщиком, ещё с кем-то и смотрю, в чём проблема. Логи там смотрел в той же нашей админкой ещё где-то, но не
38:43
Speaker A
А у вас были в в админке у вас логи просто хранились. Угу, я поняла.
38:50
Speaker A
Ой, ну всё замучила, наверное. Нет, вообще было замечательное собеседование. Гото готова ответить на твои вопросы.
38:58
Speaker A
Супер. Спасибо. Да, ещё раз спасибо за собеседование. А хотел уточнить первое, я так понимаю, что это продуктовая команда. Уже есть системные аналитики, там нужен третий, как сказала. А вопрос такой, наверное, работа в каком формате?
39:14
Speaker A
Это офис, гибрид или это удалёнка? М на твой выбор. А, супер. Варианты на твой выбор. Да.
39:25
Speaker A
А, хорошо. Ну, если ты живёшь в Москве и хотя бы иногда захочешь приходить в офис, но это будет плюсом, потому что ребята из Москвы, ну, иногда приезжают там кто-то раз в месяц кто-то.
39:37
Speaker A
А не подскажешь, где офис находится? Да. О'кей. Я сразу окола. Я недалеко, поэтому я бы приезжал в офис. Хорошо. А вот такой ещё вопрос. А в какую команду я собеседуюсь? То есть это веб портал, да? Вот это я тебе сейчас расскажу. А команда
39:59
Speaker A
мм а весь наш продукт, он разделён по функционалу на разные команды. Тамставками занимается команда, платежами занимается команда. Вот и наша зона ответственности - это вот эти страницы пополнения, вывод, история операции, баланс пользователя, а интеграция с внутренними системами, интеграция с внешними системами, потому
40:23
Speaker A
что все платежи проходят через внешнего провайдера, это наш регулятор, плюс отчётная, ну, по платежам ведётся отчётная деятельность в ЕРА, регулятор азартных игр. В общем, вот, э, мы такой как бы корфункционал, вот от работы нашего функционала зависит очень много внешних интегра внутренних
40:43
Speaker A
интеграций, внешних интеграций и 1С, и саб там. Ну, в общем, все потребляют данные по платежа. Ещё и САП есть.
40:50
Speaker A
У нас есть, да, внутри САП, поэтому туда данные тоже передаются, чтобы кол-центр мог консультировать пользователь, например.
40:59
Speaker A
Вот. И в наши команда она делится на две: фича и техничка. Мы сейчас ищем аналитиков техничку, а потому что много задач есть на вот эти вот интеграции, на переезд монолита, на какой-то рефакторинг. То есть это больше задача на БК завязанная. Команда Фича
41:24
Speaker A
занимается ну какими-то новыми фичами, которые Продок придумывает. как привлекать клиентов, как, не знаю, запустить какую-то новую механику на нашей страницах, вот что-то такое.
41:36
Speaker A
А в фиманде один системный аналитик, в технический три системных аналитика и там, и там полный, ну, как бы, а, полный набор всех ролей. Бэкэндры там, и там есть QA там, и там есть фронтенд, а, и приложение, и сайт сконцентрированы в
41:55
Speaker A
пиче, потому что для них там, в принципе, больше задач. Но если а при каком-то рефакторинге нам нужно поменять взаимодействие с фронтом, то, ну, мы ставим им задачу, и они их берут там в поряд приоритет.
42:06
Speaker A
Угу. Вот. А, ну, команда большая, наверное, вот в техничке человек 10. Вот это только системные аналитики.
42:18
Speaker A
Нене, нет. Сейчас я команду, да, системных аналитиков три. А это понял. Здорово. Хорошо. Так, а получается вот системный аналитик, который сейчас выходит, он будет заниматься вот платежами, вот этой вот страницей.
42:33
Speaker A
Первые задачи, собственно, вот с этим будут связаны. Ну, они будут связаны с какими-то интеграциями.
42:39
Speaker A
Угу. С внутренними, да, для того, чтобы платежи работали ещё лучше. Хорошо. И я вот увидел, что там у вас конфлюенс, да, и джиры, соответственно, из этих всех. О'кей.
42:50
Speaker A
Да. А ты работал в конфлюнсе из жили? Да. Да. На предыдущей. Ну. Угу. Угу.
42:54
Speaker A
Не на последнем, а на предыдущем месте работал. Угу, конечно. Угу. Ну и я работал в Почему за саб так зацепился? Я с сапом знаком просто. И у нас там тоже конфлюнса джира была и саб был, соответственно. Поэтому с этим тоже
43:07
Speaker A
знако как внешняя система, как одна из систем, с которыми мы интегрируемся. Мы туда особо внутрь туда не лезем. Как бы твои аналитики и вот общаемся на уровнестановки.
43:22
Speaker A
Понял. Ну хорошо, тогда у меня на самом деле больше, наверное, вопросов нет. Самое главное это были вот по формату работы и соответственно с чем работать.
43:30
Speaker A
Блин, можно бы Угу. Угу. А можно я тогда уточню? Ты в активном поиске работы?
43:35
Speaker A
Да, я в активном. Я, более того, я уволился. То есть я, на самом деле, получил офер в четверг и в пятницу в агamнг. А, и я его отменил, потому что я туда пришёл. И это не совсем совпало с
43:45
Speaker A
тем, что мы обсуждали. Вот поэтому я снова вышел на рынок. Вот. Угу. А если не секрет, что конкретно не совпало?
43:55
Speaker A
Там была такая история, что я почему я уходил с был таймтрекинг, а в айгейминге я вроде говорил, что можно без таймкинга какого-либо. Я-то работу нормально выполняю, ответственно подхожу. Мы сказали: "Всё о'кей, таймрекинга особого нету". Я пришёл и там тайм-трекинг был
44:10
Speaker A
по отпечаткам пальцев, и из офиса можно выходить только на 30 минут. Вот я не против офиса был бы, но и плюс, ну, из интимных подробностей туалет был вне офиса, то есть эти 30 минут они и там сгорают. И я как-то на это всё посмотрел
44:22
Speaker A
и резко убежал оттуда. Ну, собственно, люди работают. Может, это я так воспринял всё близко к сердцу, но [смех] это не для меня было.
44:33
Speaker A
Ну, понятно, нормально. По поводу тайм-трекинга. Я у нас его нету как бы вот, ну такого, чтобы все там влогировали своё время. Но первая задача, когда на этапе он анбординга аналитик берёт в работу, то мы, ну, так настоятельно рекомендуем пологировать
44:51
Speaker A
время вот на этапе исполного срока, просто чтобы понимать вот такого уровня задача, сколько она занимает у тебя времени, чтобы потом прогнозировать, там я её сделаю за 2 дня или за 5 дней или за 10 дней. Вот. Потому что у нас, ну,
45:05
Speaker A
тоже как у аналитиков, у нас большой комплект документации, который мы готовим для выпуска фичи. Это продуктовая документация, это описание компонентов, это разные диаграммы там, ну какого разных видов диаграммы. И как беря задачу, тебе может показаться, что там, ну, на самом деле описать эту задачу
45:23
Speaker A
несложно, а, ну, подготовить вот, чтобы оно потом осталось и тому, кто придёт после тебя с ней работать, было с чем работать. Вот весь комплект документов, вот он большой, поэтому мы советуем как бы первое время логировать.
45:38
Speaker A
Ну это нормальная практика. Я всегда тоже логировал, особенно в Джире, например, можно было списывать время, а здесь было такое, что там был их таймрекер и время постоянно тикает, и ты смотришь на это, и оно приплюсуется. То есть если чем больше ты был вне офиса,
45:51
Speaker A
тем больше ты будешь в офисе, то есть ты оттуда не уйдёшь. Вот там была такая история.
45:58
Speaker A
Ну не у нас благо такого нет. Ну, вообще на будущее не то, чтобы призываю, да, но в целом у нас никто не следит, воскольку ты начал работу, восколько закончил. Ну, главное, чтобы задачи были выполнены, да, и чтобы ты, а, вовремя подключался к
46:10
Speaker A
общим каким-то встречам, собраниям. Вот. Ну, то есть, если тебе нужно, знаете, там сходить утром к зубному, да, и из-за этого ты на час позже начнёшь работать, ну, как бы тебе никто ничего такого не скажет. Ну, главное там предупредить и
46:23
Speaker A
всё, да, ночитывать нуты или там сколько раз ты вышел покурить, если вдруг ты куришь, да? Ну такого у нас нет. Вот мы больше надеемся на какую-то зрелость, личную ответственность. Ну и главное, чтобы были выполнены задачи и как бы на связи
46:39
Speaker A
быть и всё. Вот. Да. О'кей. Нет проблем. У меня вот на последний месяц такая же всё то же самое было и было нормально.
46:47
Speaker A
О'кей. А если предложим тебе слоты для знакомства с продуктоунером команды на полчасика, сможешь пообщаться? А сегодня завтра?
46:57
Speaker A
Я даже сегодня я даже сегодня мог бы. О'кей, супер. А смотри, я тогда чуть позже тебе напишу и посмотрю его слоты.
47:05
Speaker A
Вот. И глянь тогда, как какой слот тебе больше подходит, и поставим встречу. Потому что в идеале мы, честно говоря, на этой неделе хотели бы тоже финализироваться.
47:17
Speaker A
Вот. что просто не затягивать никого. Да, хорошо, нет проблем. Вот у тебя ещё есть вопросы? Если есть, у нас есть время, оно остаётся, мы можем поотвечать.
47:27
Speaker A
Ой, наверное, вопросов на самом деле больше нету, и я тоже не стану держать. Угу. О'кей. Хорошо. А тогда расходимся.
47:36
Speaker A
Угу. Спасибо. Да, вам спасибо большое. Да, тогда на связи. Да, на связи. Пока-пока. Пока.
47:45
Speaker A
Пока. Если хочешь ещё больше реальных собеседований на системного аналитика, то подписывайся на мой Бусте. [музыка] Там уже больше 40 записей собеседований из самых разных сфер. Финтех, крипта, бетинг, developмен, аутфинг и так далее.
48:02
Speaker A
[музыка] Все записи с таймкодами. И, что важно, все собеседования настоящие. Часть мои, а часть от подписчиков.
48:09
Speaker A
Помимо самих собеседований в сообществе уже накопилось много полезного контента. [музыка] Гайды по составлению резюме.
48:15
Speaker A
гайды на легенду, гайды на софтскилы, гайды на проектирование апи и так далее. По сути, это большая база знаний для системных аналитиков, которая постоянно пополняется. Мы создаём коммьюнити аналитиков, где всегда можно делиться своими успехами и неудачами. Так что подписывайся на Бусти, буду рад видеть,
48:32
Speaker A
а дальше жду тебя в закрытых чатах в Телеграме. Всё, обнял. Пока. M.
Topics:системный аналитиксобеседованиеBPMNюзкейсыпроектирование БДтехническое интервьюбеттингIT-карьератребования

Get More with the SozAI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries and speaker detection. 30 minutes free.

App Store Google Play
Or transcribe another YouTube video here →

Free tools: TXT to SRT · SRT Validator · Merge SRT · Subtitle to Text · All tools

More from Метавижн

View All
Реальное собеседование на системного аналитика: ЗП 160К — Transcript30:10
Реальное собеседование на системного аналитика: ЗП 160К — Transcript
3,986 1 Russian
Внутренний диалог с бездной… — Transcript3:28
Внутренний диалог с бездной… — Transcript
296 1 Russian
1941: Нападение на СССР / Вторая мировая война / Уроки истории / @MINAEVLIVE — Transcript1:09:48
1941: Нападение на СССР / Вторая мировая война / Уроки истории / @MINAEVLIVE — Transcript
8,772 1 Russian
BETA PORTAL 2 | ПЕРИОД F-STOP — Transcript16:33
BETA PORTAL 2 | ПЕРИОД F-STOP — Transcript
2,700 1 Russian
Инфраструктура российского инвестрынка — Владислав Кочетков — Transcript1:24:20
Инфраструктура российского инвестрынка — Владислав Кочетков — Transcript
12,593 1 Russian
CV | Прогон CV: самопрезентация и поведение на собесе — Transcript1:13:53
CV | Прогон CV: самопрезентация и поведение на собесе — Transcript
8,783 1 Russian
CV | Ошибки в рассказе об опыте на техсобесе СА — Transcript59:22
CV | Ошибки в рассказе об опыте на техсобесе СА — Transcript
6,893 1 Russian
CV | Как рассказывать о проектах на собесе СА — Transcript55:56
CV | Как рассказывать о проектах на собесе СА — Transcript
7,029 1 Russian
Умирающие профессии в IT — Transcript40:31
Умирающие профессии в IT — Transcript
5,203 1 Russian
Угадай Мем – Получи Деньги! Я Собрал Все Легендарные Мемы! — Transcript1:25:51
Угадай Мем – Получи Деньги! Я Собрал Все Легендарные Мемы! — Transcript
12,685 1 Russian
Как разблокировать инстинкт власти: 4 шага к уверенности и мотивации — Transcript15:11
Как разблокировать инстинкт власти: 4 шага к уверенности и мотивации — Transcript
2,326 1 Russian
Исправленные техники поиска любимого дела — Transcript19:41
Исправленные техники поиска любимого дела — Transcript
3,171 1 Russian