Реальное собеседование на позицию системного аналитика: опыт кандидата, работа в Израиле и России, вопросы по REST, HTTP, базам данных и диаграммам. Зарплата 160к.
Key Takeaways
- Собеседование на системного аналитика включает как вопросы о предыдущем опыте, так и технические вопросы по API, базам данных и архитектуре
- Кандидат с опытом работы в аутсорсе, SAP, логистике, медтехе и страховании демонстрирует широкий технический кругозор
- Вопросы по REST и stateless-архитектуре, индексам БД и диаграммам — типичные темы для системного аналитика
- Интервью проходит в формате диалога с техническим директором, заместителем и HR-специалистом, длится около часа
What the video covers
- Автор показывает реальное собеседование на позицию системного аналитика, персональные данные и названия компаний скрыты звуком-пиканьем
- Кандидат рассказывает о карьере: программист в аутсорс-компании в Израиле, работа с SAP и VBM, затем аналитик в логистике, медтехе и страховой
- Описан типичный рабочий день системного аналитика: двухнедельные спринты, дейлики, груминг, ретро, работа с разработчиками в Яндекс Трекере
- Причина ухода из компании — распад команды после ребрендинга и финансовые проблемы
- Кандидат описывает функционал реинвестирования полисов ДМС на монолитной системе
- Обсуждаются вопросы переезда из Израиля в Москву в 2019 году и планы остаться в России
- Интервьюер спрашивает об опыте интеграции с платёжными системами и о плохих практиках FTP-интеграций
- Разбираются теоретические вопросы: что такое REST, основные HTTP-методы (GET, POST, PUT, DELETE), stateless-архитектура
- Обсуждаются индексы в базах данных, роль системного аналитика в тестировании и сборе требований
- Затрагиваются инструменты построения диаграмм и метрики проектов, включая оценку разработчиков по грейдам
Chapters
- 00:00Вступление и начало собеседования
- 02:33Карьерный путь кандидата: Израиль и SAP
- 04:25Рабочий день системного аналитика
- 06:47Причина ухода и переезд в Москву
- 09:47Опыт интеграций и плохие практики
- 13:53Технические вопросы: REST и HTTP
- 18:33Stateless-архитектура и метрики проектов
- 23:29Индексы БД, диаграммы и платёжные интеграции
Full Transcript — Download SRT & Markdown
Speaker A
это первое реальное собеседование на позицию системного аналитика на тубе по сути как первая научная история войны 1812 года до этого на ютуберы собеседования мне пришлось запикать личные данные имена и названия компаний Собес получился кайфовый и невероятно быстрым ребята которые меня собе сили
Speaker A
мне очень понравились наверное самое нено собеседование на моей памяти я долго не мог определим звуком пикать личные данные поэтому не пугайтесь когда услышите это мяу хорошего просмотра Да здравствуйте Да извините отходил воды налить Да добрый день ещё есть время ребята
Speaker A
подключаются а супер А да тогда подождём коллег и будем начинать Да хорошо А меня нормально слышно вас отлично слышно да Ага Спасибо большое Да ещё Скажите пожалуйста у нас получается собеседование будет час длится правильно Ну я думаю даже чуть
Speaker A
меньше обычно час не сидим где-то 40-50 минут а Окей угу ну я просто хотел ещё Да если она час злится чтобы я тоже в конце мог свои вопросы задать это обязательно это обязательный этап мяу е раз ты будеш окне Или он отдельно
Speaker A
подключится под ещ А всё да Всех приветствую Привет Да ещё раз привет Дава Начинать все в сборе [музыка] Да конечно на те будет лучше супер А меня зовут мы с тобой переписывались с нами технический директор заместитель сегодня в таком составе
Speaker A
пообщаемся хотелось бы послушать про твой опыт а очень много всего интересного рассказывая С чего удобно начать и там уже будем в процессе обмениваться вопросами Да конечно ещё раз Всем привет А я работал ну в начале я работал просто
Speaker A
в outsource компании в Израиле А меня там на всякие проекты кидали был в проекте логистической компании работал там программистом работал даже с сап Если знаете такую технологию она уже ушла но когда-то была вот тоже был программистом на этом сапе и vbm
Speaker A
получилось немного поработать где-то полгода проект там был с ним связан и вот на сапе я узнал что есть такие люди как сап консультант а они оказывается ещ и аналитикой по сути занимаются и я решил тоже стать аналитиком после этого
Speaker A
собственно вот я поработал логистической компании аутсорс и в России я уже приехал работал в медтех в страховой там уже работал аналитиком А вот подключены к нему до сих пор Да давай Наверное тогда там поподробнее как вообще какая была твоя
Speaker A
роль Как проходил там средние статистически день да конечно да Супер Тогда вы знаете называется Они вроде ребрендинг сделали вот я работал уже как раз-таки системным аналитиком отвечал за пару систем то есть у меня был Монолит на котором проводились вообще все платежи все вот
Speaker A
эти DMS оформлялись и тому подобное плюс его распиливали сейчас активно на микросервисы а на то чтобы люди могли заключать Ну типа выбирать себе какой-то полис ка который они хотят а какой-то DMS и тому подобное вот я отвечал за м систему и за бэк систему
Speaker A
соответственно А как у нас вообще выглядел рабочий день мы у нас двухнедельный спринт был всегда дейлики каждодневные Груминг Груминг ретро Ну вот вся вот эта менеджерская история присутствовала мой день выглядел таким образом что Ну если спринт начался у
Speaker A
меня есть какой-то пул задач в моём трекере пользовались мы Яндекс трекером ушли из жиры я узнаю что у меня за задача созванивался с разработчиками даю Им задачу если она есть Если нет то Окей угу А ты уже покинул Нет я ещё
Speaker A
работаю А почему Хочешь что-то другое ну у нас как-то получилась после ребрендинга какая-то непонятная история с финансированием и очень команда стала распадаться в которой я работал и мне это не нравится то есть мне нравилось работать с теми людьми с которыми я
Speaker A
работал некоторые уже ушли Вот и поэтому из-за того что команда распадается Я тоже решил покинуть компанию что сейчас хочется дальше какие может быть сферы опреде Ну вот я Уви сча Когда что плютом открыл вакансию а там написано совмещение системного аналитика и про
Speaker A
менеджера мне показалось это тоже довольно Интересная история потому что где бы я не работал было всё отдельно был прожект менеджер и был системный аналитик совмещённый этой вакансии такого не было а про можешь поподробнее какие-то были с банальная передача каких-то данных по ге
Speaker A
посту Ну собственно ничего такого сверхъестественного мы не [музыка] делали так хорошо А что из всего то что ты делал раньше как системно анали те Больше всего мне Рави придумывать разный функционал Вот например последнее на ЧМ я занимался это функционал реинвестирования полисов
Speaker A
ДМС то есть и не только страховых полисов тоже то есть люди пришли заплатили деньги там на 10 лет или на 5 лет может быть на год они хотят Дальше реинвестировать те деньги которые получили благодаря тому что эти полисы
Speaker A
покупали вот я этот функционал прорабатывать делал его на нашем монолите который на самом деле коробочный Но можно было на него что-то накинуть В итоге вот накинули такую вещь Угу хорошо А так я тогда пока что передам слово и
Speaker A
тогда потом ещё в конце по О'кей а так ну давай я начну Тогда вопрос Ну такой сначала общего плана Я ведь правильно понимаю что перед работал из Израиля потом переехал в Москву вот А подскажи а почему такое решение Ну почему именно в Москву именно
Speaker A
в Россию из Израиля Почему из Израиля уехал Почему не наоборот я понял я я понимаю о чём вы говорите это на самом деле классный вопрос Спасибо что задали А всё просто я в девятнадцатом году уехал Я закончил бауманку и поехал
Speaker A
учиться ну типа мне было просто интересно попробовать Смогу ли я найти работу в зарубежной компании просто галочку я это сделал в девятнадцатом году я нашёл а потом ковид я вообще не планировал уезжать яма я год поработаю и вернусь ковид потом ещё события события
Speaker A
и у меня не получилось вернуться А я всегда хотел собственно я не спланировал оставаться в Израиле на всю жизнь И сейчас я бы на самом деле не променял Москву там или Петербург я сейчас был ещё на Дальнем Востоке зимой Ну вот
Speaker A
зимой на новом году новый год и это было прекрасно и уезжать Я не собираюсь Нет А я понял хорошо то есть ты ну в ближайшем будущем планируешь в целом быть Ну как минимум в России да Да вообще ну там планы долговременного
Speaker A
отъезда из Москвы есть ли что-то такое Нет на самом деле нет ну я люблю поездить по России но это не то чтобы я уезжал там на месяцы Ну на 2 недели на неделю Угу я понял я понял хорошо А
Speaker A
слушай Такой вопрос вот ну у нас сам сервис наш построен в целом на а то есть это серверное приложение мы отдаём на сторону клиентам А для того чтобы они могли выполнять платежи у тебя как я понимаю опыт интеграции с есть Да
Speaker A
конечно Вот Ну а можешь из своей практики привести пример какого-то плохого А когда ты интегрировать к какому-то партнёру и тебе прямо вот резала глаз какая-то конкретная реализация Я могу рассказать это вообще жесть была потому что у меня был внешний
Speaker A
заказчик закидывает нам для оформления посо каких-либо что быте подумать Это был FTP файл который был какой-то очень кривой там были какие-то непонятные данные и вот эта интеграция с этими FTP файлами Я их терпеть не могу вот я их очень не люблю
Speaker A
плюс есть такое ещё на проекте когда Ну большая текучка люди рисуют какие-то апе А зачем они нужны какие-то методы Да имеются в виду А зачем они нужны и к чему они непонятно они существуют там есть какие-то ключи значения что они
Speaker A
делают ни в документации нигде нет конкретного примера я к сожалению привести сейчас не смогу но такое имеется Да приходится дополнительные задачи делать на то чтобы избавиться от этого ну так скажем цифрового мусора можно так назвать Хорошо Окей А вот можешь Ну
Speaker A
такое тоже очень часто встречающийся вопрос Расскажи что такое что такое со Да конечно - это архитектурный стиль основанный на http методе взаимодействие между клиентом и сервером основано на http методе - это уже протокол который взаимодействует с помощью xml
Speaker A
формата то есть там у Наски они жены как в вот если можно могу поподробнее про про методы если это необходимо А давай давай Почему нет Давай остановимся вот я люблю потому что я им занимался как frontend разработчик так как и аналитик
Speaker A
основные методы это у нас getch Del - это у нас на получение информации от сервера то есть получение ресурса с сервера пост на создание ресурса на сервере pch изменения ч - это частичное изменение Т полное изменение ресурса Delete удаление соответственно
Speaker A
Ну ещё есть - это получение метаданных ещё есть options вот это по методам вот Если что-то конкретно да можете спросить Ну это такая те теория конечно всё хорошо вопрос Ну вот те допустим двух реализаци что больше нравится и
Speaker A
почему Ну вот если ты допустим своё А проектировал ты бы что выл Всё я понял да но я всегда ре люблю потому что он более проще для меня Я вообще не люблю xml и SU но я понимаю зачем он нужен
Speaker A
более безопасный То есть если у нас есть какие-то такие данные очень чувствительные так это назовём то я был конечно использовал Но если у нас не чувствительные данные Мы хотим быстро что-то реализовать Я бы выбирал Ну репи какой-нибудь делал Угу хорошо а как ты
Speaker A
определишь Ну вот что А restful по каким признакам Ну во-первых у него не у нас есть собственно вот эти методы которые я перечислял у нас есть какая-то Ну я могу её посмотреть в Нетворк Да что мы за запрос делаем как
Speaker A
он выглядит то есть мы не меняем состояние сервера если это Иден патентный метод То есть я тоже понимаю что это рест в лапе вот а что ещё не знаю даже как ответить по-другому на этот вопрос Ну смотри одним давай так одним
Speaker A
из признаков Ну там есть ряд признаков одним из признаков вобще ресл является то что сервер не хранит состояний А ну да вот а ну вот допустим Если мы на этом остаёмся чуть чуть поподробней А зачем это сделано то есть зачем это во Ну да то
Speaker A
есть мы всегда Обращаемся к серверу как будто бы мы к нему не обращались получается каждый раз по-новому и Ну во-первых мы не нагружая сервер какими-то данными А например то же самое с каширу емо да то есть каширу емо у нас
Speaker A
в браузере лучше всего сделать чтобы сервер не нагружать Ну и здесь Наверное мы не хотим хранить состояние Никакое и не таким образом мы можем не делать какую-то проблему с данными которые мы хотим получить с сервера не совсем поня
Speaker A
Ну имеется в виду что если он бы хранил состояние какое-то то нам было бы наверное сложно их как-то получать правильными Я бы так это назвал Если я правильно понимаю как это всё устроено Ну а можешь пример какой-то привести Ну там на практике вот любое
Speaker A
приложение с Любой логикой какое какое в голову придёт угу вот ну Чем допустим Stat Север помогает чем stateless сервер помогает Надо подумать сейчас а какое приложение Наверное если мы делаем запрос на какой-то поиск авиабилетов на каком-нибудь авиас например А мы могли
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
Да которые затратил человек на выполнение той или иной задачи Ну хорошо Да давай тогда на этом пока остановимся просто хочу ч что если допустим ты меряешь Ну например в затраченных часах Ну работу например тестировщика а qa специалиста у тебя один потратил на
Speaker A
задачу там условно 3 часа второй потратил 30 часов Но это ведь не показательно потому что специалист потративший 3 часа мог проверить плохо а потративший 30 часов мог сделать очень качественное подробное тестирование которое нашло много багов В итоге Ну то
Speaker A
есть тут такая история Она в целом изначально вопрос В некоторой степени на фантазию Хорошо если говорить опять-таки про проектную работу Какие задачи ты не стал бы делегировать никому и почему Окей А какие бы задач не стал делегировать наверное Первое - это сбор
Speaker A
требований и общение с заказчиком Я бы сам этим занимался потому что ну уже да большой опыт у меня есть Прим и на русском языке и на иврите поэтому бы людей тоже очень важен бывает и у меня есть опыт и так и
Speaker A
с этой стороны и с той Вот Потом наверное если бы мы делали какой-то регресс тест Я бы тоже при нём участвовал То есть я бы следил за тем как он происходит потому что если мы выкатываем что-то в продакшн не хотелось
Speaker A
бы чтобы это была какая-то потом лажа какая-то ошибка произошла Вот поэтому я бы за этим тоже следил не то чтобы я сам тестирование проводил Я просто участвовал при регресс тестировании И уже потом при выводе в прот нашего какого-то функционала или ещё чего-то
Speaker A
вот наверное эти основные задачи которые я бы сбор требований брал бы сам а остальные бы прямо монитори [музыка] да у Ну если ещё Окей если есть ещё какая-то серьёзная аналитическая задача Такая прям Ну например у нас не хватает
Speaker A
ресурса вс-таки а нужно выполнить какой-то проект не знаю какой-то функционал я не буду же нагружать ещё больше мы тогда вообще ничего не успеем тогда конечно я бы взял на себя какие-то обязательства и задача если они связаны с аналитикой А если не связаны Но если это
Speaker A
программирование если это фронтенд и я может быть смог бы помочь Я ещё его помню А если это qa тестирование и оно мануальное мы тоже можем этим сделать То есть я это тоже могу на себя взять мне в принципе на самом де было бы равно мне
Speaker A
главное чтобы проект у нас как бы работал и Ну мне самому интересно было бы всё делать я и на этой работе Я и тестированием занимался собственно функционала который мы делали и при регрессе участвовал и все требования собирал Поэтому собственно я и это сам готов
Speaker A
делать А что тебя мотивирует не знаю меня на самом деле наверно особо ничего такого не мотивирует мне просто нравится делать что-то Вот такое процесс да наверное процесс Угу А так так так так А давай наверное уточ какие-то Вопросы
Speaker A
задать Ну да с а Слушай у тебя как-то писал типа есть опыт работы с SQ Да да да А в чём разница между in Jo Jo А ну это разные запросы на соединение таблиц то есть Left Joint соединяет все
Speaker A
строки Ну все значения из левой таблицы и совпадающие в правой правый делает наоборот inner Join - это по-моему обычный Join и Full Join - это Join который объединяет обе таблицы [музыка] Окей А знаешь что такое ur что ещё раз
Speaker A
ur есть вот что это такое честно говоря Нет незнаком незнаком окей а работал знаком с брокерами очередей Да конечно знаком не то чтобы они у нас прям очень жёстко использовались на проекте но да кавка у нас была а
Speaker A
подсказка была да да а с кроликом не знаком с кроликом Нет к сожалению нет Окей А можешь объяснить что такое нормализация база данных Да конечно это избавление от избыточных данных в базе данных соответственно то есть в каком-то определённой у нас там табли есть
Speaker A
ненужные данные которые можно было бы поделить То есть декомпозировать например или просто их можно было бы убрать у А что такое индекс в базе данных индексы нам нужны для того чтобы быстрее искать какие-то данные с помощью селекта Вот они ускоряют Процесс
Speaker A
поиска Угу О'кей нуно у меня наверное пока всё так я кажется у нас внезапно пропал А всё появился Слушай хотел спросить можешь ещё буквально паре слов рассказать про инструментарии которым пользовался чем работал с А чем с базой где смотрел логи просто чтобы стек твой
Speaker A
подробнее понимать и наверное перейдём тогда к вопросам в обратную сторону Оке а вообще все весь инструментарий Я так понял которым я пользуюсь на работе вообще любой А ну для база данных это у нас Ой База знаний база данных База
Speaker A
знаний это у нас confluence всегда и либо Яндекс Wiki был notion пока его тоже не блокли ene тоже умеем пользоваться Но это по сути всё одно и тоже ничего там нового интересного нету трекеры - это джира асана это была вот в
Speaker A
Израиле почему-то Там никто джири то не пользовался все были на этой асане и Яндекс трекер А по апе это сгр да то есть в документация по апе у нас в сагре находится А что ещё такого я не назвал Я активно
Speaker A
пользуюсь нейросетями Вот дисик Вышла тоже им пользуюсь Зачем для быстрой работы очень часто если у меня апе со 100 значениями я это всё ручками прописывать не хочу не хочу тратить время я прошу Просто ну можно убыстрить документацию таким образом объяснив в
Speaker A
нейросети как это сделать а вот что ещё такого я могу использовать а для построения диаграмм многие люди тоже пользуются зачем-то Dr до сих пор Мне кажется это тоже прошлый век потому что самому эти стрелочки рисовать очень Мне не нравится очень долго а я
Speaker A
использую плюс если тоже опять-таки не хочется время тратить неть написал какое-нибудь как пользователь взаимодействует или как у нас взаимодействуют методы скопировал то что тебе дали Вставил в on получил диаграмму буквально 5 минут в Я бы это рисовал минут 30-40 вот это мой
Speaker A
инструментарий в принципе хорошо окей а сном приходилось ли работать да сном работал конечно да забыл о НМ уточнить Окей Ну давай тогда мы на твои вопросы поо отвечаем супер во-первых Я бы хотел уточнить почему вы решили совместить системного аналитика и прожект
Speaker A
менеджера потому что команда в целом У нас маленькая компания небольшая У нас во всей компании всех сотрудников чуть больше п человек вот и соответственно Ну там когда по направлению аналитики Ну работает немного специалистов вот там из малого количества Люде
Speaker A
отвечающих людей за сопровождение проекта техническое отдельно за контроль за задачами вот показалось Ну чрезмерным показалось что в целом соединяется пока что это в одном специалисте вообще говоря я думаю что это исключительно такая вещь связаная с масштабированием что при расширении штата все
Speaker A
естественным образом приходят к тому что с Дели с груминга или по-другому вы работаете не по-другому у нас не гибкая история в плане разработки у нас модель Можно сказать что итерационная то есть мы выкатываем не конкретными готовыми спринта вот а по готовности задачи То
Speaker A
есть когда задача проходит свой жизненный цикл Вот и доходит до этапа релиза тогда мы её и выкат свои собственные внутренние встречи конечно же есть внутри каждого отдела и смежные Вот Но они не закреплены как Ну допустим в гибкой
Speaker A
методологии разработки если мы говорим про скра Там есть ну бы свои встречи с ими наименованиями вот у нас такого на данный момент нет Ага и получается что задачи Вы тоже оцениваете Ну вот можете сказать там на эту задачу мне может
Speaker A
неделя понадобиться вот типа такого А ну это вот тако оче удоб же это с способен обычно все всё равно не успевают За эти 2 недели сделать толком ничего поэтому Да я бы тоже такое использовал Ну вот мы тоже с этим
Speaker A
столкнулись что когда начали Ну у нас два проекта когда мы начали свой более мелкий проект пробовать загнать в спринты сразу начались все проблемы с задачами которые из него вываливаются их нужно декомпозировать Ну в общем Ну там скатывается тех долг тех долг лежит
Speaker A
какой-нибудь ещё там куча задач я понимаю это может давить на самом деле на разработчиков тоже окей а как то есть я правильно понимаю что к вам вы находите Компани или они приходят к вам и говорят Мы хотим подключить вот сервис
Speaker A
и уже аналитик например собирает требования Каким образом мы будем подключать этот сервис к заказчику а в целом Да так и происходит приходит заказчик говорит что он хочет получить от сервиса то есть Какой банк может быть ему нужен какой-то конкретный банк через который
Speaker A
он хочет работать мы смотрим есть ли у нас с ним интеграция какой-то конкретный платёжный инструмент вот Ну например там сбп намер нужен конкретному мерчант вот или ещ что-то или обыч плата картами вот в зависимости от этого мы определяем То
Speaker A
есть если у нас для этого все готовы выходы все элементы нашей интеграции Вот и дальше ИТ по одной из двух веток если у нас ВС есть то его подключает на проверят для него терминалы Вот а если у нас чего-то
Speaker A
не хватает тогда Ну это уже идёт Задача В разработку мы готовим под него решение понял понял Ну здорово Да у меня наверное больше вопросов нет спасибо вам большое за интервью Если вам понравилось видео то несите свои денежки на мой Буе я его
Speaker A
начинаю разными материалами или Можете просто разово задонатить На микрофон или ещё что-то также подписывайтесь на мой Telegram канал пока мяу
Topics:системный аналитиксобеседованиеIT карьераREST APIHTTP методыSQL индексысистемная аналитикасобесработа в ITзарплата аналитика











