0: Ещё раз здравствуйте, очень рада вас приветствовать. Меня зовут Динус Хон, я являюсь it рекрутёром банка эсхата. Благодарю вас за интерес, проявленный к нашей вакансии, и за то, что нашли своё

1: Время и за ваше терпение, что из за 2 отложений вы все-таки поддержали нас за это. Благодарю. Давайте я вас познакомлю с участниками собеседования. Мама. Он является сервис

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

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

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

5: Финансового сектора Таджикистана, мы входим в топ 3 крупнейших банков страны и активно развиваемся в направлении цифровой трансформации. Вот в 2025 году наш банк именно принял стратегию цифровой трансформации и развивается именно

6: В этом направлении сейчас уже более 15 команд, они уже организованы и практически укомплектованы. И вот мы сейчас в острой нехватке бэкенд разработчиков

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

8: Кандидатов со стран снг. Поэтому у нас сейчас многие наши сотрудники, которых мы ищем, они уже работают удалённо. Это получается с Алматы, их очень много там с респу.

9: Республики Беларусь также с России. Поэтому хотелось бы у вас спросить, Станислав, почему вы откликнулись на данную позицию, на данную вакансию? Почему сейчас в поиске немножко расскажите о себе.

10: О своём крупном проекте, который вам запомнилось. Какую роль вы там играли, ключевую роль, было бы интересно узнать о вашем опыте. Слово передаю вам. Угу. Ну вот, начнём слышно по порядку, наверное. Угу. Да, да, слышно.

11: Давайте. Угу. Почему откликнулся? Ну, мне, в принципе, привлекательна эта сфера, банковская деятельность. Довольно интересно работать именно там. Вот. И я так посмотрел, у вас довольно крупная, интересная компания.

12: Рынка, скажем так, по сути, что ещё следующее? Почему об опыте рассказать, да, по сути, разработчик

13: Чуть больше 3 лет опыта, ну, за свою жизнь успел поработать над 2 такими довольно крупными проектами. 1 это была образовательная система довольно крупная. Все проекты были на микросервисной архитектуре, то есть

14: Довольно нагруженная по последнему проекту. Это был была платформа для быстрой доставки, плюс ещё интеграции. Ну, в общем, там довольно был широкий функционал.

15: Вот, что тут могу сказать. Работали по скраму. Компания была довольно, ну, моя команда была довольно большой, то есть 11 человек, по сути, несколько разработчиков, тимлид задачи, мы

16: Мы распиливали все вместе, то есть кодревью у нас тоже было перекрёстное, то есть нужно было, чтобы 2 человека

17: Подтвердили код перед тем, как он пойдёт на тестовый стенд, н, на тестовый стенд. Да, вот что ещё тут могу сказать по моей Роли, которую занимал. Ну, я везде был.

18: Дотнет разработчиком. То есть задачи какие-то с фронтом я на себя особо не брал. Ну только если приходилось пару раз вот на 1 месте работы. Что ещё тут могу рассказать?

19: По интересным каким-то кейсам, наверное, все из немножко расскажите о Сбере. У вас был такой опыт? Вы работали в Сбере? Угу. Ну, по сути, работал я там через аутстафф, да?

20: Работал над внутренней и частично внешней образовательной платформой для Сбера и ещё немного над другими проектами в начале. Вот что ещё.

21: Занимался интеграциями, занимался оптимизацией запросов.

22: По большей части вот.

23: Ну, тоже довольно большая команда была, типа, 13 человек. Около того нагрузки тоже были довольно высокие. По стеку был довольно современный, то есть дотнет 8 мы использовали донат 6 и

24: Потом переходили на больше, на 8. Вот.

25: Так, хорошо, Станислав, у меня такой вопрос. Какие вы сложные вещи вы сделали в своём опыте, да, какие-то там самый крутой, крутой вещи, да?

26: Так, ну по сложным вещам, чем я занимался? Это была потоковая обработка видео. Ну, на 1 месте занимался, ну, в рамках образовательной платформы, делал систему для

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

28: Свою систему, потому что готовые, ну, есть много довольно готовых решений, они нам не особо подходили. То есть нужен был некоторый ещё свой функционал по доработке. Вот 1 задача была потом ещё

29: Из интересного принимал участие в разработке инфраструктуры, то есть делали под свой сервис.

30: Out бокс, который много где использовался потом. Ну то есть это был как

31: Такой своего рода проект, вот который обеспечивал надёжность многих узлов системы. Вот.

32: Ага, хорошо.

33: Хорошо, тогда я сейчас скину ссылку, да, там есть задачка, там сразу начинаем с практики. Угу. Потом постепенно.

34: Хорошо.

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

36: Ikki да окей, тогда все было прозрачно ага, хорошо, ща поделюсь, тогда как тут.

37: Угу. Так, вижу задачку.

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

39: Тут в принципе написано 1 у нас идёт структура point, потом класс circle в классе сёркл, у нас есть паблик поинт и int радиус окей, так.

40: 1 point, п 2 п. 1 окей, п 2, точка.

41: Угу. 1 точка x. Так, ну.

42: По сути, п поинт это у нас тип структуры, да, то есть при присвоении она копии.

43: Вот, поэтому все ещё будет единица. Вот это не ссылочный тип.

44: Так, да. Угу.

45: Так, это так, окей, хорошо. Так, дальше у нас идёт c1 это не circle центр.

46: П 1, радиус равно. 5, ц, 1, ц, 2, равно, c1. Да, присваиваем по ссылке. Ц, 2, точка центр равно 20. Окей, ц, 2, точка, центр равно.

47: Так. Угу. Это структура. То есть теперь у нас, если

48: Так, ну все запутано, но, по сути у нас будет 20, потому что мы взяли

49: C2 у нас является ссылкой на тот самый сёркл, который был изначально. То есть c2 у нас, так как circle ссылочный тип, потом мы берём c2 структуру, то есть

50: У этого мы меняем внутренней структуры центр мы ставим икс на 20, то есть будет 20. Так, срочный. Хорошо, Станислав?

51: Сразу расскажите, пожалуйста, про там немножко, да, про структуру, про класс и про семантику ихней работы, да? Угу. Чем они отличаются? И когда использовать структуру, и когда использовать class, да, так.

52: Понял. Ну, структура и класс это так, наверное, начну с того, где они хранятся. То есть структура у нас может храниться как на стеке, так и в куче. Класс у нас всегда хранится.

53: В куче. Ну, за редкими исключениями, если мы там не используем какой-то код, по сути, чем они отличаются. Ну, 1, что это передача в методы. То есть классы у нас передаются по ссылке структуры у нас передаютс

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

55: Что они аллоцируются на стеке. Вот. Угу. Что тут ещё могу добавить. Ну.

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

57: Вот структуры только если у нас какие-то высокопроизводительные сценарии, типа там внутри функций каких-то вот в основном используются классы, да?

58: Так, а вы исполь, вы, а вы использовали вообще в своих практиках структуру?

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

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

61: Так что ещё тут? Ну да, класс единственный минус, что он даёт нагрузку на Гарбач коллектор, по сути. Вот. Да, хорошо. Кроме структуры и класса в дотнете ещё недавно появи.

62: Record, да? Угу. Рекорд. Чем отличается вообще рекорд от самого класса? И когда используется рекорд рекорд, ну, обычно для детишек всяких используется. То есть

63: Для трансферинга данных, то есть перенос их. Вот, ну, по сути, рекорд это просто редон, ну, делает класс ридонли, можно ещё там, по моему, написать ридонли стракт, то есть структуру сделать редон. Ну да.

64: Просто делает все, делает объект мутабельным.

65: Кроме этого ещё есть какие-то отличия там между рекордом и классом.

66: Там, по моему, праймери конструктор чуть чуть по другому работает, но там, по моему, значительных таких отличий больше нет. То есть то, что разве что, ну вот только иммутабельность.

67: То есть, что мы не можем менять его в процессе. Ну, после создания. Вот. Угу. Хорошо. Тогда идём дальше, да. Угу. Переходим к следующей, да.

68: Дальше у нас тип string. Так, string у нас.

69: Это ссылочный тип, поэтому. Угу. При присвоении у нас будет

70: Тут одинаковые строки, да, то есть одинаковая ссылка. Так что ещё тут могу заметить, что тут будет использовано, использован пул интернирования, то есть интернирование.

71: Строк вот могу подробнее рассказать угу. Так, тут консул Ратна эс 1 и c2 сейчас посмотрю так, c1 hello эс 2 равно эс 1 эс 2 равно c.

72: 2. Плюс вот так. Ну так как строки у нас иммутабельные, вот в этой строке 25 будет создаваться под капотом новый объект. То есть новая строка у нас будет hello, world. Угу. Да, при этом

73: Так, с 1 у нас так и останется хло, по, судя по всему.

74: Получается, тут у нас ведётся с 2, у нас точно будет.

75: Угу. Тут у нас будет, получается. Угу.

76: Подумаю. Ну да, по сути хеллоу, да, как я сказал.

77: Хорошо.

78: Тогда следующий, следующий вопрос. Вы ранее упомянули про garbage collector, да? Вообще, что такое там гарбедж коллектор? Можете рассказать про него? Так?

79: По сути, Гарбич, коллектор это такая, такой механизм дотнета для управления памятью. Он включает в себя несколько поколений и, по сути, он управляет даже несколькими кучами, то есть есть small обжектив, есть лардж обжект.

80: Хип есть ПИН обжект хип смол обжект хип у нас делится на 3 основных поколения то есть нулевое 01.02 так в нём хранятся объекты в small обжект хип её.

81: 85 килобайт, то, что больше у нас уже идёт лаш обжект хип по основе. Так, по алгоритму работы. Он сначала, вообще в дотнете сейчас

82: Современным используется background алгоритм работы, то есть там есть несколько их режимов.

83: В общем. Угу. Так, рассказывать подробнее или этого хватит?

84: Этого хватит k тогда сейчас скину, там другой вопрос это

85: Вопрос касаю. Да, сейчас скину задачку. Угу.

86: Все вижу, все так, nick, группировка и агрегация.

87: Так, понял вас. Так, есть класс ортер, есть string кастомер есть e mount её окей.

88: Так, что нужно делать, собственно, а вот задача сгруппировать по клиентам и посчитать сумму каждого заказа. Угу.

89: Так, окей, ну тут вообще такая задачка на sq, окей?

90: Общую сумму, конечно, сейчас подумаю, как это сделать.

91: Угу.

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

93: Не сложно, должно быть.

94: Так группируем по кастомеру и ну или по customer id, но тут customer стрингом задан, поэтому не по customer id.

95: Так, создаём анонимный объект.

96: Угу.

97: По моему так было, так и нам нужно ещё total amount, там нужно использовать функцию сумм для того чтобы посчитать.

98: Угу. А, ну да.

99: Так. Угу.

100: Ага. Ну, я думаю, нормально будет работать. Да? Хорошо, хорошо. С какими там структурами данных доете вы работали, да, такими, как там.

101: Ага, понял, да, вопрос понял ну вообще в шар их довольно много. То есть есть лист дикшенери аррей обычный, очередь, там q есть двусвязные списки, односвязные списки так, ну.

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

103: Мы увеличиваем в 2 раза так из ну есть также q и стек, то есть они работают по лифо и фифо, то есть last in first out и first in first out вот.

104: По, по дикшенери могу вот что сказать, что это такая

105: Ну, такой класс, который под капотом содержит 2 массива. Массив ключей, массив Бакетов. Угу. По сути, он работает с помощью hash кода, поэтому сложность получения в нём

106: От единицы, но не всегда, потому что у нас может быть очень много коллизий и, по сути, сложность может быть, о, от количества элементов в бакете. Вот. Угу. Так.

107: По алгоритму работы. Ну, в общем, он сначала берет хэш код, берет от него остаток. Этот остаток, по сути, является этим его индексом в этом массиве баки.

108: Да, то есть в какой Бакет он попадёт конкретное значение. Вот. И в общем, он добавляется в этот bucket bucket это, по сути, связанное, связанный список.

109: Вот, так. Что ещё тут не рассказал.

110: Ну, в общем, ну, хорошо, хорошо. Этого достаточно. Тогда переходим к следующим там вопросам. Угу. У вас, вы сказали, что вы работали там с микросервисной архитектурой. Да, да, да.

111: Как определить там, допустим, к вам пришёл какой-то там проект, да, как вы определяете, что надо сделать по микросервисную архитектуру или там по монолиту как это?

112: Определяйте. Угу. Понял. Вопрос. По сути, у монолитов есть, так скажем, много преимуществ, много недостатков. Вот из преимуществ. То что если у нас

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

114: 1 плюс, что оно поддерживает? Ну, можно писать на многих разных технологиях. Вот, потом, что ещё опять же, удобнее организовывать процессы, потому что если у нас над проектом работает много команд, мы можем как бы

115: Делить их между микросервисами. Что ещё?

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

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

118: Пустяком им, возможно, не надо будет знакомиться со всей кодовой базой для того, чтобы быстро вникнуть в проект. Возможно только с какими-то микросервисами. Вот постепенно можно выстраивать. Что ещё тут можно сказать?

119: Возможно.

120: Ну хорошо, этого достаточно, Станислав, ага. Там, сервисах, архитектурах есть некий там, паттерны, да, можете перечислять их. Ну, вот то, что мы

121: Использовали это out бокс, инбокс есть паттерн, есть паттерн Сага, ну из остальных вот могу подробнее рассказать ну расскажите про outbound ла да, поподробнее.

122: Там какие проблемы решает этот паттерн, да? Так, ну, по проблемам.

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

124: Нам томат гарантируется, ну, на её уровне. Вот.

125: По сути, сам паттерн в том, чтобы мы, вот у нас, к примеру, есть обращение к базе и дальше наше сообщение идёт по какому-то брокеру сообщений, к примеру, в кафку, да, и для того, чтобы мы не поте,

126: Это сообщение, чтобы не было ситуации, не атомарности, когда у нас сообщение сохранилось в базе, но, например, не ушло в кафку или не сохранилось в базе, но, например, ушло в кафку. Вот такие проблемы как раз решает паттерн ноутбок.

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

128: Так, кроме тбокс ещё есть там паттерн инбокс, вы знакомы с этим или не работали с ним? Ну и inbox, да, также работал, по сути, он

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

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

131: Много раз приходит какое-то сообщение. Вот. Угу. И мы заводим некоторые ключ импотентности табличку бок, ой, инбокс. И проверяем, когда к нам приходит новое сообщение, что мы его не обрабо.

132: Вот, чтобы мы не обрабатывали 1 какое-то сообщение 2 раза.

133: По сути, вот так. Ну хорошо, вы упомянули там про пачкав, да? Угу. Вам приходилось ли работать, кроме апокавк, там, с реббитом, да, rabbitmq, да, с реббитом также r.

134: Можете, да, рассказать про разницу-ка, и там rabbit, mq, и когда надо использовать rabbit, или когда использовать кафку. Угу. По сути.

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

136: Выполнены. То есть, как бы сказать так что kafka, она технически чуть проще организована с точки зрения своих возможностей. Вот кафка, по сути, у нас

137: Работает на основании топиков и партиций. А в реббите у нас есть очереди в общем то, хотя они оба такие распределённые брокеры. Вот.

138: Что ещё тут могу добавить? Ну, могу, в общем, углубляться в тонкости кафки и rabbit. Ну, в общих чертах, я думаю так ответить по каким-то практическим кейсам рэббит. У нас, возможно, кафку стоит использовать как

139: Когда у нас очень высокие нагрузки и нужно, скажем так,

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

141: Наверное, реббит. Вот. Ну, в общем, да. Хорошо, хорошо. Ага. Тогда следующий вопрос. Это касательно базы данных, да. Угу. Что вы можете?

142: Сказать про там эсит, да, в принципе, эсит. Ну да. Так, эсит. Это, в общем, такие принципы, которые база данных должна соблюдать, чтобы быть, скажем так.

143: Чтобы гарантировать нам её надёжность. Вот 1, там атомарность, потом консистентность, потом изоляция и потом durability, то есть надёжность её. Вот. Угу. По принципам могу вкратце, рас.

144: А, то есть самый сложный из них, наверное, изоляция, то есть он как бы требует наибольшей, скажем так.

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

146: У каждого сервиса есть своя база данных, да? Ну да, тут можно соблюдать эти принципы, там, если

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

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

149: Вот. Угу.

150: Хорошо, там можете рассказать немножко про как теорему, как теорема, так сейчас вспомню, что это как теорема.

151: Так что я что-то слышал, но, честно говоря, сейчас не вспомню. То есть это, а про то, что система не может гарантировать.

152: Сразу все 3 свойства. То есть типа, да, там были вроде как свойства типа консистентность.

153: Partition tolerance, что-то такое и и надёжность получения ответа. Вот, то есть когда

154: Ну, я довольно давно просто про это читал. Угу. Ну, хорошо, ничего страшного, Станислав, тогда переходим к следующему задаче. Да, сейчас я скину. Окей, другую задачу.

155: Так, так. Угу. Все пришло. Такс, такс, такс, такс, такс, параллельно получение пользователей с ограничением одновременных запросов.

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

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

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

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

160: Вот асинков у нас разворачивается в стейт машину. Ну, там ещё есть много всяких абстракций. Типа, там, сред, да, сред шедулера, таск, пула, там task.

161: Ну, их там довольно много. Могу про каждую так, вкратце рассказать. Окей. Угу. Так, ну, в общем, по базе, думаю, все, если так пройтись, я могу углубиться, конечно, но тут

162: Не очень или 100? Хорошо? Окей, ага. Листай, давай, продолжай. Вот.

163: Так, параллельно получение с ограничением одновременных вопросов.

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

165: Вопросов, то, наверное, по количеству их, да, то есть логически использовать можно симафор какой-то, да, сейчас подумаю.

166: Ту, ту, ту. Так, то есть. Угу.

167: Угу. Ну так, по сути, можем, конечно. Ага, получить, по, пускай параллельно.

168: Можно не более 2 вопросов. Ну да, тут только семафор, по сути, подходит семафор. Это, по сути, такой счётчик. Так, у нас есть этот

169: Угу. Тут только эту, значит, нужно, да?

170: Так, ну ладно, окей, тогда начну, пожалуй, что нам нужен сначала этот юзер айдис, да?

171: Угу. Окей, окей. Типа от 1 до 5, да?

172: Тогда, если у нас есть этот, так, ну ладно, тогда надо создать семафор, они там разные бывают. То есть я могу рассказать немножко по теории. Угу.

173: То есть он бывает именованный, неименованный. У нас ещё есть локи, монитор, ну, лок это под капотом использует монитор. Я думаю, лучше всего использовать семафор слим, потому что он будет, скажем,

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

175: Это уже блокировку на уровне ядра. Ос. Вот хорошо, Станислав, у меня такой вопрос. Да, как раз затронули тему примитив синхронизации. У нас есть там локи и там монитор.

176: Как вы уже ранее упомянули, наша задача, например, у нас было бы условие одновременно должно быть, выполняться не более 1 запрос, да? Угу. Мы смогли бы использовать лог или там

177: Монитор в текущем задаче, если бы был не более 1 запроса, думаю, да, можно было бы. То есть семафор, он, по сути, нужен, когда у нас, ну, семафор он, по сути, даёт

178: Гибкости, то есть мы можем давать более гибкое ограничение на количество потоков, это лок lock и монитор поддерживает ли там асинхронность или нет асинхронные задачи, асинхронность.

179: Нет, мы не можем написать await внутри блока с монитор. Вот почему? Потому что лок, он привязывается к конкретному потоку семафор работает между потоками лок. Он привязывается к конкретному и.

180: Вот. Угу. Так, думаю, отвечу. Да. Ну, там, по моему, даже компилятор подскажет, что так делать нельзя. То есть.

181: Вот, я, кстати, не помню, то есть, когда мы пишем не конструкцию лог, а именно монитор enter, exit, там, компилятор, насколько я помню, не подсказывает, но там, по моему, вылетает какая-то ошибка в рантайме или при компиляции. Вот.

182: Так, так, what используем семафор сним, по моему так, семафор, семафор.

183: Видео и задачи с реальных собеседований на сайте хак собесов точка ком. Хватит гадать, что вас ждёт на интервью. Переходите и получите преимущество перед другими кандидатами прямо сейчас. Так?

184: Что дальше? По сути, нам нужно запустить параллельно несколько Тасков, да?

185: Ну да, я думаю по коллекции просто пройдёмся и запустим несколько Тасков параллельных, чтобы они обрабатывались. То есть var task user id.

186: Select внутри селекта запустим эти таски.

187: Угу. Так, так, ага. Там, по моему, надо было передать, передать внутрь этот.

188: Ну, это называется лямбда выражения.

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

190: Там был, это си, да.

191: Ну да, там есть 2 метода, по сути, вета синк и релиза синг, вот под капотом счётчик для того, чтобы понять, сколько потоков у нас сейчас.

192: Это делает так. Можем ещё сразу докинуть обработку ошибок, наверное. Ну ладно, я уже не буду тратить время, типа написать там какой-нибудь трек кеч.

193: Что там было, который получает из базы по id. Ну, я, наверное, вот это вы немножко там, да, да, вы немножко там перепутали, да, в условии сказано, что

194: Уже есть некий готовый метод, да, get user асинк, который получает id, а вы просто реализуете это, этот метод. Просто надо было вызвать этот метод get user

195: Id параллельно.

196: Угу. Гет юзер айди. Окей. А там условия то было? Сейчас вопросы, условия получает. Ну да, вот просто get user.

197: Сейчас, секунду. Перечитаю параллельное получение пользователей с ограничением одновременных запросов. Метод, который получает пользователи из базы, по его id, необходимо получить

198: От 1 до 5 включительно параллельно.

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

200: Cat user ну давай напишем а db.

201: Так, ну и дальше семафор листа, по моему было. Точка, точка.

202: Так, так, ничего не забыл. Просто там про рафа там забыли, просто когда происходит какая-то там ошибка. Ага. Ну да, да, да. Угу.

203: Try finally сюда вписать? Ну, чтобы релиз был, причём релиз, наверное стоит в блок finally засунуть, чтобы он, ага, лучше корректно завершил там. Да, да, да. Чтобы гарантированно завершил вот угу.

204: Наверное, ключ не буду писать.

205: Так, ai, че то я уже привык к идешке сейчас. Угу. Попробую так выделить.

206: Угу. Так, это нужно. Так, ну вот.

207: Че это такое?

208: Получается. Угу.

209: Ну вот так, в общем.

210: Ну, примерно, наверное, все, да, Станислав, тогда у меня там вопрос касательно там базы данных, у вас есть опыт, там, работы с большими данными, там.

211: Ну да, по сути, работал в основном с посгресом большие. Ага. То есть у вас есть опыт с шардированием или там

212: С партицированием. Ну да, шардированная база.

213: Ага. Какие там стратегии есть? Шардирования? Как вы разделили данные между серверами, да? Угу. Ну, там, по моему, было несколько основных стратегий там.

214: 1, что самое очевидное, это просто по id, там просто делить, да.

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

216: Ключа на разные наши шарды. Угу. И ещё там, ну, они так или иначе, все по ключу, можно ещё по географии как-то делить, там вот такие подходы есть, то есть для каких-то

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

218: Ага, хорошо. Можете рассказать про различия, шардирование, партицирование, да, чем они отличаются? Ага.

219: Так, ну шардирование это по сути, мы так пытаемся равномерно распределить этот, эти данные по нескольким серверам, чтобы, ну, по сути,

220: Распределить нагрузку. То есть основной, основная идея именно в этом. Угу. А партицирование это, скорее, про, скажем так, разделе

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

222: Базу одни и те же данные делим процессирование.

223: Оно, по моему, по разным данным, происходит, то есть по разным бизнес доменам, да, что-то такое, по моему. Угу. Хорошо, хорошо.

224: Вы когда-нибудь там оптимизировали какие-то там запросов бд, а как, как оптимизировали? Как поступили, да?

225: Оптимизировали. Ну да, по сути, оптимизировал. То есть основной подход к этому. То есть пишешь explain или эксплейн элайс, анализируешь, собственно, сам этот

226: Explain. Вот по сути, мы можем посмотреть план запроса, посмотреть, что в нём делается неоптимально, типа какой тип поиска у нас используется данных, то есть мы идём по

227: Индексу, или мы идём простое секвен сканом смотрим.

228: Так, а что ещё тут можно добавить? Сколько у нас джоинов можно посмотреть. Возможно, стоит смотреть в сторону денормализации, если у нас есть какой-то запрос, который включает очень много джоинов. Вот можно также

229: Использовать кэш. Так, ну, по сути, так, если посмотреть. Хорошо. Хорошо, тогда у меня такой вопрос. Ну, допустим, вы работали, да, в банке, да, есть.

230: Таблица там аккаунт да, это счёт клиента, там счёте клиента, там остаток, например, 10 ₽.

231: По каким-то причинам там клиент нажимал там 2 раза купить какую-то там услугу, да, которая стоит 10, 10 ₽. Ну в этом случае происходит некий там

232: Кондишн на уровне базы данных, да? Угу.

233: Как вы решаете такую проблему, чтобы там баланс клиента не было там минусовым?

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

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

236: Их 3. Ну, вообще их 4 в общей теории скюл, это там рит, комитет, рит, комитет.

237: Этот репитил рит и сериалайза, общем, отличаются они по тому, какие проблемы они решают. То есть у нас есть такие основные изоляции по уровню, ну,

238: Основные изоляции. Ой, блин, изоляции, говорю, основные аномалии есть из, типа. Угу. Есть терти рит, есть. Че там ещё было? Фантом рит есть.

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

240: В принципе, и уровень этот репита рит, то есть когда у нас

241: В общем, как он работает, могу пояснить вкратце. То есть, нет, нет, у меня такой вопрос. Станислав, есть. То есть вы перечислили там те методы, которые там, pessimistic, Локин, да? Ага, ещё.

242: Есть там optimistic локинг, чем это отличается от pessimistic локинга и когда необходимо там использовать оптимистик локинг вместе, там pessimistic локинга.

243: Ну, пессимистичный подход и оптимистичный, они различаются тем, что в оптимистичный. Мы, типа, предполагаем, что у нас все хорошо, и по

244: Сейчас подумаю, как сформулировать.

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

246: Какую-то запись, а в оптимистичной просто проверяем изменения уже постфактум. То есть при комите вот при пессимистичной это

247: По сути.

248: Ну да, мы изначально используем локи, н. Угу. На какую-то строку, да. А при оптимистичной, ну, оптимистичная у нас, по сути, при всех уровнях изоляции. То есть мы просто постфактум, если у нас что-то не получилось,

249: Просто выкидываем ошибку. Вот я бы так ответил.

250: Ага, хорошо, хорошо. С какими там паттерн архитектурными паттернами вы работали там в своих опытах?

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

252: На порождающие там поведенческие, структурные, насколько я помню, да, работал. Нет, я, я Станислав сразу там, я, я не про Гоф паттернов, я про такие паттерны, как, например.

253: Да, все дошло или там even.

254: Ага, ну так, ну, поди, естественно, применяли, да. Так что там ещё, да, secure эс тоже был. То есть, в основном секьюр эс ди использовал, да, что ещё репозиторий использовали, что ещё?

255: Использовали юниту форк немного, то есть для некоторых задач

256: Угу. Что ещё? Ну вот из архитектурных, наверное таких для микросервисов autox бокс использовали, сабу использовали, что там ещё хорошо. Хорошо.

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

258: Там каких-то там предметной области как это определять?

259: Угу. Так, ну вообще, что такое там агрегат руд? Ну, агрегат, рут, насколько я понимаю, это некоторая точка, от которой зависят все части приложения, то есть, по сути,

260: Своего рода диай является агрегейшн рутом.

261: Ну то есть агрегат ру это штука, которая управляет всеми связанными сущностями внутри этого агрегата. Вот так.

262: Вот, можете привести примеры из своего опыта, да, Станислав, можете? Угу. Так, сейчас подумаю пару минут.

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

264: Инжекшен своего рода этот рут. Ну, возможно вы имеете ввиду то есть как под реген рутом, слой домей, типа там все сущности, над которыми мы работаем, то есть

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

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

267: Там заказ, это у нас будет какого-то рода агрегейшн рут. Вот.

268: Хорошо, Станислав, ещё кроме там агрегейшн рута, ещё какие там ключевые моменты есть в ddd?

269: Так, кроме агрегейшн рута.

270: Сейчас домен дидиди это домен дрим дизайн. То есть у нас есть, у нас есть что там ещё из основных слоёв аппликейшн.

271: Application. Слой, это слой логики работы с самими данными. То есть у нас есть самый высокий слой, это сами данные. Следующий, это вы, Станислав, похоже, вы говорите про clean архитектуру, да?

272: А, ну, вроде того daddy там немножко другой же, да, такие там трактор есть, там бан контекст.

273: Taemin сервис.

274: Так, ну.

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

276: Тогда переходим к следующим вопросам там про QR да, у вас был опыт, да, работы с секретом можете рассказать про преимущества да, использования данного?

277: Паттерна. И когда использовать этот паттерн?

278: Ну секьюр эс по моему это command квери спосиби ити сегрега по сути это некоторое разделение запросов на на запросы, на чтение и на запросы на.

279: Запись и модификацию. Вот по сути.

280: Из преимуществ, наверное, можно выделить высокую гибкость. Возможно, кстати, есть, был даже кейс, что есть некоторые сервисы, даже микросервисы, которые работают по secure, к примеру, очень удобно, разделяя

281: Ну, во первых, повышается читаемость кода, повышается масштабируемость.

282: Вот, что ещё, возможно, упрощается некоторая архитектура и бизнес логика. Угу. Можете привести пример, да, из своего опыта.

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

284: Занимался до этого и чтением, и записью из него мы вынесли, скажем так, 2 микросервиса. 1 на чтение, чисто, другой чисто на запись. И, по моему, там был кейс с тем, что

285: Из за этого сильно возросла производительность эти, ну, этим занимался мой 1 из членов команды. В общем, по сути, там была какая-то проблема с базой в том плане, что было много Локов из за чтения.

286: И ещё там было что-то. Сейчас секунду припомню.

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

288: Из за того, что неравномерно шла нагрузка. Вот.

289: Гораздо хорошо. Выгоднее было масштабировать тот сервис, который Шёл на чтение, потому что там было гораздо больше заказ, ну, запросов на чтение. Вот. Угу. Хорошо. Можете рассказать про

290: Sewing у вас был опыт или нет?

291: Так, сорсинг, ну, немного было, скажем так. Угу. В answers нг, это такой подход, когда мы, ну, то есть, по сути, у нас

292: Мы как можем хранить, мы можем хранить просто состояние объекта, а можем хранить некоторую последовательность его изменений. Вот. И, по сути, вот этот паттерн, он как раз нужен для того, чтобы хранить

293: Последовательность изменений. Вот. Угу. Это можно по разному реализовывать, можно через кафку, к примеру, реализовывать в некотором виде. Угу. Вот.

294: Ну, так, если в общих чертах, ну, допустим, вы сказали, что объекты храним там в виде лога, да, каждое состояние, конечное состояние, как мы получаем, как мы.

295: Собираем, да, все данные, чтобы показать, например, конечное состояние какого-то там объекта.

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

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

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

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

300: Хорошо, тогда скину сейчас последнюю задачу. Угу. По рефакторингу.

301: Скинул тут можете там просто рассказать, да? Ну, например, к вам пришёл такой код, да? Угу. То можете говорить об этом.

302: Так, ладно, сейчас сначала изучим немножко.

303: Угу. То есть есть класс order. Так, ну, 1, что по неймингу вроде все окей. Пока что я смотрю. То есть, id.

304: Угу. Так, а order id?

305: Окей. Так. Угу.

306: Ту ту ту ту.

307: Ну, наверное, 1, что приходит на ум такое глобально, если смотреть на код, это немножко, тут нарушен принцип единственной ответственности. То есть у нас 1

308: Этот ордер процессор отвечает буквально за все, то есть что тут что тут есть, то есть он и в базу что-то сохраняет, и по sstp что-то шлёт.

309: Короче, лучше все это, конечно же, разнести по разных, по разным микросервисам. Вот что тут ещё мне сразу бросилось в глаза, что тут используется http client.

310: Не через http client фактори, что, о, плохая практика. То есть там, http client фактори, по моему, использует ppoe под капотом, да, а если мы используем http client, то там, по моему, что

311: Это будет происходить не очень оптимально. Вот так. Ладно. Так, пройдусь последовательно. Паблик. Вот. Ну что тут?

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

313: Результатом. Вот так.

314: Так, ну, предположим.

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

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

317: Ну, давай следующий вопрос. Станислав, если мы оставим, да, синхронные там методы, что произойдёт в этом случае? Ну, тут есть очень много этих ао баунд операций.

318: Например, safe, ченджес там, вот, не знаю, постинг, а вот тут вызван Вейт, по сути, будет очень много блокирующих вызовов, то есть, по сути, зачем нам нужен

319: На синхронность как раз для оптимизации ну да, ае операций ае баунд операций есть cpu bound операции, есть io bound операции, cpu bound операции, нагрузка на процессор, то есть какие-то вычислительные, к примеру, посчитать там большой факториал, да.

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

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

322: Так что ещё тут можно докинуть такого?

323: Ну, вообще, что тут общий эксепшен используется, наверное, не очень хорошая практика. Стоит, наверное, выделять этот

324: Какой-то кастомный тип делать. Вот. Ну тогда следующий вопрос. Станислав, вообще эксепшены. Использовать валидациях? Да, это хорошая

325: Или там плохая практика по вашему взгляду. Ну, я вообще разные видел в валидациях, наверное, не очень хорошая практика. Ну и

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

327: Клиенту уже результат без каких-то ошибок. Вот.

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

329: Так вот, по следующей строке. Так, using using у нас разворачивается в этот

330: Во что он разворачивается, если он разворачивается в try finally, да, в finally у нас вызывается dispose. Угу. Что ещё тут, я забыл.

331: Там логирование сразу мы там записываем файл, это правильно? Или там, ну а вот использоать вроде того, что это опять же, по моему, это bound операция, то есть она

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

333: Логгирование, если он есть на проекте, то есть там какой-то i логгинг провайдер, да, и уже логи писать системно, а не в какой-то файл, ну то есть использовать какие-то более хорошие подходы. Вот.

334: Так что тут ещё?

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

336: Так, ну не знаю, наверное, тут я больше такого ничего не вижу. Ну, вроде так сказал основное.

337: Ну хорошо.

338: Тогда у меня вопросов больше нет. Ребята, у вас есть какие-то там вопросы?

339: Вопросов у меня нету, все было довольно чётко и ясно.

340: Угу.

341: Может быть, у вас к нам есть вопросы? Ну вот сам вопрос, собственно, по проекту. Чем вы вообще сейчас занимаетесь? Какие задачи и как вообще построен процесс разработки?

342: Что такое просветите?

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

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

345: Есть проекты. Ну, для них мы сейчас собираем бекон разработчиков.

346: Угу. Так, понятно. В общем, а как вообще процесс разработки строится по скраму там или какие-то другие, да, процесс, раз, наверное, по скраму все там спринты есть там.

347: Все, соблюдаем, все мероприятия, там, скрама. Угу. Там, делики каждый день. Так, понятно, все такое. Угу. Угу. Интересно. То есть, а какие, какой у вас стек сейчас? То есть, вы исполь,

348: Rabbit или кафку, какой у нас, у нас в данный момент там используется ребит в проекте, там бизнеса. Сейчас там ребята там поднимают кафку.

349: Для, для электронного кошелька там физлица, да, сейчас поднимается кафка у нас к основной там нетовский.

350: Ну, все такое. Угу. Понятно. Так, ну, в общем, в общих чертах я понял. То есть, интересный проект, что, ну, больше вопросов нет, наверное. Так что.

351: Основное спроси.

352: Хорошо, спасибо большое, Станислав. У нас просто до конца недели есть ещё пару собеседований кандидатов, с которыми мы должны провести собеседование. Я вернусь тогда к вам с обратной связью к концу.

353: Этой неделе. Поэтому вам большое спасибо за то, что уделили своё время. Было приятно с вами познакомиться, услышать о вашем опыте. Угу. Спасибо вам тоже тоже.

354: Был рад с вами познакомиться. Интересное интервью, в принципе, интересные вопросы. Угу. Хорошо. Спасибо большое. Все. Тогда. Спасибо вам. Всего вам доброго. До свидания. Угу. Всего вам доброго.