На мой взгляд систем дизайн это всегда разговор, как с коллегой, не всегда крайние случаи и острые углы архитектуры может продумать один человек, поэтому для интервьюера не зазорно делать на таких вещах акцент, потому что вы на время интервью - одна команда, которая строит архитектуру продукта. И это нормально не покрыть все аспекты в интервью, ведь оно проверяет технологический кругозор и опыт интервьюемого. Хороший собес вышел, свою компетентность парень показал. Гуд!
Это не system design interview, это ученик 5-го класса отвечает у доски невыученный урок, а учитель пытается вытянуть его на тройку. Человек не в состоянии внимательно выслушать задание, не в состоянии перемножить несколько чисел. Endpoint'ы не расписаны, data model не сформулирована. High level design - это просто набор прямоугольников, рандомно соединенных стрелками. Про секцию deep dive и обсуждение tradeoff'ов нет смысла и говорить, не с этим уровнем кандитата. Если кандидат так же бессвязно мямлил бы на реальном собесе, разговор с ним был бы закончен уже на 10-й минуте, ибо дальнейшее не имеет смысла. Балун понаставил ему завышенных оценок, но я уверен что к себе в команду он бы такого кандидата не взял.
буквально кейс из одной из первых глав книги с кабанчиком (про твиттер), как раз сейчас читаю ее и очень приятно было послушать обсуждение этой задачи! спасибо!
it is clear that guy is junior, based on questions he asked at the beginning of the video. Who worked with architecture knows that both delete , first page , like, comment wil take few days to do. Because to do even first page on twitter - insta will take huge amount of thinking.
Спасибо за интервью. Было очень познавательно. Сильно видно, что кандидат имеет мало опыта проектирования - как дошло до схемы модулей и описания данных сразу запутался, при каждом уточнении начал придумывать костыли и как давай стрелки туда сюда рисовать в плоть до циклов. Начал про базы говорить про которые только слышал. Тоже полезно было, как не надо говорить ))
Клиент стучится в gateway, который выполняет функции аутенификации, авторизации, балансировщик встроенный или внешний (консул какой-нибудь, как вариант)
Хочется уже увидеть хотя бы одно успешное прохождение архитектурки. Пока мнение такое, что это невозможно. Всегда можно сказать, что чего-то не хватило, т.к. тема бесконечна в отличии от времени интервью. Редко сразу в голову приходят идеальные решения. Секция выглядит весьма странно. Кажется, что еë используют для снижения самооценки кандидата и сбивания зп в оффере.
Зачем использовать redis что от этого выигрываем на feed service когда можно использовать elastic search и просто загружать по batch -ми по 30 постов например Главное чтобы первые несколько постов были мгновенно загружены а остальные можно уже из еластика грузить что-то вроде этого)
Проблема проектирования от АПИ - кривые границы ограниченных контекстов, и как следствие на выходе распределенный монолит. Процесс проектирования должен строиться иначе. Бизнес требования(есть) -> Пользовательские требования (упущено) -> Стратегическое проектирование (упущено) -> Тактическое проектирование (очень сильно корявое) -> Оптимизации (кэш, репликации, CQRS, балансеры - сделано почему-то вперед всего)
"Стратегическое проектирование (упущено) -> Тактическое проектирование (очень сильно корявое)" Александр, а что почитать чтоб покрыть эту олбасть знаний?
Не совсем понятно, зачем на интервью тратить время на расчет нагрузки. Это не вскрывает никаких навыков кандидата кроме как умение пользоваться калькулятором или считать в уме, что к предмету не имеет никакого отношения. Архитектура это про умение спроектировать масштабируемый функционал который будет устойчив к отказам и высоким нагрузкам. Нагрузку должен дать интервьюер как бизнес , а инженер уже работает с тем что имеет.
Где можно посмотреть как именно нужно высчитывать кол-во хостов/инстансов/ядер? Может есть гайды? Я вот так рассчитывал, ВООБЩЕ НЕ ПОНИМАЮ правильно или нет, подскажите кто разбирается. "запись 1 секунду занимает (RPS 115), чтение 2 секунды занимает (RPS 2893) = 5901 кол-во одновременных запросов (столько ядер и нужно). Пусть каждый хост имеет 16 ядер (4 инстанса по 4 ядра соответсвенно) и каждый запрос занимает 1 секунду CPU времени. Получается 369 хостов приложений, 1476 инстансов" Может нужно наоборот 2893 делит на 2?
Заранее это высчитывать не нужно. Нужно просто строить масштабируемую и эластичную систему. Как правило количество пользователей растет постепенно, вместе с этим растет и система. Ну и предусматривать некоторый запас пропускной способности на пиковые нагрузки.
this guy asked about geo-diversity on the interview with span 1 hour))))))))))))))))))) he just say some words he learnt in the boook) he is 10000000% jun
Зачем все это делать в реальном времени? Дается задание, дается время на реализацию, потом можно обсудить результат и в процессе обсуждения скорректировать элементы.
Тот случай, когда собеседуемый подготовлен теоретически, но не имеет практики. Сколько труда будет стоить грамотно организовать взаимодействие этих Image и Post services. Очевидно, что на первом этапе разработки их нужно объединить.
Любопытно, как Кирилл стал тимлидом в Яндексе. По их меркам этого не достаточно, чтобы пройти архитектурную секцию, а на позиции дальше мидла они обязательны.
Можете обьяснить джуну, пожалуйста, в чем минус хранить в кэше не готовую ленту для пользователя из 20 постов, а хранить 20 последних постов пользователей и на основе того, что нам известны подписки пользователя, формировать его ленту?
если сравнить структуру двух кэшей, в каждой из структур мы делаем выбор в пользу того или иного преимущества с наименее болезненным негативным эффектом - id1 : { post1, post2, post3..} - id2 : { post1, post2, post3..} - id3 : { post1, post2, post3..} - id4 : { post1, post2, post3..} vs - id1: { post78, post3001, post134} - id2: { post901, post3001, post124} - id3: { post1101, post32, post10229} __________________ условное сравнение преимущества первого перед вторым будет следующим: - легко получает записи, если перейдёшь на страницу (условный ВК/twitter/Instagram -> ты увидел страницу, зашёл на неё и тебе из кэша подгрузили n первых постов определённого пользователя) - легко собирать ленту, если у тебя частые операции на подписку/отписку, при которой формирование ленты идёт путём merge операций по timestamp в постах (к примеру у тебя есть n друзей на основе которых в твоём кэше собрана лента, отписываясь от нескольких друзей тебе сложнее вычленить посты этих друзей в уже пред-подготовленной ленте редиса) - рассматривая поддержку редактирования поста (пользователь опубликовал запись, затем отредактировал текст к ней), и после редактирования мы снова должны пробежать по n подписчикам и обновить пост для каждого из них, чтобы в момент получения /feed мы увидели уже обновлённый пост, в то время как отношение id - { posts} просто на этапе запроса ленты по id друга вытянет актуальное состояние поста (не нужно каждое редактирование поста отправлять в n друзей, обновляя их пред-подготовленную ленту)
@@timmyyyyyyyyyyyydimkakoopa5732 Ты не дожен обновлять пост для каждого из них, пост обновяется в кеше. Клиент идет в кеш снова и забирает уже обновленный пост если надо, что сомнительно - так как нужна функция которая не загружает уже просмотренные посты. Иначе у тебя будет инстаграм показывать одни и те же посты все время. К тому же в реквайментах говорится что функции изменения поста не предусмотрено
@@ilyasavenok9051 Да больше исторически сложилось:) Насколько я помню несколько лет назад посгрес чуть более активно развивался (моя личная оценка. Может я ошибаюсь) - например там появился JSONB - он был сразу не плох. В данном случае как мне кажется агрумент "что у меня есть опыт с этой БД" - хороший. Но я бы еще добавил что найти разработчиков у которых есть опыт работы с посгрес - проще - по мне так это тоже хороший аргумент. Ну и да - посгрес не стоит на месте - регулярно появляются новые фичи. Mysql немного в тени о нем меньше говорят на конференциях но вроде тоже развивается.
Архитектура - сразу космолет. Можно было сделать все гораздо проще, и не начинать архитектуру с CQRS, это то к чему приходят от безысходности, когда остальное уже не работает (репликации, кэш)
Это что-то вроде игры , как если бы рядовых строителей проектировщиков просили спроектировать то же здание за час. Никто бы не пошел после этого реальное здание по результатам строить. Это для проверки кругозора.
да, вот это "инженеры" - не могут байтики между размерностями сконвертировать, зато архитектуры инстараграмов обсуждают, слова умные заучили, ДАУ, МАУ, трафик, капасити... не удивлюсь, если у этих "архитекторов" за плечами лишь колледжи и гребля на галере N лет, после которых они посчитали себя архитекторами, назвались синьорами, тимлидами и думают, что действительно что-то умеют
аргумент в пользу таких инженеров прост: - расчет произвести можно в конвертере и калькуляторе, не столь важно, но отличие лишь в том, что если человек умеет рассчитывать безошибочно на листочке, это продвинет лишь на одну ступеньку вверх к систем дизайну на обсуждение непосредственно системы - знание constant hashing, sharding, LB, quadtree cassandra vs mongo (master/replica strategy) и прочее, сильно может повлиять на экономику проекта не судите по себе, если вы посчитали правильно, но другие нет. Видео носит информативный характер, очень хорошо, если вы что-то из него подчерпнёте полезное. Комментарий неадекватный по своей агрессивной интонации и наверняка, ваш болезненный и тернистый путь к вершине карьеры сказывается на вас травмой, но не все должны страдать как вы. ___________ повторюсь, на видео люди УЧАТЬСЯ, демонстрируют свои навыки и определяют свои знание на общей системе координат. Они не обязаны вам или кому-то еще. Любой желающий может поучаствовать в таком мероприятии, запишитесь и вы. Очень стыдно читать не поддержку коллеги, а попытки пристыдить. Укажите на ошибки, поправьте, скиньте ресурсы, есть другой подход в обучении
@@timmyyyyyyyyyyyydimkakoopa5732 судя по количеству слов в вашем комментарии, моё сообщение вас сильно задело :) ваши "аргументы", как и, вероятно, ваши сертификаты, бессмысленно комментировать. Метать перед свиньями бисер себе дороже.
биты в байты почему то умеют конвертировать ученики 5го класса, а вот сделать приложение - почему то не все ученики 5го класса :) не находишь ничего странного? да ты видимо и есть тот самый злой стажер который не может 5 лет уже найти работу хотя выучил всю "БАЗУ" но не устроился даже на 20 тыщ .... рублей в месяц
@@ИзяРобинович буду очень признателен, если увижу от вас ВАШУ ссылку на линкедин профиль. Задеть комментарием, вы конечно значительно преувеличиваете.. нет абсолютно никакого повода кому-то что-то доказать, чего о вас не скажешь
На мой взгляд систем дизайн это всегда разговор, как с коллегой, не всегда крайние случаи и острые углы архитектуры может продумать один человек, поэтому для интервьюера не зазорно делать на таких вещах акцент, потому что вы на время интервью - одна команда, которая строит архитектуру продукта. И это нормально не покрыть все аспекты в интервью, ведь оно проверяет технологический кругозор и опыт интервьюемого. Хороший собес вышел, свою компетентность парень показал. Гуд!
Это не system design interview, это ученик 5-го класса отвечает у доски невыученный урок, а учитель пытается вытянуть его на тройку. Человек не в состоянии внимательно выслушать задание, не в состоянии перемножить несколько чисел. Endpoint'ы не расписаны, data model не сформулирована. High level design - это просто набор прямоугольников, рандомно соединенных стрелками. Про секцию deep dive и обсуждение tradeoff'ов нет смысла и говорить, не с этим уровнем кандитата. Если кандидат так же бессвязно мямлил бы на реальном собесе, разговор с ним был бы закончен уже на 10-й минуте, ибо дальнейшее не имеет смысла. Балун понаставил ему завышенных оценок, но я уверен что к себе в команду он бы такого кандидата не взял.
Спасибо, посмотрел как не нужно проходить собес на system design) ну и от ведущего хотелось бы больше вопросов к собеседуемому по ходу его хода мыслей
Спасибо за ролик) посмотрел пару раз, и с первого раза прошёл интервью без подготовки) оффер в кармане)
мечта)
как хорошо что с точки зрения "Чистой архитектуры" можно и отложить вопросы по выбору DB )
- Геораспределенность нужна?
- Делаем клона для СНГ
- Ага, без гео
Это что за логика такая 😂
😂😂
буквально кейс из одной из первых глав книги с кабанчиком (про твиттер), как раз сейчас читаю ее и очень приятно было послушать обсуждение этой задачи! спасибо!
it is clear that guy is junior, based on questions he asked at the beginning of the video. Who worked with architecture knows that both delete , first page , like, comment wil take few days to do. Because to do even first page on twitter - insta will take huge amount of thinking.
Спасибо за интервью. Было очень познавательно. Сильно видно, что кандидат имеет мало опыта проектирования - как дошло до схемы модулей и описания данных сразу запутался, при каждом уточнении начал придумывать костыли и как давай стрелки туда сюда рисовать в плоть до циклов. Начал про базы говорить про которые только слышал. Тоже полезно было, как не надо говорить ))
Все круто. Спасибо. Пожелание: зумить схему чтобы было видно о чем речь идет. Excalidraw позволяет зумить.
12:17 Расчеты немного неверные, вы 200 байт прибавили к 500 КИЛОбайт
еще расчет хранилища сделан из того, что картинки и комменты будут лежать в одном месте, чего на практике не будет
и получилось 700 кБ)
Все гараздо хуже, они умножили размер картинки на размер текста((((
складываем 200 байт на описание с 500 кб на картинку и получаем 700кб. Браво!
ну это же mock-картинка)
@@timur2887 они там умножили(
Клиент стучится в gateway, который выполняет функции аутенификации, авторизации, балансировщик встроенный или внешний (консул какой-нибудь, как вариант)
Как всегда супер!
Хочется уже увидеть хотя бы одно успешное прохождение архитектурки. Пока мнение такое, что это невозможно. Всегда можно сказать, что чего-то не хватило, т.к. тема бесконечна в отличии от времени интервью. Редко сразу в голову приходят идеальные решения. Секция выглядит весьма странно. Кажется, что еë используют для снижения самооценки кандидата и сбивания зп в оффере.
Коллеги, спасибо за комментарии.
Зачем использовать redis что от этого выигрываем на feed service когда можно использовать elastic search и просто загружать по batch -ми по 30 постов например Главное чтобы первые несколько постов были мгновенно загружены а остальные можно уже из еластика грузить что-то вроде этого)
Проблема проектирования от АПИ - кривые границы ограниченных контекстов, и как следствие на выходе распределенный монолит.
Процесс проектирования должен строиться иначе. Бизнес требования(есть) -> Пользовательские требования (упущено) -> Стратегическое проектирование (упущено) -> Тактическое проектирование (очень сильно корявое) -> Оптимизации (кэш, репликации, CQRS, балансеры - сделано почему-то вперед всего)
"Стратегическое проектирование (упущено) -> Тактическое проектирование (очень сильно корявое)"
Александр, а что почитать чтоб покрыть эту олбасть знаний?
А где здесь было про бизнес в начале? Бизнес это деньги. Пользовательские истории как раз покрыты.
P.S. Хотя Ок, было про аудиторию.
Не совсем понятно, зачем на интервью тратить время на расчет нагрузки. Это не вскрывает никаких навыков кандидата кроме как умение пользоваться калькулятором или считать в уме, что к предмету не имеет никакого отношения. Архитектура это про умение спроектировать масштабируемый функционал который будет устойчив к отказам и высоким нагрузкам. Нагрузку должен дать интервьюер как бизнес , а инженер уже работает с тем что имеет.
capacity не 2,5 tb а. 2406.01TB
Короче, я не понял, это видео про то как "надо делать" или как "не надо делать"?
Это просто видео
Где можно посмотреть как именно нужно высчитывать кол-во хостов/инстансов/ядер? Может есть гайды?
Я вот так рассчитывал, ВООБЩЕ НЕ ПОНИМАЮ правильно или нет, подскажите кто разбирается.
"запись 1 секунду занимает (RPS 115), чтение 2 секунды занимает (RPS 2893) = 5901 кол-во одновременных запросов (столько ядер и нужно). Пусть каждый хост имеет 16 ядер (4 инстанса по 4 ядра соответсвенно) и каждый запрос занимает 1 секунду CPU времени.
Получается 369 хостов приложений, 1476 инстансов"
Может нужно наоборот 2893 делит на 2?
По-хорошему, надо сделать бенчмарк сначала и узнать метрики прежде, чем считать большие цифры. Слишком большая погрешность
Заранее это высчитывать не нужно. Нужно просто строить масштабируемую и эластичную систему. Как правило количество пользователей растет постепенно, вместе с этим растет и система. Ну и предусматривать некоторый запас пропускной способности на пиковые нагрузки.
Жаль, не успели железо подсчитать
this guy asked about geo-diversity on the interview with span 1 hour))))))))))))))))))) he just say some words he learnt in the boook) he is 10000000% jun
что за сайт используется для рисования ?
excalidraw
Excalidraw
что это за программа в которой он рисует?
excalidraw
Зачем все это делать в реальном времени? Дается задание, дается время на реализацию, потом можно обсудить результат и в процессе обсуждения скорректировать элементы.
Потому что оценивается не результат, а путь к результату.
нет описания конкретных требований в итоге ты реализуешь не то что ожидалось или уйдешь в глубь одних вещей абсолютно не раскрыв другие
это интервью в диалоге и обсуждении
Тот случай, когда собеседуемый подготовлен теоретически, но не имеет практики. Сколько труда будет стоить грамотно организовать взаимодействие этих Image и Post services. Очевидно, что на первом этапе разработки их нужно объединить.
Костыль с подписчиками в качестве совета это странно
Любопытно, как Кирилл стал тимлидом в Яндексе. По их меркам этого не достаточно, чтобы пройти архитектурную секцию, а на позиции дальше мидла они обязательны.
Я так понял что тимлид не Кирилл, а Владимир =)
RPS рассчитан не верно) на порядок ошиблись) 5000000 / 5 / 86400 = 11,57
там было 50млн не 5😅
Можете обьяснить джуну, пожалуйста, в чем минус хранить в кэше не готовую ленту для пользователя из 20 постов, а хранить 20 последних постов пользователей и на основе того, что нам известны подписки пользователя, формировать его ленту?
если сравнить структуру двух кэшей, в каждой из структур мы делаем выбор в пользу того или иного преимущества с наименее болезненным негативным эффектом
- id1 : { post1, post2, post3..}
- id2 : { post1, post2, post3..}
- id3 : { post1, post2, post3..}
- id4 : { post1, post2, post3..}
vs
- id1: { post78, post3001, post134}
- id2: { post901, post3001, post124}
- id3: { post1101, post32, post10229}
__________________
условное сравнение преимущества первого перед вторым будет следующим:
- легко получает записи, если перейдёшь на страницу (условный ВК/twitter/Instagram -> ты увидел страницу, зашёл на неё и тебе из кэша подгрузили n первых постов определённого пользователя)
- легко собирать ленту, если у тебя частые операции на подписку/отписку, при которой формирование ленты идёт путём merge операций по timestamp в постах (к примеру у тебя есть n друзей на основе которых в твоём кэше собрана лента, отписываясь от нескольких друзей тебе сложнее вычленить посты этих друзей в уже пред-подготовленной ленте редиса)
- рассматривая поддержку редактирования поста (пользователь опубликовал запись, затем отредактировал текст к ней), и после редактирования мы снова должны пробежать по n подписчикам и обновить пост для каждого из них, чтобы в момент получения /feed мы увидели уже обновлённый пост, в то время как отношение id - { posts} просто на этапе запроса ленты по id друга вытянет актуальное состояние поста (не нужно каждое редактирование поста отправлять в n друзей, обновляя их пред-подготовленную ленту)
@@timmyyyyyyyyyyyydimkakoopa5732 Ты не дожен обновлять пост для каждого из них, пост обновяется в кеше. Клиент идет в кеш снова и забирает уже обновленный пост если надо, что сомнительно - так как нужна функция которая не загружает уже просмотренные посты. Иначе у тебя будет инстаграм показывать одни и те же посты все время. К тому же в реквайментах говорится что функции изменения поста не предусмотрено
Это нихера не мок интервью. Скажем так - это вообще не интервью. Это больше учитель и ученик. Балун тянет за уши этого студента.
Довольно скудный выпуск. Интервьюер слишком часто соглашался со словами кандидата, не задавал каверзные и сложные вопросы, слабо.
например, какие вопросы вы бы задали? оценка интервьюера как раз не особо интересна...
Почему всё-таки был выбран PostgreSQL для Post Service DB, а не MySQL, например? Только потому, что у собеседуемого он встречался в 80% случаев?
Потому что в яндексе нет пыхарей
@@sergeyz4591 разве MySQL используют только пыхари?
PostgreSQL мейнстрим в качестве RDBMS в энтерпрайзе.
@@dagerashenko а чем это обусловлено?
@@ilyasavenok9051 Да больше исторически сложилось:) Насколько я помню несколько лет назад посгрес чуть более активно развивался (моя личная оценка. Может я ошибаюсь) - например там появился JSONB - он был сразу не плох. В данном случае как мне кажется агрумент "что у меня есть опыт с этой БД" - хороший. Но я бы еще добавил что найти разработчиков у которых есть опыт работы с посгрес - проще - по мне так это тоже хороший аргумент. Ну и да - посгрес не стоит на месте - регулярно появляются новые фичи. Mysql немного в тени о нем меньше говорят на конференциях но вроде тоже развивается.
Разве систему разрабатывает один человек? Смысл вообще проводить такие эфемерные собесы далекие от рабочих процессов...
Архитектура - сразу космолет. Можно было сделать все гораздо проще, и не начинать архитектуру с CQRS, это то к чему приходят от безысходности, когда остальное уже не работает (репликации, кэш)
Да, согласен. На схемке `CQRS` выглядит красиво, а на деле -- заноза в заднице.
господи, дети не закончив школу в архитектора идут😂 крч что было бы если бы программисты строили дома
Это что-то вроде игры , как если бы рядовых строителей проектировщиков просили спроектировать то же здание за час. Никто бы не пошел после этого реальное здание по результатам строить. Это для проверки кругозора.
эх, володька, ну ты и врунишка. не прошел же секцию человек явно, честный надо давать фидбек
Полный провал...
Мне кажется дизайн должны делать LLM для человека это слишком
В ответ на это Савватеев рекомендовал бы вам идти работать курьером))
@@AlexLexus42 Савватеев это тот, кто поддерживает избиение жены? Вот это авторитет, дааа
Даже лид советуется с людьми и ошибки корректируются, никто не увольняет. А тут сходу выдай
ужасная архитектура, впрочем такие вещи не делаются "за час"
- Какой DAU?
- Ну пусть будет 50 миллионов
Ну можно ли найти больший отрыв от реальной жизни, чем типовой сидиз собес?)
да, вот это "инженеры" - не могут байтики между размерностями сконвертировать, зато архитектуры инстараграмов обсуждают, слова умные заучили, ДАУ, МАУ, трафик, капасити... не удивлюсь, если у этих "архитекторов" за плечами лишь колледжи и гребля на галере N лет, после которых они посчитали себя архитекторами, назвались синьорами, тимлидами и думают, что действительно что-то умеют
аргумент в пользу таких инженеров прост:
- расчет произвести можно в конвертере и калькуляторе, не столь важно, но отличие лишь в том, что если человек умеет рассчитывать безошибочно на листочке, это продвинет лишь на одну ступеньку вверх к систем дизайну на обсуждение непосредственно системы
- знание constant hashing, sharding, LB, quadtree cassandra vs mongo (master/replica strategy) и прочее, сильно может повлиять на экономику проекта
не судите по себе, если вы посчитали правильно, но другие нет. Видео носит информативный характер, очень хорошо, если вы что-то из него подчерпнёте полезное. Комментарий неадекватный по своей агрессивной интонации и наверняка, ваш болезненный и тернистый путь к вершине карьеры сказывается на вас травмой, но не все должны страдать как вы.
___________
повторюсь, на видео люди УЧАТЬСЯ, демонстрируют свои навыки и определяют свои знание на общей системе координат. Они не обязаны вам или кому-то еще. Любой желающий может поучаствовать в таком мероприятии, запишитесь и вы. Очень стыдно читать не поддержку коллеги, а попытки пристыдить. Укажите на ошибки, поправьте, скиньте ресурсы, есть другой подход в обучении
p.s. [являюсь опытным backend разработчиком и сертифицированным архитектором]
@@timmyyyyyyyyyyyydimkakoopa5732 судя по количеству слов в вашем комментарии, моё сообщение вас сильно задело :) ваши "аргументы", как и, вероятно, ваши сертификаты, бессмысленно комментировать. Метать перед свиньями бисер себе дороже.
биты в байты почему то умеют конвертировать ученики 5го класса, а вот сделать приложение - почему то не все ученики 5го класса :) не находишь ничего странного? да ты видимо и есть тот самый злой стажер который не может 5 лет уже найти работу хотя выучил всю "БАЗУ" но не устроился даже на 20 тыщ .... рублей в месяц
@@ИзяРобинович буду очень признателен, если увижу от вас ВАШУ ссылку на линкедин профиль.
Задеть комментарием, вы конечно значительно преувеличиваете.. нет абсолютно никакого повода кому-то что-то доказать, чего о вас не скажешь