# Собеседование Python Junior разработчик [2026]

## Метаданные

- **Канал:** Артём Шумейко
- **YouTube:** https://www.youtube.com/watch?v=iDFKnmXIKuU
- **Дата:** 21.05.2026
- **Длительность:** 2:20:37
- **Просмотры:** 4,084
- **Источник:** https://ekstraktznaniy.ru/video/51724

## Описание

🎓 Курс по Backend разработке, на котором я готовлю востребованных разработчиков. Начинай бесплатно или записывайся на экскурсию: https://clck.ru/3TkUux

☘️ Готовься к собеседованиям бесплатно на Солвит: https://solvit.space/l/lzuuym

Забрать памятку с вопросами и ответами с собеседования: https://clck.ru/3TkxuM (включи BПH)

Мой телеграм-канал, где я пишу о своем стартапе и работе разработчиком: https://t.me/artemshumeiko

0:00 О чем видео и знакомство с собеседуемым 
06:36 Где живут куки
06:59 Как куки работают в мобильных приложениях
7:52 Как куки передаются от клиента к серверу и где они находятся 
09:08 Сущности HTTP-запроса
12:26 Refresh- и Access-токены: кого из них мы отправляем клиентам
19:26 Как хранятся пароли в базе
19:39 Зачем хэшировать пароли
19:55 Почему нельзя просто из хэша получить пароль 
20:36 Почему из JWT токена можно получить данные 
20:56 Почему выбрала микросервисы на своем проекте
21:31 Преимущества и недостатки микросервисов
24:56 Минусы API Gateway
26:58 Как

## Транскрипт

### О чем видео и знакомство с собеседуемым []

Друзья, в этом видео вы увидите необычную запись собеседования. Это запись собеседования с девушкой. Её зовут Эвелина. Она сейчас учится на разработчика и пройдёт собеседование на джуниор позицию. Посмотрим, сможет ли она ответить на все вопросы и решить все задачи. Вы наверняка заметили, что собеседование длится огромное количество часов, но очень важно, вам не нужно смотреть всё. Смотрите только те моменты. В описании есть тайм-коды, которые вам нужно подтянуть. Это вопросы, может быть, по авторизации, которые мы разбирали. Микросервисы или JRPC, или решение задач на Python, или, может быть, задание на SQL, или, может быть, кодw на Python на фаastпе. В общем, сами посмотрите. Либо, конечно, можете смотреть всё в захлёб, но я рекомендую именно пройтись по тем моментам, которые вам важно подтянуть. Также важно заметить, все вопросы, все задачи с ответами есть по ссылочке в описании. бесплатно забирайте, скачивайте PDF-шпаргалку и используйте для подготовки, чтобы смотреть на диване, в метро, в автобусе, в общем, где вам будет удобно. И, конечно, друзья, это видео вышло не просто так, а благодаря поддержке онлайн-школы Python разработки Pyth представлены курсы по обучению сильных Python-разработчиков. Ну или, как модно говорить, не сильных, а крепких или умных Python-разработчиков. Друзья, юмор в сторону, а есть курсы по бкэнд раз заработке, по ООП и планируются новые обучения по синхронности, по микросервисам. Возможно, они уже вышли, так что обязательно переходите по ссылкам в описании, начинайте эти обучения бесплатно, пробуйте, нравится ли вам, полезна ли информация, интересно ли задание, которые там выложены, и, конечно, продолжайте смотреть это собеседование. Желаю вам удачи в просмотре этого собеседования. Погнали, — друзья. Всем привет. Сегодня у нас пройдёт мок собеседование с Эвелиной. — Всем привет. Да. И мы проверим знания Эвелины в Python, в backend, в лакодинге, в базах данных, может быть, в брокерах сообщений. Посмотрим. В общем, будет интересно. Эвелина, можешь рассказать про себя? Э, какой у тебя опыт программирования, там, какой стек используешь и там работаешь, учишься, какой статус? — Угу. А, ну, пока что я не работаю в IT, но учусь на третьем курсе, курсе информационной безопасности. А, ну, учёба моя не особо связана с питонноразработкой, но я угляюсь в это сама. Ну, последние полгода я беру какие-то для себя пт-проекты, чтобы изучить что-то новое. Ну, из моих пт-проектов начинала я с самых лёгких. Это, допустим, блокнот, где было хранение каких-то записей, авторизация. А, ну и сейчас пытаюсь что-то сделать типа социальной сети для путешественников. А также брала некоторые пдпроекты с сайта Soulwe, правильно, да, несла. Угу. — Есть там некоторые интересные пдпроекты. Я брала мониторинг сайтов, то есть какие статус коды они возвращают. А не реализовала фронтENД, там нужно было фронтенд реализовать только в качестве БКА. А вот, ну, как-то так пока. — Угу. А скажи, какие базы данных пробовала и фреймворки? — В основном я пишу на фастапе, а, как использую сQL. Ну и постгре SQL. — О'кей, хорошо. А, и ты ещё писала, что у тебя есть некоторый опыт JRPC, микросервисов, брокеров. Можешь про это рассказать? Да, как раз-таки я сейчас в процессе изучения, так что, возможно, где-то будут какие-то пробелы. А я решила, что мне бы стало интересно взять проект, вот, опять же повторю, в социальной сети для путешественников. А то есть, э, там будет лента, да, рекомендаций, э, люди могут выкладывать посты с какой-то меткой локации. Вот. И, ну, у меня будет всё разделено на сервис. То есть у меня будет авторизация - это отдельный сервис, а-а лента отдельный сервис, лентарекомендации - это как email. Я ещё вле, кстати, не углублялась. Потом в будущем будет хоче лучше что-то попробовать из этого. Это отдельный сервис. То есть каждый сервис будет изолирован друг от друга. — Вот общаться, ну, они будут их пообщать будет App Gateway. А вот клиент будет отправлять запрос на App Gateway, и уже App Gateway будет запросы как бы, ну, перенаправлять, можно так сказать. наверное, да, сервисы, которым должен был идти запрос. Вот. А общаться они будут через JRPC. Ну, JRPC отличие от HTP тем, что если HTP общается в Jсоне, то GRPC он всё, ну, как бы переводит в бинарник. Из-за этого GPC быстрее, ну, как бы, ну, отправляет данные, чем в JSON формате. — Угу. — Вот. — А брокеры как-то там будут присутствовать или что? будут присутствовать. Я ещё до этого, ну, именно практически я к этому ещё не подошла. То есть я пока так авторизацию сейчас я ленту настраиваю. Вот. Ну, брокеры вообще нужны для того, чтобы прислать, ну, серверы могли прислать какие-то события друг другу. То есть, допустим, выложился пост и, допустим, ленте, ну, лента рекомендации должна знать, что это произошло, и через брокер сообщений будет направлено на такое событие. Угу. О'кей. Интересно. Хорошо. Давай вот поговорим немножко про этот проект, наверное, про авторизацию. — Вот расскажи, как это будет выстроено. Ну, авторизация у меня выстроена вообще максимально самым простым способом, то есть без какой-то многофакторной мотификации. Хотя до этого я раньше реализовывал многофакторную мотификацию через тотп. Вот сейчас я решила на этом не убляться, потому что уже было такое вот. То есть у меня юзер заходит просто при помощи, ну, — логина, пароля, а у него создаются, ну, получается, на сервере создаются куки, а Access refresh, ну, и выдаётся как бы сессия. Ну, асс токена для того, чтобы, ну, рефреш для обновления аксесса токена, то есть access to токен он мало живёт, рефреш подольше. Вот. И при помощи акстокена будут, получается, ну, доступы к ручкам, которые созданы только для авторизированных пользователей. Вот. То есть через IT — Угу. А вот ты сказала, — что куки, да, в целом всё корректно, что куки, э, создаются на сервере. Вот если

### Где живут куки [6:36]

говорить именно про куки, это сущность чего? Браузера, бэкэнда, Пайтена, где они как бы живут. Живут они вообще на у клиента, то есть они не хранятся на сервере, они хранятся у клиента. Ну, получается, ну, как сказать, в браузере, — м если так корректно будет. Вот. — Угу. А может, ты знаешь, как вот в

### Как куки работают в мобильных приложениях [6:59]

мобильных приложениях там есть куки? — В мобильных, если честно, не углублялась, но я подозреваю, что у них тоже есть какие-то сессии, мне кажется. Ну, в мобильных приложениях вот, да, - это действительно браузерная сущность, какая-то обёртка для безопасного хранения, ну, например, в традиционных аутен аутентифициро, короче, вот токенов. Это секретных данных. А потому что там можно спокойно како-нибудь бабушке отправить ссылочку, и она там подвергнется сеас рф атаки. В общем. О'кей. А, а в Давай вот поговорим про куки. про HTP протокол, наверное. А как куки посылаются от клиента серверу? — Где они находятся, где живут?

### Как куки передаются от клиента к серверу и где они находятся [7:52]

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

### Сущности HTTP-запроса [9:08]

если говорить про HTTP протокол, как бы про HTP запрос, допустим, вот в каком месте живут куки, они и они передаются? У нас вот в HTP вот если можешь описать HTTP запрос, какие у него есть сущности? — Ну это же про заголовки стож, правильно или нет? — Да. Вот да, например, там у тип запроса, заголовки, где у нас передаются и сайтятся вот эти токены. — Тактак, что-то вообще совсем из головы вылетело. Ну, в заголовках мы вроде бы не можем передавать. Так вот, если честно, вот сейчас я боюсь что-то это неправильно сказать. Мне кажется, что-то это не туда я на заголовках, мне кажется, нельзя их передавать, насколько я помню, потому что их можно тогда — как бы, ну, это не безопасно будет. — Вот. — О'кей. — А в local стож э вроде отправляется вообще там вродени не связаны. Aal storage уже немножко в сторону, то есть он к HTP протоколу — не относится. Угу. — Ну о'кей, давай тогда. — А как это будет правильно? подскажу. У нас ну как бы изначально, когда сказала, что куки создаются на сервере, я услышал здесь то, что ты, видимо, только с куками работала. — И это немножко некорректно звучит, потому что куки - это вот именно сущность браузера. И, ну, как бы корректнее было бы, наверное, сказать, что на сервере создаются вот эти токены, как ты и сказала, и как бы они могут храниться у клиента по-разному. Они могут, если в браузере, конечно, чаще всего они хранятся в куках, а, а не в Local Storage. Ну, это если опять уходить вон, потому что local storage можно прочитать через JavaScript. Если мы говорим про мобильную разработку, то когда мы строим, например, апишку, вот у меня был такой опыт, которая с которой и мобильные разработчики работают, и фронтендеры, а мы посылаем сами токены, что и как бы в ответе. Мобильный разработчик делает запрос на авторизацию, на аутентификацию. Мы отправляем access refresh token просто в jonчике, если про HTP говорить. А там нет кук, то есть там, да, как-то хранится, я опять же не эксперт. хранится этокирефреш внутри мобильного приложения, внутри клиента, ну, как бы телефона. А, но там нет кук, как в браузере. И если мы говорим про браузер, когда мы устанавливаем куку, мы действительно делаем это на стороне нашего, ну, допустим, Python приложения через заголовок set cookie cook. Это просто HTP заголовок. А если у нас фронтEN, ну или браузер отправляет запрос на эээнд наш, то кука отправляется в заголовке аки. Он так называется. То есть set cookie - это когда хочет засетить в браузере, а когда браузер просто посылает уже аess токен, который у него хранится, он делает это в заголовке куки. Ну и там заголовки не одна кукла хранится, а все, которые в принципе есть у пользователя в браузере.

### Refresh- и Access-токены: кого из них мы отправляем клиентам [12:26]

А базово так? А, о'кей. А давай вот поговорим про рефреш и access. Вот ты сказала пара токенов, что рефреш нужен для обновления Access. А может сориентировать отправляем ли мы, короче, кого из них мы отправляем клиентам, а какие из этих токенов мы храним у себя в базе. Вот можно с этого начать. А, ну, вообще обычно, обычно я отправляла сразу же Access Refresh на браузер. Игу, — лично я такую практику не использовала, но я знаю, что рефреш некоторые хранят ещё в PD, чтобы потом сделать, ну, при обновлении аксес токена, когда мы берём рефреш для обновления, чтобы мы проверили, сходится ли рефреш, который, ну, мы получили, и рефреш, который у нас лежит в бадшке. А у тебя сейчас рефреш, то есть не хранится в базе, — да? — То есть он существует, то есть он типа создался, передался в браузер и всё. Как бы его больше нет у нас. — И ну он передался в браузер. И потом, когда у меня получается он возвращается на сервер для проверки, то он проходит валидацию. — Ага. То есть рефреш - это тоже типа GVT формат GVT. По сути, да, вот я из-за того, что мм не знала, откуда вот именно взять эту информацию, у меня были сомнения, правильно ли это, что у меня получается по сути рефреш почти такой же, как Access. Кроме того, что, ну, на рефреш я накидываю HTP only, ээ, — вот эти флаги. — Вот. И получается, пока что по-другому он не отличается. Вот. Насколько это правильно? — Ну, давай попробую навести на мысль. Допустим, мы узнали, что у нас, а, как сказать, ну, какой-то хакер увёл аккаунт нашего добросовестного пользователя и завладел его рефрешем и эксесом. Как? Ну, и ты об этом узнала. И как тебе сделать так, чтобы хакер потерял доступ к аккаунту? Как ты думаешь? — Ну, по сути, просто, ну, удалить куки, то есть брать accessрефреш, просто выйти как бы с аккаунта, если так можно. — Сейчас. Секунду. У ха у хакера свой ноутбук. Он сидит где-нибудь. Поняла. Не поняла. Сейчас ещё раз. Да, давайте заново. — О'кей. А хакер каким-то образом, мы не знаем каким, раздобыл пару Exessфреш токена от у от другого пользователя, у которого, я не знаю, там какая-нибудь подписка куплена, в общем, куча всего, и он зашёл на его аккаунт. Он сейчас всё у него украдёт, там испортит. А ты разработчица, ты знаешь об этом, и тебе надо сделать так, чтобы хакер. Ты знаешь, какие какая пара? А нет, сейчас, не знаю, секунду. Не знаешь? Нет, ты не знаешь. Ты только знаешь, что увели аккаунт пользователя, что кто-то им завладел. — Как сделать так, чтобы все текущие люди, у которых есть доступ к аккаунту, ну вот тут хакер, может, может два хакера, забрать у них этот доступ в моменте, чтобы они потеряли его? Ну, по сути, — ну, то есть как обеспечить безопасность по сути? — Ну, вообще, ну, первы, ну, если у них, наверное, уже валидные аксес, да, я так поняла, они валидные акcessрефрешки. — Да, да. — А, ну, можно было бы их как бы обнулить, может быть. То есть вот — А как это сделать? — Ну, — а как выйти? Мы же не можем сказать, пожалуйста, выйдите из аккаунта. Да, я тоже думаю, что мы же так не можем сделать. — Ну вот тут бы хорошо, конечно, бы сработала проверка с тем, что у меня бы лежало в ПТ э последний рефреш токен. То есть я понимаю, что хакер, наверное, заполучил этот рефреш, и это какой-то новый рефреш, который не записался в пдэшку. Правильно, да? — Ну да. Если мы говорим про твой кейс, когда не записываются данные в ПД, — он же может использовать этот рефреш, нагерить новый рефреш и всё. И мы тогда уже не знаем, какой новый рефреш, как он, как он выглядит. — Ну только, ну я вижу тут безопасность только, да, если записывать рефреш в PD и сравнивать ээ рефреш, который нам поступает и рефреш, который у нас лежит в ПД. А если без БДшки, то как будто бы ну как-то экстренно, не знаю, экстренно закрыть сещю, ну убрать куки, но как будто это не особо корректно, потому что раз у него есть доступ к генерации, то он может заново это сделать. Да. То есть мы не можем в его браузер зайти и его разлогинить. Да. В общем, здесь идея такая, что рефреш токен мы всегда храним у себя в базе где-то, ну, обычно в базе, то же постгрес, для того чтобы можно было в нужный момент его пометить как украденный, и мошенник не сможет продлевать пару Exessфреш. То есть у него какое-то время ещё будет работать, там, там 15 минут, 30 минут. Ну, они обычно короткоживущие. Но рефреш, который у него есть, мы его добавим в блоклист, и он не сможет им пользоваться. Угу. — Ну, то есть он не сможет дальше продлить свой бесконечный доступ к аккаунту, и у него он через 15 минут, — да, — денется. Поэтому рефреши обычно хранят в базе. Друзья, давайте возьмём небольшую паузу от просмотра собеседования, и я хотел бы рассказать вам о обучении ээнд разработчиков. Если вам интересно направление бэкэнда, Python, базы данных, и вам хочется работать бэкэнд-разработчиком, но вы видите, что есть какие-то пробелы в знаниях, может, какие-то вопросы, на которые сейчас отвечает Эвелина, вы не можете ответить или вам тяжело написать полноценный проект с нуля до продакшена, то это то, что вам нужно, чтобы выйти на следующий уровень. Итак, что такое курс по бкнд разработке? Это, в первую очередь, практический курс, в котором есть более тритрицати практических и тестовых заданий для проверки теории и практики. Соответственно, у вас есть куратор, который на протяжении всего обучения помогает вам, проверяет задания, отвечает в чате, проводит консультации, мог собеседование, если вам такое нужно. Просто пишете: "Я хочу мог". Всё. На следующий день у вас точно такое же собеседование и даёт обратную связь. А после окончания обучения вы попадаете в сообщество выпускников и таких же специалистов, как вы, бкн разработчиков, с которыми можно обмениваться опытом, обсуждать рабочие задачи и просто приятно проводить время. Друзья, полная программа курса. Все модули, все технологии, которые используются, весь стек, все проекты, которые пишутся, их там не один, есть по ссылке в описании. Очень красиво и понятно всё расписано на сайте pitex. school. Обязательно переходите и ознакамливайтесь. Также вы можете начать обучение бесплатно. Вы просто заполняете имя и почту, и вам открывается доступ к первым трём урокам из курса. А также вы можете записаться на бесплатную экскурсию в нашу школу, посмотреть, как устроено обучение изнутри, как происходит общение с кураторами, со службой поддержки, заботы, узнать все вопросы организационные, технические, про заморозку доступа. У нас есть такая опция, про сертификаты, про бонусные уроки. Всё это можно узнать, задать вопросы, и вам ответит технический специалист. Друзья, записывайтесь на экскурсию или начинайте обучение по ссылке в описании, а мы продолжаем собеседование. О'кей. А, а вот ты

### Как хранятся пароли в базе [19:26]

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

### Зачем хэшировать пароли [19:39]

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

### Почему нельзя просто из хэша получить пароль [19:55]

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

### Почему из JWT токена можно получить данные [20:36]

GVT токен почему можно как бы из него получить, да? — Ну, потому что он кодируется, то есть он его можно кодировать и ты кодировать, — да? Корректно. О'кей. А, хорошо, хорошо. Про авторизацию можем пока закончить и перейти, наверное, к микросервисам. Э, вот почему ты вообще

### Почему выбрала микросервисы на своем проекте [20:56]

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

### Преимущества и недостатки микросервисов [21:31]

— М, а какие плюсы даёт, что у нас там не монолит, а там три микросервиса? — Ну, плюсы а более масштабированные. Если у нас падает один сервер, то, допустим, мы не можем, ну, мы не будем, у нас не весь проект падает, а только один сервер. То есть другие серверы у нас будут работать. Вот. А что ещё из плюсов? — Ну, получается, данные у нас передаются, возможно, чуть быстрее, потому что у нас, ну, может использовать GPC, а в монолите мы, получается, сразу передаём через HTP. Возможно, я тут чуть-чуть, я чуть-чуть, кстати, некорректно сказала, потому что, да, всё, я поняла сразу ошибку и туда чуть пошла. Ну, — в монолите у нас получается нет задержки. Задержки мы же это не туда сказала. — Угу. О'кей. Окей. Ну, масштабируюсь и сложности, ну, и сложность, вот из минусов сложность. А потому что, наверное, лучше, когда каждый сервис пишется, ну, каким-то — одним, да, разработчиками команды. То есть вот потом что ещё? У каждого сервиса своя бдшка. Мм, они не могут стучаться к другим сервисам в ПД. Ну, вот эта изолированность получается. Что ещё? — Это плюс или плюс? Это плюс. одна бдшка. — Ну, это плюс, потому что если у нас, допустим, укрытся какие-то данные из одной БД, то в другой БД у нас всё будет нормально. Мы её не трогали. — Вот. — О'кей. — Пока что-то. — А минусов? А минусов нет. То, что у нас — минусы, ну, получается слож это сложная система, — потому что это, ну, вот если так, грубо говоря, опять это несколько монолитов, это очевидно. Ну, это прямо в кавычках кавычках, поэтому сложнее их связывать, э, больше писать. — Ну, наверное, что-то такое. — У. Угу. Ну, вот про баз данных под микросервис там минус такой, что раз мы не можем, раз мы запретили командам обращаться в чужие бдшки, но если нам нужны данные оттуда, то есть нам нужна какая-то прослойка, что мы идём в микросервис, а он уже идёт в базу. То есть у нас, в принципе, короче, сетевого взаимодействие будет, сетевых задержек будет больше. Мы немножко жертвуем, э, временем в таком случае, что мы не сможем напрямую в базу пойти. — О'кей. В целом, да, корректно. Ты ещё говорила про App Gateway. Скажи, — как бы, а почему бы просто не сделать так не сделать так, чтобы клиент напрямую в микросервис обращался? Почему через API Gateway? Ну, это получается единая точка входа. Мы стучимся в App Gateway, и уже он передаёт к опреждённому сервису. А, и сервисы дальше общаются между собой. То есть, ну, какие-то кусают друг другу события, может быть, что-то такое. Ну, я мне кажется, что так просто удобнее. То есть какая-то целостность происходит. У нас в Апе Gateway получается только какие-то, ну, вот пост get запросы. Дальше у нас есть клиент, где у нас прописаны, ну, получается, ну, как сказать, методы, наверное, да, обращение к сервису. И дальше он уже посылает, идёт, ну, дальше он стучится уже к нужному сервису, который, ну, запрашивает клиент. Мм, как-то так, наверное. Может

### Минусы API Gateway [24:56]

договорила. — Угу. А есть ли минусы вот у AP gгateway в таком случае? — Хх, сейчас подумаю. Ну, я думаю, это как бы его и минус-плюс, наверное, то, что это единая точка кода. — Угу. — Вот. То есть, если, допустим, сейчас надо подумать, как что может такое произойти, что можно не доступ до пики, ну, как-то не могу придумать именно конкретный какой-то случай, но я думаю, это как бы и плюс, и минус, то, что это один код и выход для наших сервисов. — Угу. Может, ещё чем-то мы жертвуем в таком случае. — Так, чем мы ещё жертвуем? Затрудняюсь, наверное, ответить пока что. — Угу. Ну как я это вижу, опять же у нас дополнительные сетевые задержки. У нас есть какая-то прослойка, через которую проходит запрос. Ну, хотя её могло бы не быть, да. Второе, что нам нужно каждый раз, когда мы какой-то микросервис добавляем, опять же не забывать править это в App Gateway, чтобы это работало. Ну, это такой минус, конечно, на пару минут, скорее всего, делов. Просто был опыт у меня работы, когда у нас нет апигeя или, точнее, даже часть микросервисов не под гейтвеем были, и напрямую клиент обращался к энпоинту там опишки, которую я написал в микросервисе. Ну, конечно, минус такого, что мы светим все роуты, все наши опишки, а, и к ним могут и как-то их легче эксплуатировать. чуть сложнее может быть deb в плане там агateйвея, то есть когда у нас добавляются дополнительные посредники, а запрос, допустим, упал, нам нужно разобраться, он упал на стороне нашего микросервиса или на стороне гейтвея. И когда у нас ещё вот такие посредники могут добавляться, нам ещё больше там для расследования какого-то инцидента нужно времени потратить, чтобы понять, где проблема. О'кей. Ну, в остальном ты всё корректно сказала. Хорошо. А если вот говорить про

### Какие слои слои проходят данные при отправке запроса из браузера [26:58]

сам запрос, вот, допустим, кто-то вот открыл ноутбук, какой-то сайт, вот сервис, соцсеть для путешествий, отправил запрос на твой эээнд, вот через какие слои он, через какие технологии, может так выразиться, слои он проходит перед тем, как дойти до там Gateway того же? Ну, получается, допустим, мы что-то отправляем, нажимаем какую-то кнопку. Ну, по сути, у нас есть, наверное, ну, как сказать, домен который является как адресом, куда нам идти дальше на сервер. — Вот. Ах, ну и по нему мы идём к нашему попоинту, по сути. То есть он так и прописан в коде с ссылкой. Вот сейчас чувствую не туда я ушла. Угу. Сейчас ещё разочек надо подумать. — Ну как бы я могу сузить тоже. Мы в браузере уже нажали какую-то кнопку. JavaScript сформировал и URL, и какие-то данные для запроса, заголовки, — да. и начал попытку отправить. Короче, началась отправка. Вот какие здесь слои мы проходим, системы, может, какие мы проходим. Ну, если честно, я прямо я вспоминаю ваше видео, которое смотрела, и мы тоже там проходили собеседование, там был такой вопрос, — да. — А сейчас сама как-то это воспроизвести тяжеловато. Сейчас что-нибудь придумаю. — Угу. Ну, по сути, у нас же сначала идёт то, что хотя что-то как-то не идёт. Не идёт, если честно. Ну — о'кей. — Боюсь сказать некорректно прямо, если как-то. Ну ладно. Максимум, что я могу сказать, это получается, ну вот у нас есть домен, где у нас есть какой-то URL, и по этому юлу мы уже стучимся на сервис, и там уже endpint наш и выполняется, ну какой-то вот запрос, да. Но я очень много пропустила шагов между. Я в этом уверена. Я как-то их прямо вылетели из головы буквально. — Угу. А, ну да. Ну давай скажу, как бы я бы ожидал такого ответа. Я бы точно хотел услышать про веб-сервер какой-нибудь, типа Enginex, то у нас всегда перед нашим голым сервисом стоит какой-то типа защитник прокси там балансировщик, там много функций, может быть, того же веб-сервера, но это вот, наверное, базовая, ну, перед ним можно там сказать было бы, что там DNS resolver, что вот у нас есть домен, по нему распознаётся IP-адрес, потом вот в этот IP-адрес стучимся. Ну, базовое что-то вот такое. О'кей. В принципе, не критично, но пронек знать важно, опять же, да, вот когда особенно ты разрабатываешь сложные системы, у нас ошибка может быть тоже на стороне нжинса. Почему бы и нет? Такое бывает. Э, опять же пример приведу для понимания. Э, из практики была микросервисная архитектура, и мне нужно было реализовать сервис для загрузки паспортов. очень секюрный сервис. Он жил вообще внутри нашей куберсети Бернетиса. Вообще нельзя достучаться было до него извне. То есть до для него был ещё один микросервис, который уже в него встучался, который был публичный. И мы раскатились, задеплоили, тестируем. Пока на тестовом стенде. Выясняется, что какая-то ошибка есть. Почему-то файл фронтензеer пытается загрузить паспорт, он не грузится. Я в своём сервисе не вижу ошибок. И вот если ты знаешь про то, что у нас есть ещё какие-то предыдущие промежуточные сервисы, например, тот же Enginex, можно догадаться, что, ну или не догадаться, да, можно вспомнить, что ага, в Engin же может ограничивать по а пропускной, по размеру файла. Он не может пропускать, например, там большие файлы больше там 5 Мб, 10 Мб. Может быть, настройка такая двопсом сделана. И действительно, так и оказалось. Вот. И вместо того, чтобы там решать проблему день, искать ошибку в своём сервисе, почему-то логи не вывелись про ошибку, можно было бы вот так быстро её решить за, не знаю, 5 минут сказать, что это не я виноват, это девовс, типа идите, идите к нему, он разрулит. Ещё раз напоминаю, друзья, если вы хотите подготовиться к собеседованию и наверняка вы забудете часть из этих вопросов или задач и захотите повторить их перед собеседованием, обязательно скачайте по ссылочке в описании шпаргалку PDF. там все вопросы с ответами собраны те, что есть в этом собеседовании, чтобы вы смогли прямо перед собеседованием открыть за день, за 10 минут и повторить все эти вопросы и ответы. Так что обязательно переходите по ссылочке. О'кей, про это понятно. Мм, я предлагаю

### Преимущества использования словаря [31:52]

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

### Какая алгоритмическая сложность доступа к элементу словаря [32:54]

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

### Виды алгоритмических сложностей [33:06]

— Ага. — Да. А какие ещё ты сложности знаешь? — А о от единицы, О от N логарифмическую. А вроде бы ещё есть — n². Вроде бы есть. Ну да, — ну такие это базовые, вроде бы. — Угу. А можешь привести пример вот на каждую сложности из сложностей, что ты назвала, какой-нибудь примерчик. Вот что с такой сложностью может выполняться? — Так, ну если у нас N - это единица, это вроде бы линейно получается. Если от N - это есть какой-то вложенный, ну цикл, я прямо могу в этом чуть-чуть поплавать, не очень разбираюсь. И в получается n² - это когда несколько вложений есть. Логарифмически не могу вообще даже если так придумать что-то. — Угу. А сейчас вот ещё раз про Он какой пример был? — Э то, что там получается, ну один цикл, один проход, — наверное, и это, наверное, даже в лучшем случае, потому что Да, что, наверное, в лучшем это будет от единицы, допустим, да? Вот в лучшем, наверное, да? или как будет корректнее сказать? Ну, я думаю, ну, если один проход, то это от по случае должен быть. — Угу. Да. А если мы условно два раза пройдёмся по одному и тому же списку и — итериемому объекту, то какая сложность? — Ну, если два, ну, там вроде бы должно быть n², то есть несколько прохождений. Но я не думаю, что если мы, допустим, третий, да, если я так вот думаю, если мы третий цикл какой-то сделаем, то есть это у нас сложность будет цикл, цикл и цикл, то это будет n в третьей степени. Я думаю, это так не работает. Поэтому какие-то сомнения есть по поводу того, что n² - это циклложенный цикл. Сейчас я подумаю, может быть. Ну, пока я могу разделить то, что а получается O от N - это м какой-то один цикл, а N² - это уже когда мы имеем каких-то несколько вложений, наверное, так. О'кей. Ну, в целом ты корректно рассуждала, что чем больше вложенных циклов, тем больше степень. То есть это может быть в четвё и так далее, но это напрямую зависит от количества вложенностей. То есть просто for - это O от N for и внутри него, а это N². — Угу. — Ну и так далее. Ну, опять же, если это мы по одному и тому же списку проходим, у которого длина n, там, если у у одного длина, если мы, знаешь, проходимся чаще всё-таки не по одному и тому же, ну, на практике там для алгоритмических задач может быть, но на практике у нас там может быть там два-три списка. У одного длина n, у другого m, у третьего там x. У нас тогда будет сложность n на m на x, условно, вот так. А, но в целом рассуждения были около корректные. Ну, в общем, о'кей. Понятно по этой теме. Мм

### Зачем в Python нужен OOP [36:13]

давай вот ещё над чем порассуждаем. А зачем нам в Пайтоне нужен ООП? Какие он плюсы даёт? — М, какие плюсы? Ну, мы можем, что, ну, допустим, у нас есть какой-то класс, где мы создаём какой-то объект. А, и, ну, за счёт класса мы можем создавать несколько объектов. Если мы хотим какой-то объект разделить, допустим, ну, его как-то расширить помимо другого, да, мы, ну, дале удобства у нас мы можем как бы произвести наследование так другого класса, и у нас будет разде ну разведена логика уже. Так, у нас есть один класс, допустим, у нас родитель, у нас будет у него какие-то основные функции. Если мы хотим какую-то логику добавить, чтобы, ну, как бы было вообще понятнее код и приятнее, мы можем сделать, получается, наследника, э, добавить наследнику какие-то другие методы. Вот. И при уже использовании, да, создании мм самого как бы объекта использовать то, что нам более подходящее. То есть это будет, э, объект, который будет наследоваться от класса родителя, и ему не нужны какие-то лишние другие методы. Или, наоборот, он более функциональный, да, мы там, допустим, наследники прописали ещё какие-то методы, и мы будем его наследовать от, получается, уже наследника. Вот, наверное, что-то такое. — О'кей. Наследование хорошая вещь. Согласен. А, о'кей. А, хорошо. Если говорить про опять же ООП

### Виды dunder-методов [37:51]

про классы, какие методы ты чаще всего используешь на практике? — Ну, чаще всего используется Init конструктор. Вот. Также какие ещё ндермето? Ну, можно, допустим, если мы хотим что-то сделать для сложения, да, просто у нас какой-то метод, который в сложении, мы можем Thunder AD использовать. Мм, вот. Нуно, чаще всего у нас, конечно, фигурирует inт в оп. — Угу. — Вот. — Угу. Мм. Хорошо. О'кей. Э

### Декораторы static метод, class метод и property и для чего они нужны [38:30]

у нас в классах в Pythonне есть декораторы static method, класс метод и property, часто используемые. Можешь рассказать, был ли опыт использования и для чего это нужно? Хх, ну, если честно, э опыта не было и так прямо не попадалось на глаза. Ну, в принципе, декоратор, получается, накидываем на какую-то, да, на нашу функцию дополнитель, ну, изменя виды изменяем нашу функцию, не затрагиваю её. То есть, ну, могу только предположить то, что это для удобства, чтобы мы прописали, допустим, какой-то метод. И у нас есть вот декоратор, там что-то он делает, мы накидываем, — и он что-то делает за нас. — А так я по практики вот не использовала и, ну, просто, если честно, просто на сухую было. Как это работает, не знаю. — Угу. О'кей. А, ладно. Ну, ладно, пожалуй, эту часть я, наверное, не буду объяснять. Мм, слишком долго займёт. О'кей. Давай вот про декоратор ты сказал. про декоратор объяснила, что это такое даже. Мм, а как нам поступить, если мы хотим свой декоратор написать? Как он выглядит? — Ну, вообще, он выглядит как функция, ээ, ну, функция функции. Ну, смотря какой именно нам нужно декоратор написать с какими, может быть, с какими-то параметрами, может, без параметров. От этого будет зависеть. Это получается функция, которая принимает функцию, можно так сказать. — Угу. А, а вот если я захочу как класс реализовать декораторы, я могу так сделать через класс? — Ну, по сути, да. Да, я думаю, да. — Сделать, — ну, объявить класс, а, и прописать, ну, получается, наверное, сейчас, наверное, ну, декоратор прописать как функцию. Это будет, получается, метод класса. Ну, хотя потом так его использовать. Ну, хотя, наверное, так же, как и обычно. Мы класс. Можно, можно как вариант, но вот если я хочу прямо вот, чтобы собачка класс над функцией было и всё, и без вызова метода какого-то. Просто собачка класс. Ну, название класса я имею в виду. — Угу. — А точнее не название класса, а экземпляр класса. Можно ли так сделать? — М, мне кажется, нет. Даже такого никогда и не встречала. Как-то их разделяют классы и декораторы. Именно если прямо писать целый декоратор. Такого не встречала. — Так, думаю, нет. — О'кей. А, ну на практике всё-таки может такое быть. Если мы реализуем магический метод call в классе. — Угу. — Он тогда будет вести себя экземпляр этого класса будет вести себя как функция. То есть его можно будет ещё вызвать через скобочки, типа как обычную функцию. Ну и декоратор у нас же это, по сути, если его не как через синтаксический сахар описывать, а как просто функция равно декоратор от функции, — Угу. — то становится понятно, что формулировка, что декоратор - это функция, она не до конца корректна, что это скорее сказать colable объект, да, какой-то вызываемый объект. — А, ну да, можно через класс. Просто опять же, когда часто с какими-то декораторами работаешь, с какими-то библиотеками, там нужно разобраться, как это работает, ты проваливаешься внутрь библиотеки и смотришь, что бац, оказывается, это класс, да, а не функция. И о'кей, что просто не было удивления на практике. О'кей. Про декораторы понял. А вот ты работала с алхимией, с пайдентиком. Интересно, может быть, ты встречалась с понятием миксин? — Если честно, нет. А, ну ладно, ладно. Это вот изоп тоже такая история. М

### Преимущества ORM [42:30]

давай попробуем перейти тогда к теме алхимии той же, немножко вернуться вот к бэкэнду. Мм, скажи, какой вообще смысл иметь ОРМ, а не писать сырые запросы? Ну их, ну они получаются вообще легче, ну обрабатываются, наверное, легче. То есть мы прописываем, как нам удобно, ну принято писать. Ну, допустим, конкрет пишем, я напишу на питоне, и это переведено, как сказать, в язык питона. Вот. И потом это уже обрабатывается SQL-код. И, ну, дальше уже происходят действия какие-то с нашей базой данных. Вот, чтобы у нас не было как-то интегрирован напрямую скейкод в нашу программу. — Угу. — Ну вот, наверное, так. — О'кей. Может, ещё какие-то плюсы есть, кроме этого? Это плюс, да? Ну, из плюсов, ну, когда мы, получается, пишем какую-то, да, допустим, нам нужно получить какую-то строчку, и мы используем ORМ, то опять же это из-за того, что интегрировано сразу же в Python, то есть это получается Python код, то мы можем делать какие-то дополнительные проверки, которые мы не можем делать в, наверное, в сQэле. Ну, допустим, мы пишем функцию, которая, э, ну, берёт какую-нибудь там первую строку. И когда мы подпишем эту функцию, мы можем дополнить то, что мы ждём на возврате такой-то объект, то, что принимаем конкретно там, я не знаю, допустим, int str, что-то может быть такое в скеле. Я что-то не по Ну будет, наверное, не особо удобно прописывать такие ээ ну сказать, валидацию такую, — да? Это будет, я согласен, это будет менее удобно.

### Что такое SQL-инъекция [44:16]

О'кей. А может слышала что-то про SQL-инъекцию? Что это такое? — А, ну SQL инъекция. Ну, это получается, когда мы можем вставить код SQL, если я не ошибаюсь, в запрос, и он у нас выполнится, потому что, ну, как бы придёт на сервер. Это уже подзабыла атаки. Вот. И, ну, для этого у нас вообще существует валидация данных, которые нам поступают вот при помощи — в плане какой-нибудь пойдентик условно, — да? Да. Вот по идентик, допустим. — А как он, например, спасёт, если у нас, э, есть какой-то endпоint, в котором принимается строка. Например, мы ищем по в маркетплейсе по названию карточки, там, я не знаю, мыльные пузыри. Человек может вместо мыльные пузыри написать, — да, какой-то — даже мыльные пузыри. кавычка OR 1 = 1. Ну, условно, и ему выдастся немножко не то, что задумано было. То есть по идентик здесь, ну, либо он должен быть супермощный, но, скорее всего, он тут не спасёт. — Ну, это да. — Ну да, та же алхимия нас спасает от лъекций. О'кей. А как ты с ней работаешь? Синхронно или асинхронно? — Ну, я работала и синхронно, и асинхронно. что-то может рассказать. Ну, то, что там получается просто у нас будет разница в том, что создаётся сессии. В одном случае у нас будет мейкер асинхронный, в другом, ну, другой синхронный. Вот, наверное, в этом разница. Просто то, что одному будут — рутины, другом уже просто будет, ну, синхронно всё работать. — Угу. А есть ли какой-то выигрыш от асинхронного использования? Асинхрону, ну, вообще получается это быстрее происходит, потому что, допустим, если у нас, допустим, открывается доступ к ПД, ну, допустим, подключение к ПД идёт, то пока у нас идёт подключение к ПД, мы не ждём, когда оно подключится, мы можем выполнять какие-то другие функции и потом уже вернуться к этой функции, где получалось бы D асинхронно, мы бы, ну, получается, у нас бы код как бы остановился, мы бы ждали подключений, только потом пришли какой-то следующий, может быть, ну, к следующему выполнению.

### Какой смысл использовать асинхронность, если используется SQLAlchemy [46:36]

— Мм, сейчас, а у нас же алхимия работает, так, что она же сразу держит какой-то пул подключений. — То есть вот, если говорить про подключение, у нас при там первых запросах уже формируется пул. У нас хранится там условно пять подключений. Есть ли тогда смысл в асинхронке? То есть мы не тратим уже время на подключения, они есть коннекшены. Если выигрыш асинхронки, тогда, — ну, в любом случае, даже если не про подключение говорить, а про синхронность и асинхронность. то у нас синхронность может блокировать какие-то другие, получается, операции. Вот. А если у нас асинхронность, то, ну, вот помимо подключений есть какие-то и другие, да, функции, которые у нас ну есть какое-то время ожидания, да, и которое мы можем поставить, так сказать, на ожидание и перейти к следующему выполнению, потом уже вернуть ответ от прошлой функции. Ну, то есть они как бы конкурируют, кто быстрее выполнится, не останавливаюсь, ну, не останавливая всю программу. Угу. Мм, а может ты знаешь, как до асинхронности, до появления асинхронности решали задачи около параллельного досту вот за запросов, допустим, чтобы там пять запросов отправить? — Ну, я что-то слышала, ну, так про многопоточность, многопроцессорность. Вроде бы разделяли потоки и при помощи этого — уже работали. Ну, так, чтобы программа не блокировалась, а разделялась на несколько потоков. — Угу. И типа то же самое. То есть мы тоже могли достигнуть какой-то параллельностики. — Ну, э конкретно многопроцессорсть, многопоточность я не использовала, но я так думаю, что это была как альтернатива. Вот. И потом это уже привели в какой-то более приемлемый вид. Ну и сделали асинхронность. — Угу. Ну, скорее, вот асинхронность стала альтернативой. — Ну, ну альтернатива друг другу, они как бы взаимо. — А, я понял. Ну да, раньше вообще асинхронки не было. Были потоки и писали все на них. О'кей. А вот, да, ты

### Как в FastAPI используют потоки [48:44]

говоришь, что не используешь там потоки напрямую. Это о'кей. Но знаешь ли ты, как в стапе как фастапе используют потоки? То есть сейчас навести на мысль. То есть знаешь ли ты, когда даже в асинхронном фастапе, когда все асинхронные роуты хендлеры, у нас всё равно могут потоки какие-то спавниться, там что-то выполняться? В документации видел? в документации не видел, но я так предполагаю, что скорее всего они как-то автоматически друг с другом работают. — Ну нет, это именно мы, именно мы пишем какой-то код с использованием в фотапе. Там встроенно есть такой модуль, что у нас какой-то код запускается именно в потоке дополнительном, а не в текущем в основном. — Угу. Вроде бы. Кстати, что-то типа тердин на английском что-то Рдн библиотека. — Можешь напи написать в чат может — что-то типа такого. Я очень плохо помню, если честно. — Ага. Ну да, как бы это стандартная библиотека, она называется трейдинг. Э — трейдинг. Угу. — Вот так. Да, ну как бы здесь скорее речь не про неё. То есть под капотом, да, скорее всегоспо используется она. речь именно, наверное, давай так попробуем. А видишь

### Когда использовать потоки в асинхронном приложении [50:11]

ли ты какое-то применение потоком в там современной разработке, когда они там даже тебе в асинхронном приложении могут как-то помочь? — Ну, возможно, — возможно какое-то может быть логическое разделение, м, чтобы один поток отвечал за что-то одно, другой за что-то другое. Может быть, так. Ну, сейчас. Ну, нет, скорее, скорее не сюда. — Затрудняюсь ответить. — О'кей. Понимаю. А вот может был опыт с бэкграунд тасками в фастапе? Какой там прямо есть? Граунд task. — Мновая задача. — Ну, работала только слари, может быть, только оттуда. — Ну, — а как селари как бы нам помогает? Ну, он просто фоново работает, обрабатывая задачи, то есть независимо от основной программы. Просто — А можешь пример задач привести, как бы и, — ну, вот, допустим, ну, мониторинг сайтов, то есть у нас есть какое-то основное, ээ, допустим, ну, как сказать, доступ, ну, допустим, есть какие-то ручки посмотреть, какой сайт, э, какой статус имеет, да, код. У нас она пока что не активна, но при этом фоновел у нас постоянно каждые 5 минут, допустим, да, проверяется какой статус код возвращает сайт. Вот это получается у нас будет как фоновая задача. А основная, ну, не основная, так скажем, — а ещё одна задача другая, это, ну, не знаю, ну, как сказать-то хорошо, э, ну, получение как раз вот этих фоновых данных, может быть, допустим, наоборот, добавление какого-то другого мюрла в базу, какие-то такие действия. А, ну я правильно понимаю, что они тоже сказать не нагружают наш комп, то есть это внешний какие-то запрос во внешнюю апишку или во внешнюю базу? — Ну получается, да, но при этом фоновая задача работает отдельно от основного, так скажем, приложения. — А почему её просто в while true не поместить и там будет таймер каждые 5 минут спать и потом запускать? Зачем сел или так далее? — Ну, потому что у нас будет тогда всё в одном целом. Это, наверное, не особо корректно. — Вот — почему? — Ах сейчас, ну, вообще, как будто бы можно и разделять какие-то, да, обращения КПД или там общение клиентсервера и, ну, действия фоновые. Что-то как-то затрудняюсь ответить. Не просто для специально для удобства, я думаю, создали отдельно селри, которые работают с фоновыми задачами, не просто так. — Ну да, что-то в этом есть, как бы звучит корректно, да, но интересно было услышать как бы аргументы, да, ну, базово, да, как бы действительно по логике это в голове тоже живёт как отдельные какие-то сущности. У нас есть там, допустим, какая-то апишка, допустим, которая там фастапе просто регулярно отвечает на запросы пользователей, ходит в базу, у неё нет какого-то состояния, ничего, расписание просто работает. А есть какие-нибудь там сери, ну, ты говорил про периодические сдачи, наверное, salary bitт. — Угу. — Э, как-то там мелькает. — И, во-первых, он не так сильно завязан наше приложение. И, допустим, если мы там редиплоим даже наше основное приложение, можем не затрагивать сери, э, он как себе работал, так и работает. А второе, нам легче, как больше есть готовые сервисы мониторинга под этот сери тот же Flow. Третье, мы можем, если это как, точнее, как отдельный докер контейнер, это запускаются, у них отдельные логи, мы можем отдельно настраивать уровень какой-то логирования более серьёзный для того же Sлери, для тех же фоновых задач периодических, чтобы за ними отдельно следить, потому что часто они очень важны. Там очень важно, чтобы выполнилась задача какая-то там раз в день. А то, что у нас какая-то ручка не обработается, одна из тысячи запросов, ну там, допустим, пофиг. Ну и есть ещё одна любопытная особенность у селари именно, а касательно работы какими-то нагруженными задачами. То есть мы часто хотим скинуть на сери не просто задачу input output, то есть формата, когда мы ждём, то есть мы ждём базу, мы ждём пишку, то есть мы не нагружаем себя, просто ждём, чилим. А есть вот ещё CPU задачки. А был ли у тебя когда-то опыт какой-то CPU нагрузкой, там работа, ну, с чем? Ну, с картинками, — аудио, с большими данными, массивами внутри памяти. Ну вот эмэлька у тебя ты говорила будет. А тут ещё очень важный момент, который хотелось бы услышать, что а ну не только селер есть у неё как бы тоже и альтернатива. Она запускается в отдельном процессе, и она не влияет на скорость и эффективность работы основного нашего приложения, нашей там опишки, допустим. Вот именно потому, что она крутится там вообще в другом ядре, в другом процессе, и нам не мешает. Вот. А её можно отдельно масштабировать, можно отдельно масштабировать количество там селари воркеров. То есть, например, на нам опишку не нужно масштабировать, там она и так всё выдерживает, а мы бы хотели только фоновые сдачи масштабировать. Тогда нам реально удобно, что это всё вынесено. Нам не нужно опишку масштабировать. Если бы всё было в одном приложении, мы бы ещё и лишний раз апи масштабировали без необходимости на то тратить оперативку, ну и деньги, соответственно. О'кей. А, ну, если я правильно понял, про потоки и процессы, ээ, лучше не спрашивать про разницу или — Пока, да, пока, да. — О'кей. Мм, да, вот это важный момент. Именно потоки процесса, хоть мы их часто не используем напрямую через модули мультипроцессинг и трейдинг, важно понимать, как это может афектить там моё приложение, если я запущу вот эту таску в карутине, там заблочит это меня или нет. О'кей, заблочит. А может тогда в потоке ухудшится или нет? Ухудшит. Ну, в общем, понять, стоит ли вынести задачу куда-то в другой микросервис, в другой процесс, в другой поток очень ценно, когда пишешь код. О'кей. А давай, наверное, пару вопросов ещё по асинхронности хочу задать перед базой данных. Мм

### Что такое корутина в Python [57:22]

что ты можешь сказать? Что такое карутина? Что такое карутина в Python? — Ну, карутина у нас есть вообще функция, у нас остаётся, получается, S def и объект крутины. Это то, что нас возвращает SDF. А вот сами функции у нас вообще вызываются при помощи weight. Что-то такое, наверное. — Угу. Да. А, о'кей. А может, ты знакома с тасками в Осинкао? Карутины есть таски. — Угу. — Сейчас подумаю. — Ну, что-то слышала, но прямо рассказать не смогу. — О'кей. Ну ладно. В принципе, это не критично. И опять же, да, когда пишешь, ну, часто бывает такое, что ты это не затрагиваешь, пока ты пишешь просто API, работаешь с базой. О'кей, ладно. Эту тему проедем. Мм, я предлагаю по базе

### Что такое транзакции в базе данных [58:25]

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

### Свойства транзакций, например, атомарность и долговечность [59:09]

— Угу. Да, они как это свойство называется, может, знаешь? — Там вроде абревиатура AC, ID, что-то такое, — атомарность. — Мм. Ух, потом долговечность. Ну, это последняя. Э, C и A что-то не помню. А помнишь, что такое долговечность? — Ну то, что если у нас транзакция произошла, то она сохранится у нас какой есть на долгое время. — Угу. Да. Да, в целом, да. Ну и про томарность в целом, да, корректно. О'кей. Про транзакции всё. Мм. Был ли

### Что такое индексы [59:48]

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

### Преимущества и недостатки индексов [1:00:33]

О'кей. А, а значит ли это какие-то минусы там индексов, недостатки? — Мм, недостатки. М, вот с индексами пока особо не углублялась, не узнавала. — Ээ, о'кей. Значит, давай я тогда объясню, как это происходит. У нас есть серьёзный минус у индексов. Первое, что они занимают место. Если у нас столбец весит гигабайт памяти, то индекс будет весить тот же гигабайт. И второй немаловажный минус, что когда у нас происходит запись в базу, то есть это либо insert запрос, update, delete, у нас данные в таблице меняются. В этом столбце, который проиндексирован, тоже может быть меняются. И у нас пересобирается индекс. То есть данные в этой структуре это либо дерево, либо ещё какая-то более извращённая структура, просто меняется расположение объектов, чтобы по ним было также быстро там за логарифм, за логарифмическую сложность. Кстати, это подсказка к самому началь к вопросу про пример с логарифмической сложностью. Это вот проход по дереву в классическом индексе в постгрес. Вот это два основных минуса: память и время. Нужно, чтобы пересобрать индекс. Ну, соответственно, база в это время типа хуже работает, просто медленнее. О'кей. А давай, если про SQL говорить, чем отличается left join от join? А, ну

### Разница между left join и inner join [1:02:02]

left он объединяется, допустим, если у нас рассматривать две таблицы как множество, то left, он объединяет, получается, всю левую часть и их объединения. А какой ещё раз второй джойн? — Inner. А инер - это вроде бы только их конкретные пересечения, — да? Корректно. О'кей. Хорошо. Прои

### Разница между having и where в SQL-запросах [1:02:30]

можешь ли ты сказать разницу между и в запросе? — Ну, ver он обрабатывает, ну, какие-то дастроки, столбцы, э, напрямую, то есть сразу же. Анг, вроде бы после только объединения можно его применять. будет корректно. — А объединение, как это записывается в виде SQL? — Сейчас, сейчас, сейчас. Всё из головы вылетела. Там т и — задача на это будет, — да? Оorder by Нет, вроде бы сейчас — нет. Ордер - это сортировка. Сейчас, сейчас. Всё, стресс заставил меня всё забыть. Сейчас может быть. — Давай. — Ладно, пока что-то не идёт. — В общем, группиров группировка. Как это? Это подсказка. Группировка, — да? Я понимаю, я понимаю просто как-то

### Что такое нормальные формы базы данных [1:03:32]

вообще. — Ладно, в общем, by, да, это, — да, вот, вот всё. Да, — ээ, да, но ответ корректный. А, хорошо. и пропустил вопрос. Знаешь ли ты, что такое нормальные формы в базе данных? Незнакомо. — О'кей. А, ну кратенько как бы рассказать-то кратко, какие-то устоявшиеся нормы, как мы, э, храним данные в базе, что мы не храним в одной ячейке. Ну, допустим, у юзера есть, как бы сказать, не знаю, паспортные данные. У него есть два паспорта, старый и новый. И вместо того, чтобы заводить таблицу паспорта и там в отдельные ячейки хранить старый, в отдельный новый и через там внешний ключик связывать, мы просто в таблице users добавляем поле passwords и через запятую пишем серии номера. Это условно очень грубое нарушение нормальных форм. Я уже не помню какой, потому что тяжелее работать с данными, тяжелее по ним искать, обновлять, удалять и всё такое. В общем, это про то, как мы храним данные. Ну, это как-то очень вот если кратко, э, ладно. Ну, обычно это как бы как это по-русски здравый смысл. Э-э на основании здравого смысла мы не будем так хранить данные обычно, если мы что-то про базу знаем. Но тем не менее этот здравый смысл описан в нормальных формах, как стоит хранить данные в базе бы, например, не хранить их в списке. То есть можем в ячейку же в постгрес положить список какой-нибудь, да? список ID заказов пользователя или список комментариев человека в телеграме, вместо того, чтобы по внешнему ключу какую-то дополнительную таблицу создавать и many to many и пить их таким образом. Ну ладно. М давай ещё немножко гит затронем. Тоже важная тема, чтобы ничего лишнего не коммитить. Скажи, какие основные команды гита ты используешь? Gгиit

### Основные команды Git [1:05:38]

— Push P. Ой, нутпуш полу комит инит — цивилизация. И пока на этом всё.

### Как ведется работа над общим репозиторием несколькими разработчиками [1:05:50]

— А, о'кей. А вот ты сказал, что хочешь, ну, собираешься искать работу вот, ну, допустим, скорее всего, в команде, и часто разработчики ведут командную разработку в общем репозитории. Можешь ли ты описать, как ты себе представляешь, как ведётся работа над общим репозиторием несколькими разработчиками? То есть какие там есть, я не знаю, церемонии, процессы, что там отличного от того, когда ты сам просто самостоятельно в одиночку пишешь код в репозитории? — Ну, я так предполагаю, что есть какое-то деление на ветки. Вот. И, наверное, каждый работает со своей веткой, чтобы они как бы, ну, изменения какие-то не пересекались с другими. Вот, наверное, так. — Что ещё? Ну, каждый ответствен за свою часть и для удобства оставлять комиты, которые, ну, понятны, так скажем, что произошло, какие изменения внесли, чтобы можно было, если что, откатить и посмотреть, что было.

### Какие типовые ветки встречаются в проектах [1:07:01]

— Угу. Так, а как вот код и то есть, а можешь назвать какие-то типовые ветки, которые встречаются в проектах? То есть не вот не под фичи какие-то, а вот типовые, которые чаще всего есть в проекте. — Ну, обычно же используют ветку main. — Угу. — И, ну, вот это основная ветка, если проект какой-то очень простой, в одну ветку всё запулить. — Так, а если чуть сложнее? Если сложнее, ну, я так подозреваю, что мы можем, ну, несколько веток можем создать, э, где будет какая-то главная и, возможно, не то, что ветления от неё, но какие-то обочные, наверное. — Для каких целей? Ну, я больше представляю так, что у нас каждая ветка отвечает за какой-то отдельный процесс, и уже в каждой ветке, да, есть какие-то, допустим, там, не знаю, файлы, Redmi и так далее. Пока что только так представляю, команде ни разу не работало.

### Какие этапы и ветки в git проходят изменения [1:08:07]

— О'кей, справедливо. Я это понимаю. Но тем не менее, вот есть ли у тебя представление, как, допустим, какая-то фича попадает в продакшн уже к пользователям в той же там социальной сети, которую ты пилишь? У тебя, допустим, есть какой-то там в починении разработчик, ты поставил ему задачку, чтобы он там какое-то поле в базе данных добавил, как вот это его изменение попадёт уже пользователям? Какие этапы и в гите должны пройти, может быть, ещё в каких-то там в развороте этого приложения? Как это шаг за шагом происходит? — Ну, я так понимаю, мы не ну мы не можем предстановить работу, да, нашего приложения. — Мы не хотим, мы не хотели бы, да. Вот поэтому у нас есть какие-то разные версии нашего, ну, приложения. Мы берём нужную нам, дописываем, а, получается, закидываем эту. Ну, сначала у нас она проходит, соответственно, тесты, — потом уже — теплой и попадает к нашему — Сейчас, сечас. Стоп, стоп, стоп. Как-то мы пропустили. Вот. А в гите какие там ветки? Ну, в гите у нас — он прямо в ме пушит или — Ну, он, получается, пушит — на в ту ветку, где у нас, ну, где мы хотели вот из какую часть мы хотели изменить. То есть — это новая ветка или это мейн ветка? — Ну, то есть смотря где у нас находится та часть, которую мы хотели изменить, наверное. Так, если, допустим, у нас в мейне, то мы запушим в ме как-то

### Есть ли процесс проверки кода другим разработчиком [1:09:42]

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

### Как называется процесс переливания кода из одной ветки в другую [1:10:09]

Ну, есть, да, этот термин, но я, ну, думаю, то, что такое же происходит, такое на практике, я думаю, есть, но я как-то этот термин, ну, либо не знаю, либо сейчас не могу сказать. — Ну, это называется часто либо merch request, либо pllрест. — Угу. — Ну, это даже это не именно факт слияния ветки. Как бы факт слияния - это мёрж команда. Но вот я именно хотел слышать про то, как ты это представляешь, что обычно у нас есть всё-таки мы не работаем в майнвеке, никто из разработчиков никогда там ничего не пишет, мы только туда мёржим код из наших веточек. Мы ответвились, какую-то фичу написали, протестили, всё д, смёржили обратно. И вот перед, ну, и как бы разработчик обычно рядовой, он не может сам на как бы наш реально продакшн код залить какое своё изменение. Оно должно пройти проверку там главного разработчика и разработчицы. То есть процедура cд review, э, тоже я хотел бы услышать. Он создаётся мёрзший квест из там пича ветки в метку. Ты там говоришь: "Всё хорошо, я". И вы мёржите. А вот, ну и про деплой и развёртывание, наверное, тоже хотелось бы слышать что-нибудь там про CCD хотя бы упоминание. Вот. Ну, а если уже дальше забегать, то, конечно, хотелось бы немножко слышать, но я сомневаюсь, что это нужно на самом начальном уровне, что у нас есть обычно не только ветка main, то есть не только продакшн

### Процесс код-ревью и деплоя изменений в проекте [1:11:47]

так называемый prodдаction сайт. У нас ещё есть, например, какой-то поддомен, на котором у нас всё, тестировщики живут и тестируют наш сайт. То есть, если у тебя соцсети, там было бы миллион пользователей, довольно страшно сразу на них выкатывать все изменения. Обычно так делатся, что у нас есть перед продакшеном ещё в одном там двух экземплярах развёрнутый тот же самый сайт, тот же самый backкфрон, то есть всё полная копия сайта. Просто там никто не сидит использователей, кроме бэкндеров, фронтендеров, тестировщиков. Там всё тестится. Ну, если говорить про гит, то у нас есть ветки, там, допустим, деф, это разработческая ветка. Туда можно, ну, какой-то говнокод может туда попасть даже иногда. А мы всё тестим, правим, опять комитим, опять мёржим. И потом уже раз там в несколько недель, там раз в неделю, в две мы в main торжественно а льём изменения через тоже request из deва в main. О'кей. Ну, это вот последняя часть про стенда, наверное, она не так важна для начинающего разработчика, но про код Revвwest, наверное, было бы хорошо узнать, просто потому что когда ты как бы как ожидают другие разработчики, что когда ты приходишь в команду, ты уже ну представляешь, как это происходит, чтобы не объяснять какие-то супербазовые вещи. О'кей, погиту понял. Я сейчас предлагаю перейти к практической части и проверить, как ты справляешься с написанием кода. — О'кей.

### Задание 1: обмен ключей и значений в словаре [1:13:18]

— Итак, у нас сейчас будет две практические задачки на Python и на папе, на фастпе, и затем отполируем уже SQL задачкой. Посмотрим, какой реально сейчас навык написания SQL запросов. Первая задачка на условие: надо написать код, который поменяет в словаре ключ и значение местами. И вот пример словаря. То есть он может быть абсолютно любой. Просто как пример, на котором мы всё это проверим, можно, собственно, приступать. — Так, ну, я думаю, а можете чуть-чуть убрать курсор, а то он меня закрывает. — Да. О'кей, — спасибо. Так, ну я думаю, что-то типа пройтись с циклом. О'кей. М, получается, там вроде надо items. — Угу. — А, ну и поменять, получается, значение и ключ. Ключ значения. — Так. Так, ну мы должны вроде бы взять items. Нет, прямо можно напрямую, вроде бы. Окей. И, ну, даже, наверное, это пусть будет как если функцию, может, лучше написать. — Ну нет, можем без оформления через функцию. Ну тогда думаю так. Сейчас ещё раз чуть-чуть про это пробегусь. — Пока думаю так. — Угу. Да, запятая. А, о'кей. Давай, ээ, если ты сдаёшь решение, то можно запустить и посмотреть, работает ли оно. Кнопочка справа снизу — пусто. — А, ну да, давай выведем на печать D. Что-то я тоже подумал, да. Так, как ты думаешь, почему не поменялось? Ну, я предполагаю то, что, ну, получается для K, ну, у нас получается как будет как счётчик и value значение в нашем дикт. И, наверное, лучше бы применять D items как-то распаковывать, что ли. Так. Ну, потому что по сути я просто по сути ничего не сделала. Я просто поменяла значение, ничего не произошло. — Угу. Ну, я думаю, надо как-то работать d. items. То есть в принципе в принципе мне же вообще вроде бы, да, нельзя запускать, просматривать, что происходит. — Э, ну как бы за это будет, э, виртуальные очки сниматься. — Всё поняла. Ну, наверное, я должна применить D items ключу и значению, чтобы их поменять местами. Как-то так это должно сработать. Ну, как, как именно это правильно записать? Сейчас бы вспомнить, понять. Сейчас, может быть, он будет подсказывать, если я что-то буду писать. — М. Давай сейчас перед тем, как писать, я попробую чуть пример расширить, чтобы сразу ты сказала, сработает ли тогда эта история. Допустим, если вот так будет. О'кей. То есть как бы надо сделать так, чтобы мы в идеале не потеряли никакие данные, да? То есть если у нас где-то совпадают там ключи значения, то они, может быть, могут перезаписать друг друга где-то. Ну ладно, в общем-то, давай продолжать. а работала с таким функционалом, когда мы что-то передаём? Нет, я просто вот как-то пытаюсь вспомнить, что-то воспроизвести с дикт, как именно менять. Поэтому я так — думаю, а сейчас, ну вот давай подумаем, как это будет тогда происходить. Если итерациями, то есть можешь вот расписать для каждой, то есть там через комментарий какой-нибудь через Python, что у нас будет с А, потом что станет CD, потом с третьим и с четвёртым. Ой, случайно. — Ну, у нас получается, — ну, итерация с нуля. Мы берём сначала первый, да, ключ значения. Ну, мы должны их поменять местами. То есть, в принципе, ну, я думаю, это будет работать как-то так, но именно написано вот эта часть по-другому, то есть просто обмен. Вот. Потом перейдём к следующей рации. Мы перейдём к следующему ключ значению, поменяем их местами и дойдём так до конца. — Сейчас, сейчас. А вот давай прямо распишем, как бы, какой у нас будет, э, прямо итеративно. Вот было А двойточие B, станет B двоеточие А. просто так и расписать, — да? То есть тут где-то, возможно, возникнет какая-то проблема с этим тогда. — Ну, у нас получается ника меняется. А, ну то, что у нас возможно, да? Тут здесь строка и int. — Он будет жаловаться то, что мы меняем местами и ну то есть на место строчки мы хотим поместить инта на место инта строчку. То есть у нас будет, ну, неподходящий тайм. — Нет, почему? В этом ээ плане всё хорошо. Здесь ошибки нету. — Не будет. — У нас может быть ключ ээлом. — Ну, ну к ключ у нас, да, может быть. Просто я имею в виду то, что если мы их будем менять местами именно как строчку и число может быть ошибка. Вроде не должно быть. Здесь немножко другая проблема в плане, если мы на ходу О'кей, давай подскажу. То есть, меняем, у нас становится BA, у нас становится DC, затем у нас становится 45. Аа, и у нас потом получается, что у нас ещё ключ 45, то есть мы уже на нём находимся. Хотя, вроде бы у нас уже ключ только что мы его переписали. То есть у нас как будто два ключа — э одинаковых и в D может — уменьшиться количество значений. Ээ, как можно, давай вот так, как можно этот словарь поменять таким более простым, примитивным способом, как бы максимально надёжным с твоей точки зрения? Он может быть не самый оптимальный, но точно рабочий. А, ну, если самое простое и такое примитивное, можно, наверное, проверить, нету ли таких ключей, похожих со значениями. Если эти ключи есть, то временно замените на какой-то, ну, уникальный уникальное значение, а потом обратно поменять. Получится сложно. И ещё проще без проверки вот таких случаев. — М без проверки. — Ну, если, допустим, — не обязательно. Угу. Если у нас есть какое-то значение, которое совпадает с ключом, то сначала поменять ключ значения. Вот ключ, который совпадает с значением, потом уже получается перейти наоборот к значению, которое совпадает с ключом и поменять их, то есть, ну, поменять порядок изменения. — Мм, тоже как будто не сложно. М. А если просто создать ещё одну переменную переприсвоить, создать ещё один словарь, используя и данные из D словаря, потом переприсвоить D словарь просто на новый словарик. — Мы сначала не меняем D, создаём новый. И потом говорим, что а вот это новое, это теперь D. — Угу. — Так, а как это как именно мы определим то, что у нас будет получаться два одинаковых словарика? А и мы в одном Как их поделим, ну, как мы именно выделим то, что у нас ключ значения, тогда поменяется корректно. А, а учитывая в данном случае, что вот в этом примере мы сразу меняли D, и поэтому бы возникала проблематика с, ну, типа с коллизией. Ну, не с коллизией, что с одинаковым ключом. А если мы не будем трогать D и просто где-то вот в следующей строчке скажем, что у нас есть словарь ещё там C или какой-то D1, D2, — да, — а, то есть мы не будем менять D, тогда здесь ключи и значений не будут переставляться, и мы можем спокойненько провернуть нашу операцию, по идее, а потом сказать, что, а, так, это же теперь у нас D, а не D1. Понятно. Механика — как-то, если честно затрудняюсь. Можно вот сейчас вот момент такой потом его вырезать. Хорошо. Я вот как-то, если честно, очень сильно теряюсь. Прямо переживаю прямо, не знаю, всё из головы вылетает. — Я, если честно, не знаю. Вот как-то, ну, по сути, лакодинг - это же то, что я пишу. Вы мне так объясняете всё. Мне кажется, вообще это будет ли полезно вам для контента? — Да, это будет полезно. Ээ, как бы не должно быть такого, что собеседование человек всё ответил. Это убьёт у всех мотивацию. Если придёт человек, который идеальный просто Википедии. Ну и все скажут: "Блин, зачем мне тогда стараться? Я сдаюсь". А здесь суть в том, чтобы показать, что этот человек знает у тебя. Ну, я в конце это всё скажу. Как бы необычный путь, что ты перепрыгнула, ты сама сказала, перепрыгнула многие темы и пошла сразу дальше уже в прикладную разработку и пропу пропустив какие-то, может быть, более базовые для других людей темы. А, но это неплохо. Это просто твоя особенность, и я это в конце скажу. А, ну давай — просто ничего. Так, то, что я вот прям, ну, я прямо я вижу, что я торможу. Я понимаю, что это прямо база база. Так и есть. Ну, как бы оно так и происходит на собеседованиях, как бы. Мм, тем более мы собесимся на там какой-то базовый уровень. НимиID midл ничто. Это о'кей. Это нормально. — Всё хорошо, спасибо. — Вот на второй сдачке будет легче. — Надеюсь. — Вот. Да. — Угу. Давай попробуем создать просто, например, там, если этот код убрать этот, э, попробовать создать ещё один словарь под D, как-нибудь его обозвать, там D1, D2. И, мм, это можно через однострочник сделать, если ты, если тебе О'кей, либо через цикл заполнить. То есть сначала его объявить пустым, а потом а заполнить. Здесь как удобнее. Можно также пройтись по айтемсам, как у тебя написано. Просто заполнять мы будем уже другой словарь. Я как-то вот ээ забыла, как именно обращаться к элементу в словаре. То есть, по сути, ну вот это я понимаю, что это не так. У нас тут не может быть такого, да? Сейчас, ну, здесь, наверное, D будет, а не D1. А, — по-исходному, — поисходному сначала. — Тогда может просто поменяем местами. — Сначала поисходному, потом мы заполним второй D1. Вот. И хотелось бы сейчас, а, — ну, получается, когда я беру просто такие просто значения, то ничего не происходит. Я вот именно как мне взять вот можно подсказку именно элемент, то есть, ну, значение ключ обратиться. Ну, получается через D1 тоK или как? Или а ну items тоже он не принимает ничего. Сейчас тут нам понадобится всего один for, а-э. То есть вот эта история нам не особо нужна. Мы проходимся по нашему текущему массиву словарю. — Угу. — Мы из него знаем, что K там - это A, value - это B. И мы хотим вот тут условно у D1 для value поставить. Всё — окей. — То есть вот этот код получается уже нам не особо нужен. То есть мы таким образом что сделали этим циклом? — Ну, мы меняем пока что для значения ключ. Так, — ну как бы как у нас сейчас выглядит D1, — точнее D1 мы, ну, в наши D1 значение мы вкладываем ключ, когда проходимся фором по получается D, причём, — то есть у нас тут D, а тут вообще D1. И мы меняем таким образом значение у D. Да, значение сейчас. Угу. А вот у нас изначальный словарик, мы его как-то сейчас видоизменяли. А — изначальный вот сейчас, ну, получается, я вообще прохожусь по D, да, то есть в словере D я прохожусь. И при этом я обращаюсь к значению — в D1, а D1 у меня пока что пустой, и присваиваю значение D1 ключ даже, э, получается значение. Ну да, значение получается D1 ключ, который в словаре D. — Угу. — По сути, так. — Ой, нам осталось одну строчку написать. — Теперь просто наоборот. То есть мы проходимся опять по, ну, не пять, а всё, с самого начала до конца по D. Сначала мы, получается, сделали значение. Ну, теперь нам нужно наоборот сделать ключ значения. — Мм, а что, если просто сказать, что D - это теперь D1? — Мм, если мы сделаем D тепер — это теперь D1, то у нас получается, я так понимаю, — вне цикла. Тактактак. Сейчас. Ну, у нас получается поменяются ключи и ключи у, ну, они будут совпадать. Сейчас, ну, у нас по сути недостающий, ну, у нас нет уже ключа у D1. Если мы скажем, что они равны, то у нас должен привиниться, что дописать ключ — сейчас. А вот, э, после того, как у нас вот этот цикл завершится, у нас D1, как он выглядит? Он по-прежнему пустой или в нём что-то есть? — Ну, вообще в нём что-то есть. То есть получается, у нас было D1, а мы берём, а, обращаемся к значению D1 и присваиваем к значению D1 ключ из словаря D. Вот. Но при этом мы трогаем только значение, не трогаем ключ. Но при этом сварит у нас это ключ значения. То есть у нас какое-то пустое место, это ключ. И потом мы в значение присваиваем, ну, допустим, так его значим то, что это, не знаю, D. То есть мы у нас теперь здесь значение - это ключ из D. Вот. Но при этом, что у нас вот здесь будет образовываться после цикла? — Давай попробуем сейчас вот сделать. Вот я сделаю просто так, чтобы мы посмотрели сейчас пока другой прин закомень. А сейчас тоже появится. Вывелась каменьчик. Что ты можешь сказать после того, как видно вывод этого кода — или всё так же, как ты и предполагала? — Так, ну, получается, первый цикл мы проходим себе по словарю D, выводим ключ значения. У нас получается выводится AB CD 125 45 123. Ну, первое, так и должно быть, по сути. Так, — мы обращаемся сюда к и значению. Значит, получается, ну, единственное, что я чуть-чуть запуталась тем, что у нас значе, ну, ключи, значения, можно прямо так напрямую обращаться, и они выводят, — ну, словаря вот — напрямую. То есть, по сути, если мы пишем вот так, ну, это же, ну, вообще это — так — D1 словарь. Угу. И мы берём значение. Сейчас мы берём значение, допустим, у нас здесь так. Ну, допустим, 0 ноль у нас. Значит, мы обращаемся к значению один и кладём ключ. Да, получается, вот здесь — лежит — у нас не просто — пусто — что-то лежит. А почему пусто? Мы же сказали, что — вот это название ключа по сути. — Какой ещё раз не было видно. — Ну да, да. Но мы только что выяснили, что value, когда мы проходимся по the items, тут как и тут, это вот это правое значение, то есть BD 45 23. Значит, тут, как сказать, как бы нет, давай вот так. А, example, то есть ловарь example = А. Как у нас выглядит сейчас? Ну, теперь он получается Угу. Сейчас. А, ну теперь он, наверное, как-то, ну, он вообще переприсвоился, наверное. Теперь он будет как, а, но у него же, ну, это же вообще по сути словарь, значит, должно быть, значит, нужно думать, что будет ключ значением. Так. Люди, что значение вот этого, — ну, по сути, вот это ключ, а это, наверное, значение, — да? Да. То есть он будет выглядеть вот так вот после этой операции. Ну и теперь, если смотреть так, то мы, получается, мм, ну, получается, ключ, ну, получается сейчас, сейчас ключ для D1 это будет K из просто D. Так, это получается, ну, в первом случае это будет А. И потом, если мы, а, сейчас ещё раз перепроверим, — ну да, по сути, это, ну, точнее, не а, а. — Угу. — Сейчас равно. Так, значение значение в D1 это равно K из D. K в D - это А. Всё, это получается будет А. Но при этом я говорю, что дальше тоже самое, потому что деке это получается тоже вот это. Так, сейчас я подумаю ещё. А, ну у нас получается будет просто поменяется местами, потому что у нас, если здесь было B - это ключ, а это значение, значит, у нас ключ - это будет м из D, то есть у нас будет вот здесь вот B, а здесь будет наоборот тогда, то есть мы теперь вот здесь вот присваиваем наоборот к словарю D1 значение, но значение А в это получается — А, всё. — Угу. — Ну, получается, просто поменяется местами. — Ну да. То есть после первой первого первой итерации, да, у нас есть весь цикл прогонится. — Угу. — После полностью фора у нас получается тут в D1 только Б будет или ещё ключи какие-то? — Ну да, у нас получается до конца он поменяет всё местами. как вот D1 только, ну, точнее, как D, только теперь поменяется ключ значения местами и будет D1. — Ага. Так, сейчас это свой вспомогательный код удалю. А и что нам осталось сделать, чтобы изначальный словарик D теперь, — ну, можно — в нём поменялось? — Можно переприсвоить просто сказать, что — давай — просто сказать, что D D1 - это D и вывести уже D. И по сути оно должно так сработать перед присваиванием. И вроде бы дикт так и можно переприсваивать. — Можно. Ну давай подумаем, что к чему мы должны переприсвоить. — А, да, наоборот. Жд всё же выводим, да? — Ой, что там пролось? Да. Вот так. Всё. — Давай попробуем запустить. Да, да, мы полностью его развернули. То есть мы не потеряли вот эти 45, которые там в моменте то был ключом, то значение, да? С ты задачей справилась.

### Задание 2: Анализ и улучшение REST API [1:39:35]

Хорошо, давай двигаться ко второй. Тут есть вкладочка слева два. Я думаю, с ней получше пойдёт, потому что, я думаю, по фастапе у тебя хороший опыт. Задание слева. Ты случайно увидела код коллеги там разработчика и в тайне. Вот скажи, что бы ты изменила в этом коде? — Сейчас подумаю. — Ну, а если так быстренько бросить взгляд, то, мм, по-моему, ошибка, не уверенно, вроде бы другая, но просто статус код 400 - это B request. — Так — вот. — А что он значит? Когда он отправляется? Он отправляется вроде когда неправильно что-то с данными обрабатывается не так. — Неправильно к или неправильно фронт? Кто? Ну, ошибки 400 - это неправильно. Ну, что-то у клиента. — Клиента, да. — Угу. — Так, а здесь как должно быть? — Ну, а здесь я думаю, что всё же это, наверное, будет ошибка сервера, если у нас не получится. Сейчас думаю, ну я просто я вот не уверена пока что то, что здесь именно нужно код ошибки 400. У меня есть сомнение. Ну пока вместо какой? Пока думаю, не знаю. — Угу. О'кей. — Так, сейчас ещё посмотрю. — Ну, можно было бы мре, ну, как бы чёрн сделать. Ну, какую-то модель прописать, а не прямо вот так вот напрямую. Ну, в принципе, для лёгкого такого кода, я думаю, ничего страшного. — Вот. Ну или прописать, допустим, что мы ждём на возвращение функции тоже как ээ ну как пролизировать, наверное. Так, сейчас ещё посмотрю, подумаю. Ну, если я не ошибаюсь, вроде и так напрямую ошибки, ну, можно отправлять, но нежелательно. Вот так вот то, что мы выведим ошибку. — А как бы ты поменяла? — Ну, здесь указать какую-то ошибку, которую мы отдадим клиенту без вот этой части, а чтобы нам было удобно, ну, работать с ошибками, прологировать, наверное, эту часть. логом обернуть ошибку. Ну, если, соответственно, мы обернём эту ошибку, то, ну, и прописать то, что вот тут вот мы заходим в trй, там, ну, информационный диалог прописать или, допустим, мы зашли в exе или так далее. Сейчас ещё посмотрю, подумаю. — О'кей. Тут могут быть как бы даже не то, что код упадёт, а какие-то договорён, ну, не знаю, общие разработческие договорённости. нарушаются какие-то, может, принципы, — устои, я не знаю. — Ну, пока больше не могу назвать, мне кажется. Пока не вижу. — О'кей, давай я дам наводку. А, наводка rest. R. — Ну да, правила общения клиента и сервера. — Нарушен ли здесь эторест? Так, ну я предполагаю, что, ну, то, что одно из это, наверное, то, что нельзя выдавать ошибку полностью, да, клиенту. — Мм, такого я не помню, вроде. — О'кей. В адресе, — да. Вот я тоже думаю про адрес. А сейчас, ну, мы можем вообще какие-то поставить дополнительные теги, да, на наш endpoint указать. У нас вообще адрес указан прямо так — теги. Ну, в принципе, — постапили префикс. — Ну, и префиксы накинуть, ну, наш нашу ссылку. Или мы можем, допустим, поставить теги для того, чтобы нам было удобно работать с документацией по стапе. Так, а тут, ну, сейчас, секунду, как бы корректный ли здесь HTTP метод. А корректно ли здесь? — Ну мы вообще, что мы здесь делаем? Мы — мы же ничего не меняем. Здесь используется пост. Сейчас посмотрю. — Ну мы типа предполагаем, что мы создаём какого-то гонщика. Просто да, здесь нет взаимодействия с базой, но оно где-то присутствует. — Так, ну просто нормально и обратить внимание на вот это. Так, есть ли для тебя здесь что-то странное или всё о'кей или всё нормально? — Ну, в принципе, — ну ладно, давай я скажу. Мне кажется, учитывая, что ты, если работаешь с GRPC, э здесь может как-то не заметить ээ неточность реста. А, ну потому что в речно не используем глаголы в принципе create, delete, ну или стараемся их не использовать и во множественном числе часто пишем какие-то сущности. — Угу. — То есть у нас там get racers будет, там post racers, условно какой-нибудь delete racers и там у него какой-нибудь айдишник. — Угу. Вот вместо того, чтобы писать там вот так, типа, вот, то есть это не принято ростом. О'кей. Ну, это просто как бы правило хорошего тона. Э, с одной стороны, с другой стороны, пост и так предполагает создание, и это тоже частично здравый смысл. Вот если возвращаться там к нормальным формам, к ресту, правилам, они часто просто преследуют то, чтобы все использовали здравый смысл. О'кей? И давай ещё подумаем, можно ли здесь где-то пайдентик встроить, чтобы стало удобнее. — Ну, как раз-таки можно, мм, запрос и ответ обрабатывать. То есть мы можем вот это обернуть, в принципе, в — А что бы ты здесь сказала более важно? Вот если бы тебе можно было только либо входящие данные, либо выходящие провалидировать. — Входящие данные. Ага. А почему именно в этой ручке? — А, ну в этой ручке, потому что я ходировала входящие, потому что это, ну, так сказать, более важно, то есть то, что у нас будет поступать и что мы будем обрабатывать, к чему обращаться. Вот. И если у нас будет корректно обработаны входящие данные, то есть у нас же не какой-то вот тут вот происходит, да, с ними действия, то, соответственно, выходящие тоже, ну, их корректность, процент корректности повысится, если мы будем валидировать входящие. — Логично. А согласен, но у меня так такое точка зрение, да, давай заканчивается этой задачей. В общем, я закончу тем, что я думаю здесь пойдентик бы помог просто вот этот код как-то убрать. — Ну, меньше какой-то — какой-то рейсермы, допустим, мы написали и всё. У нас под капотом происходит уже проверка, что у нас есть там поля, нет полей, вбрасывается 422. Ну, по дефолту по идентика. И тогда бы мы просто эту модель как-то тут уже, знаешь, типа дата, ну не дата, а реacсерли бы, а то есть сократили бы код, а было бы легче читать, была бы автоматизированная работа с ошибками. И по поводу четырёхсотого кода, мне кажется, он всё-таки здесь корректен, потому что у нас есть какая-то договорённость с фронтом, естественно, она в дикте не была прописана. То есть кто-то непонятно, что договорённость в свагере будет просто дикт. Это ужасно, конечно. То есть фронтендер будет на нас э очень недоволен нами. Ну и как бы мы тоже словим, э мы тоже потеряем время то тем, что будем объяснять фронтендеру, какие у нас там поля, и тестировщику, поля. То есть мы сами типа жертвуем своим временем, просто не прописав здесь валидацию данных и в сгере, в свагере уже данные не подставив таким образом. Ну и да, это просто код, который сейчас нет смысла писать. То есть тут либо датакласс, либо Pдентик с автоматической валидацией были бы очень кстати. Мм, наверное, базово так вот. Да, в целом, в целом здесь, э, ты лучше справилась, э, но видно, что как бы типа ещё не намётан глаз, что ли, на эти штучки с рестом. Их часто спрашивают на собеседованиях. Ну, и в принципе, когда ты часто пишешь именно рест, опять же, у тебя такая специфика, что, я так понял, с ним меньше взаимодействия, то это может быть не такая насмотренная тема. А вот в плане работы с данными, чтобы не вот так через строчку, там четыре строчки целых тратить, чтобы распарсить словарик, это уже такое базовое понимание программирования, даже не то, что Пайтона, это неудобно, это некрасиво, это можно, а, вынести какой-то в отдельный модуль или какую-то готовую библиотеку типа пойдентика применить. Вот. Ну, в остальном, да, здесь действительно не какой-то прям суперзверский ужасный код. Тут, понятное дело, что вот так не очень хорошо делать. А, согласен, что лучше там, наверное, вернуть модельку, чем какое-то сообщение. Ну, либо там отдельно какое-то сообщение, отдельно там данные или модели, я не знаю, как обозвать. То есть это условно, я так понимаю, что типа на клиенте отображается это уведомление, да? Иначе зачем бы оно отсылалось? А про логи тоже верно заметила. нам бы было бы хорошо лагировать любые ошибки.

### Задание 3: Решение SQL-задачи [1:50:39]

А я теперь предлагаю перейти к завершающей задаче. Она будет по SQL. — Угу. — А я попрошу тебя продемонстрировать экран. Вот по что там не видно в лайве эту историю. А, да, сейчас кину в телемост и давай решим вот эту. Да, вот эту задачку — последнюю. Да, сообщение. Дадада. Да, да. Значит, условие лево. — Угу. — И можно, собственно, приступать. — Так, сейчас я дополню задачкой. Ну, по сути, мы должны можем пока написать, что нам нужно вывести название стороны. Это получается, оно кроется country в Name. А, то есть получается можем сразу написать name и отк пока что from. Что у нас тут? Так, пока так уж будет. Так, пляж таблицами наибольшее количество различных языков. Угу. Так что у нас дано в странах в странах. Угу. Так, так, так. У нас получается связано кантрис и язык страны. М сейчас чем он тут? А, кодом. Угу. То есть мы по сути можем их объединить по коду группировать и вывести, получается, наибольшее количество. Угу. Скорее всего, я думаю, это будет как P. А мы, наверное, будем по что здесь есть название по CRС. и получается country sandвиe. Так, теперь нам нужно будет выбрать, получается, что ещё раз посмотрим, наибольшее количество различных языков. Так, я думаю, теперь возможно можно уже даже, наверное, только как мы его будем сейчас. Только тут вотту я что-то м неправильно сделаю. А он сейчас вот так. Ой, нажала, у меня всё разлетелось. Так, здесь у нас получается по коду так. А и в получается это у нас, ну, пусть будет пока так по длинному. М. Так, что тут? Ко также называется. Тут просто код, да? Там код. Так, сейчас проверю. Угу. Так. И теперь нужно отфильтровать. Нам получается наибольшее количество различных языков. То есть нам нужно, наверное, посчитать, где у нас наибольшее количество различных языков. А я вообще так тут города. Это нам вообще вроде бы не нужно. Да, это нам А здесь у нас отвечает так, лисы официальный, не официальный и процент. Так, то есть по сути нам нужно процент вывести наибольший. Так, настро, который использу большее количество различных языков, и вы видите её название. Нам нужно, получается, наверное, посчитать langвич и вывести максимальный максимальное количество. Сейчас подумаю чуть-чуть. — Угу. — Ну, это что-то типа. Так, сейчас, наверное, где гдеж. Ну, может быть, если я напишу здесь пока что временно м подсчёт, не помню, как точно, но, возможно, да, Макс есть. или даже, наверное, макс и в скобочках language. И причём я могу даже сделать вот как-то такое поле. Ну, пусть будет краткое вну. Так, и здесь я тогда должна вообще по сути мм взять то же самое, то есть просто максимальное количество. Что у нас тогда вернёт максимальное количество, если я буду смотреть по языку? языку, то что я вообще обращаюсь к столпсу? Что-то вообще не туда сейчас ушла. Надо к процентам обращаться. — А о чём проценты говорят? — Проценты вообще использовании конкретного языка, а тут получается вообще различных языков, да? Единственно, то используется большее количество различных языков. То есть, то есть получается всё же. И тут где-то есть даже, наверное, где 0%, да? То есть надо как-то это обходить. — Не, нет, нет. То есть как бы если он используется, там не может быть ноль, иначе он бы не использовался. — Так, сейчас. Ну я бы, наверное, посчитала не Макс тогда аккаунт. И тут то же самое. Вроде быкаунт что-то вроде бы по-другому как-то именно используется. писываются. Мне кажется, там как-то она не так выглядит, что в скобочках. Ну пока почему и так. Сейчас ещё раз просмотрю. Так, мы получается выведим. У нас что просит? Поля различные бицены. Так, найдите страну, которая используется наибольшее количество различных языков и выведите её название. То есть мне, в принципе, вот это можно не выводить. А только name, ну, пусть пока будет. То есть я, получается, вывожу имя страны м из countries. Группирую по countries и а countс и вот получается language по их получается коду. Тут это код. Здесь это получается countтри код. И теперь мне нужно подсчитать количество языков. Мм, ну я думаю, что-то как-то типа аккаунт, но я не уверена, что вот это правильная запись. Но здесь это просто можно будет убрать. Ну, может быть, я так подозреваю, что мне это неправильно. Можно какую-то, может, подсказку вот по поводу вот этого. — Мм, ну давай вспомним. Where иг. Они что делают? — Ну, они, получается, ну, фильтруют по — столбцам. Так — вот и соответственно мне нужно сначала отфильтровать. Ну хвилин-то я не фильтрую, просто подсчитываю. Так это как-то надо по-другому. — Нет, да, ты уверенно сказал. Их heaving занимаются фильтрацией. Ну просто на разных уровнях. Одна до группировки, другая после. У тебя сейчас написано условно дай мне там страны, где два. Вот примерно так. Где два что? Где два больше, чем что-то равно чему-то. А — здесь как будто не хватает условия какого-то. То есть каунт. — Ну вот как разтаки получается про максимум. Количество иков наибольшее. Про максимум — надо с чем-то как бы сравнить его, чтобы отфильтровать. — Да. И — нам ещё, обрати внимание, нужна только одна сторона. — Угу. Да. Так, нам нужно как-то сравнить максимум и сейчас подумаю. Ну, я в принципе же могу. То есть я сейчас я беру, ну, я вывожу имя из объединяю по, ну, получается коду страны. И тут просто как бы отфильтруем количество по языкам. А, ну, допустим, я у меня выведится именно страны и количество языков, которые они используют, да? То есть у меня посчитается для каждого country код, и мне из этого списка нужно будет взять максимальный максимальное число. А я же по сути могу как-то, ну, не условиям, просто что-то как-то я думаю, что можно же, если у нас список и там числа, то я могу просто тоже максимальные взять, но это, наверное, как-то будет некорректно, если прописывать. Мм. А если условиям делать, да? Так, сейчас подумаю. Условием. Ну нет, что-то как-то вижу условием, сравниваясь с чем-то. — То есть у нас есть count language - это же число, да? Типа сколько языков, — по Да, сколько языков для страны. — Вот. Новин предполагает, что мы там либо больше, поменьше, либо равно, чем — А вот ещё можешь уточнить, здесь ты используешь какой тип джойна? Угу. Ну, вообще я использую. Мне нужно было бы, да, перепутала, возможно. Сейчас, секунду, я это ещё раз подумаю. — Ну да. То есть, если хочется объединить две таблицы countries и country languages, надо их сйнить. — Да, сджойнить. — Так, всё, теперь мы объединяем. А — точно ли? — Ну и теперь я не могу использовать, потому что — Да, он после груба идё после группа идёт. — И, допустим, а груба как я могу прописать теперь? Сейчас подумаю. Ну по, ну получается, группировать пох, ну вообще, как будто бы я могу просто тогда зачем мне группировать? Могу напрямую написать. А нет, не могу, наверное. Ну пусть пока будет. Ну, наверное, пока так. Сейчас ещё пому чуть-чуть Кевин. Ну, тут опять нам нужно какое-то условие. Только я тут группирую, получается, по странам. А лучше нею? — Да, ты сейчас группируешь по целой таблице. — Да-дада. Сейчас мне нужно группировать, наверное, по ммд. Хотя я вот здесь же это, ну, то есть я сказала, что у нас первичный ключ для кантри или что там у нас было, да? код - это мы соединяем по, ну, как мы соединяем, то есть тут код, здесь код. Дальше мы группируем. Так, нам удобнее, наверное, будет группировать. Сейчас почему нам, наверное, удобнее как раз-таки по сколько там langж. — Ну нет, группировать всё-таки по нейму удобнее, то есть по названию страны. То есть как бы мы же хотим, у нас есть несколько строчек, то есть там вот USA, США говорят на английском, США говорят на русском. То есть мы понимаем, что две записи должно быть, то есть два языка. А то есть нам где-то нужна функция точно посчитать количество языков. Ну, тут ещё такое правило есть просто как бы визуальное, что то, что мы селектим name, оно должно быть обязательно и в groupй. То есть тут даже тяжело будет в грубай что-то другое запихнуть, кроме как name, потому что у нас не пропустит. То есть мы группировать можем только по тем полям, которые мы лектим. Поэтому грубай сейчас как бы корректный name. — Вот. то нам как бы давай ещё подумаем вот по поводу максимума. Если у нас будет таблица, в которой мы знаем название стран и количество языков, а может ли нам как-то помочь сортировка от большего к меньшему? — Ну да, если мы отсортируем по, получается, ну убыванию, то первый элемент будет наибольший. — Ага. Давай попробуем вот таким образом забрать без, то есть без функции ма. М. Так. Ну, дальше получается мы прогревали по имени. Теперь мы можем вывести, ну, по сути, мы выводим first, наверное, как-то можно обратиться. — А сейчас давай сначала вот отсортируем по количеству языков в стране после группировки. Так, ну, сортировать вроде бы что-то типа сортит. — Нет, сорт нет. Ордер ордер. — Ордер, да, это порядок. — Да. — Вот нам нужно по количеству языков, по количеству, получается, мм, языков, но они у нас не подсчитаны. Сейчас я подумаю, как сортируют. — Намкаунт поможет. — Ну, получается, можем просто записать аккаунт и посчитать, ну, language. — И теперь у нас мы должны вывести первый по случаю, — да? — Спервали. Теперь вывести первый будет здесь. Нет, это можно делать через законные функции, но это было бы очень сложно. Мы можем даже в алхимии, так и называется, для вывода только там первых скольки-то элементов, и она идёт после order byй. Ну вот есть offset, а есть — лимит — второй — лимит — лимит, — да. Вот. А, и давай ещё подумаем. Вот order buy он по умолчанию в базе данных какой? Ну и в алхимии тоже по возрастанию или по убыванию? — Если не ошибаюсь, по возрастанию. — Ага. А нам нужно, — значит, надо по убыванию. Это что-то с вроде бы на D, нет, там такая, — да, на Д. — Операция сейчас. Возможно, дек. Нет. Угу. Так, ну, вроде теперь всё. Сейчас ещё раз. У нас выведится имя изри, где мы объединяем таблицы постро. Какие мы таблицы друг с другом объединяем? Сокращённо как s. И получается в country код и в country language по country code. Сейчас, а, попробуй прочитать подряд третью и начало четвёртой строки. — А из страны, ну, из, получается, таблички стран, вы видите объединение страна. Нет, скорее как не скорее как типа from countries join countries. То есть мы таблицу с собой как будто джойним. У нас уже есть таблица countс, мы из неё выбрали. Нам нужно к ней приджойнить другую таблицу. Сейчас мы джойним саму таблицу стран на саму себя. То есть, а, после джоина, после выражения join должно следовать название другой таблицы. Ну, в нашем случае country languages, чтобы у нас связь прошла не самой таблице с собой. Такой есть, конечно, joint self join, но он не здесь. — Ну, получается, если я напишу from я выложу, — а такой есть синтаксис. Я в нём, конечнорт, но тогда нам joint, скорее всего, не нужен. То есть мы либо присоединяем через joint таблицу, либо вот так через запятую. Но что-то так редко. — Ну тогда если через join сейчас мы — что-то так если не через а через join, то мне нужно где-то вот сейчас объявить country langage. То есть вот так это же не сработает. Я просто думала, что если я обозначу таблицу и — мы её нигде не — сказали, что мы из неё делаем выборку. То есть ты обращаешься к столбцу таблицы, которую мы не джойнили и не фромили. — Я же могу вот здесь допущ запятую. — Скорее нет, чем да. Ээ, я хочу сказать, что после слова join мы должны указать название таблицы country languages, а не countries. — Угу. Он мне предложит сейчас. — Оно не так начинается. Надо е убрать. — А, всё, да, — да. Ну, але, да, уже другой будет, получается. А C у нас теперь нигде не объявлен. Ас, соответственно, будет ошибка. Надо его — где-то тоже либо объявить, либо убрать. Угу. Да. И момент ещё, что нам нужно не просто end написать, а равно такой синтакси, что мы говорим, что код должен равен быть кантрикоду. О'кей. Теперь выглядит аа корректно. Давай попробуем запустить, — да, посмотрим ещё, пройдёт ли. Как будто проходит. По смыслу Южная Африка тоже как будто логично. Давай попробуем отправить. Смотрим, работает ли. Да. О'кей. Э, так. Ну да, я думаю, демонстрацию можно выключить. И давай

### Фидбек по собеседованию [2:10:45]

перейдём к фидбэку. Так, если вспомнить, что было в начале, мы обсуждали авторизацию, про сервисы, у тебя очень любопытный опыт с точки зрения, что ты перепрыгнула какие-то часть базовых тем, каких-то питона, может, немножко алгоритмов, и сразу начала такую более промышленную разработку. Это круто в том плане, что ты быстрее, скорее всего, двигаешься, чем другие люди в плане решения реальных задач. Там знания алгоритма, как там работает хштаблица под капотом, не решают никакие задачи прикладные. Ну, во всяком случае, на базовом уровне Jуниор, а у тебя знания, которые можно тут же взять и применить. Это круто. А, но видно, что по каким-то базовым темам действительно ты отстаёшь. Я понимаю по опыту, что это будет мешать разработке. То есть ты можешь писать, как бы использовать сложные библиотеки, сложные концепции, там тот же GRPC, которые мы не обсуждали, но я верю, что какое-то там базовое понимание тоже есть. Микросервисов есть, а с авторизацией тоже какие-то знания есть, что обычно, что не обычно, да, что обычно люди изучают уже на каком-то там позднем этапе развития, иногда даже на будучи медлами. А я бы точно посоветовал подтянуть базовый Python. Именно не хочу, как на всех совесах говорить асинхронку, многопоточку мультипроцессинг. А потому что с асинхронкой особо мы не обсуждали, но вот понимание, что такое процессы и потоки базовые, я бы подтянул. Лакодинг точно я бы подтянул по Pйthon и по SQL. То есть, несмотря на то, что мы можем писать на SQ алхимии ОРМ запросы, и там это делается красиво, удобно, питанячими структурами, а тем не менее ты не понимаешь, что происходит. Ну не ты, а вот в принципе ты когда так делаешь, конечно, люди так делают, не понимают, что происходит под капотом, какой запрос формируется, насколько он оптимален. И если им показать запрос, они не сразу смогут сказать или с чей-то только помощью, а что в этом запросе нужно поправить. Может быть, там какой-то лишний джоийн, может, там какой-то, и он очень долго работает, и без понимания, как это под капотом работает, будет тяжело. Затем, опять же, по опыту с сырым SQL, с небольшим опытом, я вижу минус в том, что на работе будет тяжелее, потому что одно дело, когда мы там разрабатываем какой-то для себя локально там сервис и с ним всё хорошо, на работе очень часто у нас очень много таблиц в базе данных. Мы разрабатываем, у нас есть прямой доступ там к разработческой базе, можем её ломать, чинить, как хотим. И очень часто, очень часто приходится залезать в какой-нибудь adдми, дебивер, datagрип, ну, смотря, что удобнее для работы с позгрый, и смотреть, что там за данные, то естьделать базовые селект запросы, иногда joint запросы, иногда сортировку, иногда какие-то фильтры, потому что это просто быстрее, чем те же самая операции через питон писать и как-то через алхимию прогонять для дебага. То есть в плане быстрого решения каких-то задач на работе сырой SQL очень ценен и очень полезен, потому что разработчики прямо привязаны к базе, прямо вот железно. Без неё невозможно практически разрабатывать никакой бэкэнд. Всегда мы где-то храним данные. А в плане питона, конечно, я понимаю, что можно теряться, тем более это первое собеседование, в принципе, в жизни. Тут каких-то типа неожиданности нет для меня. Но я бы посоветовал потренироваться, писать просто какие-нибудь простенькие функции. Вот находить простенькие сдачи на том же Соловите или на других сайтах задачи собеседований на Python. Например, вот развернуть словарик, написать функцию для сортировки списка, чтобы он случайно сортировался без использования встроенных функций в Python в таком ключе. Потому что мы часто уходим в какие-то на первый взгляд как бы более сложные концепции, микросервисы, архитектура систем, архитектура Python приложений, но, в общем, так получается, что невозможно с ними нормально работать, пока не закрыт вот этот фундамент. И опять же от собеседования к собеседованию они отличаются. И где-то может повести и будет диалог только про бкэнд, про микросервисы, про авторизацию, там и у команды такой же стек, как у тебя, и там будет ч и ты пройдёшь. Но точно стоит понимать, что лайфкодинг встречается в половине собеседования, опять же, по моему немаленькому опыту, поэтому к нему точно нужно быть готовой. и базовый Python, типа какие там есть типы данных, э, чем они отличаются, какие изменяемые, неизменяемые, асинхронка, декораторы, ООП, генераторы, итераторы. Это всё всегда спрашивается, но в целом по там базовым тем ООП декоратор, что мы обсудили, а нет, я вспомнил, да, вот по Property Class metthod, Static Method всё-таки был звоночек, что стоит немножко туда углубиться, потому что это тот код, эти те декораторы, если конкретно говорить, которые часто используются на работе другими разработчиками. И даже как бы, если ты их не используешь, очень важно, когда в команде работаешь, уметь читать, читать чужой ход, чужой код и ревью его в том числе. Если говорить про чужого кода, про гит, а здесь тоже, а, как бы так всё выстроено, что ты не можешь собрать команду у себя там локально перед первой работой и научиться работать в команде, то нужно хотя бы в теории понимать, что такое gitflow, какие есть ветки. как происходит процесс доставки какой-то фичи к конечному пользователю, какие этапы тестирования, как ручного, так и автоматизированного, так и CCD проходит. А без этого тяжело уже, как бы требования выросли, тяжело попасть будет в компанию, но особенно большую. Вот. А если говорить про грейд, наверное, как мне кажется, многим это важно, как бы какого грейда они, я бы сказал, что для какого-то стартапа, где нужно что-то быстро разрабатывать, это уже джун, потому что ты можешь работать, решать задачки, особенно если ты, что я не уточнял, кстати, используешь нейронки и они могут Ты, кстати, используешь нейронки какие-то? Ну, я так смешана с какими-то статьями, документацией, нейронки, всё вместе использую. — Ну, это хорошо, как бы, что ты не отрицаешь их пользу. Э, то есть можно работать, но если говорить про, ну, как бы таких компаний меньше, и я бы сказал, что до работы уже непосредственно в компании, там, не знаю, полную неделю, как бы, на полной ставке дженом пока, наверное, рано. А точно есть от меня респект, что ты не остановилась на какой-то базе, потому что такое бывает, что люди надолго задерживаются на базе питона, читают там книги про асинхронность отдельные, хотя на первых этапах это не нужно, на мой взгляд. Это классно. Ээ но всё-таки стоит чуть-чуть вернуться, там сделать шаг назад, чтобы потом сделать два вперёд и закрыть фундамент. Вот, наверное, с моей стороны такой фидбэк. Вот что, какие у тебя вообще ощущения, эмоции от первого собеседования? Ну, — очень волнительно, прям безумно, как будто сразу всё вылетает из головы. — Вот и всё просто вот пустой лист, ничего нету, какие-то вот такие моменты. Но при этом это, ну, как я повторялась, моё первое собеседование, в принципе, такое - — Угу. — Очень было интересно получить такой опыт, потому что, ну, как открыть для себя, это часто страшно сделать первый шаг. И все многие, наверное, застаиваются на том, что, ну, вот я изучу ещё, изучу ещё. Вот. Хотя уже можно начать пробовать себя именно в каком-то реальном деле. Вот поэтому для меня это такое небольшое открытие. Да, спасибо, что ты не побоялась, заполнила анкету. Кстати, если кто не знал, да, вот я отбирал людей в Telegram-канале по анкете было где-то 350 заявок и 10 человек я отобрал. Вот среди них Эвелина. Ну я ещё, я думаю, это хороший, это более плавный старт, чем сразу э-э на реальное собеседование попадать, где, мне кажется ещё более страшнее, потому что там на кону офер, на кону какое-то классное престижное место, а тут на кону, ну не пройду, не пройду, ладно. А ну это не умоляет того, что действительно это стрессово, я это понимаю. А большое спасибо, что согласилась, Эвелина. Мне понравилось с тобой общаться. Желаю тебе всяческих успехов. — Спасибо. Спасибо, Артём, что позвали. Было очень приятно. — Да, всё, давай, пока. — Итак, друзья, вот и завершилось собеседование Эвелины. Напишите в комментариях, что думаете, справедлива ли моя оценка, какая у вас оценка знаний Эвелины. Интересно будет почитать, посмотреть. И, конечно, поддержите её комментариями и это видео лайками, чтобы ещё больше подобных собеседований вышло на этом канале. Друзья, напоминаю, что шпаргалка со всеми вопросами и задачами в описании можно бесплатно скачать. И это видео вышло благодаря поддержке онлайн-школы для Python разработчиков Pyth Python ээнд-разработчиком. Все ссылочки в описании. Повторяться не буду. И, друзья, желаю вам успехов подготовке к собеседованиям и прохождении самих собеседований. Увидимся. Пока.