No video :(

Mock-собеседование по System Design от Team Lead из Ozon

Подписаться 3,4 тыс.

Просмотров 5 тыс.

50% 1

Потренироваться проходить собеседования: clck.ru/3ASssc
Курсы по программированию: clck.ru/3ASt6y
Mock-собеседование от Team Lead из Ozon секции по языку Golang на платформе it-interview.io. Потренируйтесь и вы проходить собеседования с разработчиками из ведущих компаний и получите подробный отзыв о том, на какую зарплату и грейд вы можете расчитывать, или над чем вам еще стоит поработать!
Telegram канал Олега: t.me/oo_ilin
RU-vid канал Олега: / @oo_ilin
Таймкоды:
00:00 Знакомство
03:31 Начинаем проектировать URL Shortner
04:02 Сбор функциональных требований
07:53 Сбор нефункциональных требований
12:56 Схема данных и рассчет объема базы
22:42 Рассчет RPS
23:53 Рассчет пропускной способности
26:30 Высокоуровневая схема
30:45 База данных
32:28 Шардирование базы данных
37:14 API
39:09 Шардирование продолжение
41:45 Добавляем кэш
45:03 Уникальность ключей на шардах
48:13 Внешний сервис для генерации ссылок
53:13 Соединяем потоки
53:56 Поток создания
58:24 Добавляем аналитику
1:00:25 Добавляем RateLimiter
1:04:16 Возвращаемся к аналитике
1:05:13 Обсуждаем точки отказа
1:09:06 Обсуждаем идемпотентность
1:14:12 Обратная связь от Олега
1:18:10 Обратная связь от Саши
[[ Отзыв о кандидате ]]
Александр во время собеседования показал себя хорошо. Показал себя как специалист способный анализировать предметную область и способный подстраиваться под новые требования. В качестве системы для проектирования был выбран URL Shortnet (сокращатель ссылок). Кандидат собрал все требования, реализовал верхнеуровневый дизайн и постепенно углубился до компонентов. Из плюсов еще могу отметить что разделил трафик на чтение и на запись и проработал оба потока данных. Проработал систему хранения, масштабирования и отказоустойчивости.
В ходе интерью из за того что сразу не спроектировал API ошибся с выбором ключа для шардирования данных. Но после того как спроектировал две API ручки быстро сообразил в какую сторону необходимо смотреть. Так же не до конца раскрыл как именно будет генерироваться уникальная ссылка. Не определились со словарем и полным алгоритмом.
По коммуникациям приятный в общении, рассудительный. Все предположения обосновывает и рассуждает в слух, что дает понять в какую сторону движется.
Из рекомендаций можно посоветовать следить за таймингом, чаще просматривать первоначальный требования и не повторяться на тех моментах, которые уже были овучены ранее.
Валерий Бабушкин. System Design. Карьера в IT. Karpov courses. Яндекс алгоритмы.
#собеседование #mockсобеседование

Опубликовано:

16 авг 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 16

@instl1117 9 дней назад

Крутое интервью, много интересных моментов, мне кажется «кандидат» отлично справился

@leonkonig5131 17 часов назад

Очень крутой кандидат, кроме самого системного дизайна явно где то учился грамотно говорить и отвечать, действует как психолог -архитектор

@dmitryzolotarev1532 Месяц назад

Сколько смотрю собесы по сисдизу, еще ни один человек в тайминг 50 минут не уложился, даже если мок-интервью внутри одной компании. И по rps постоянно невнятки. Кто говорит DAU, кто DAU/86400. Мало кто задает вопрос про распределение внутри дня. Я так и не понял, как правильно.

@Magomedrasul7 3 месяца назад

Что если упадет хранилище заготовленных ссылок 200кк ? Если это inMemory хранилище, то при рестарте оно восполнится снова этими же заготовками или же будут новые заготовки ? 🤔

@noone7796 3 месяца назад

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

@oo_ilin 3 месяца назад

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

@kozhurkin Месяц назад

неверно же посчитал пропускную способность 40 wRps x 300 байт = 12,000 байт/сек = 0.094 Мбит/сек

@noone7796 3 месяца назад

26 букв, + верхний регистр + числа в 8 символах это 62^8 возможных уникальных значений. разве вероятность коллизии высокая?

@oo_ilin 3 месяца назад

В вашем варианте словарь хороший и коллизий в принципе нет если генерировать ключ последовательно. Речь шла о другом. Что если взять какой-нибудь алгоритм хеширования, например MD5, то у него длина 32 символа, а сами символы это всего лишь шестнадцатиричная система: 0-9A-F. Так как наша задача сделать короткую ссылку, то если мы от md5 отрежим 8 символов, то будет очень высокая вероятность коллизии. Ну и в интервью я подталкивал Сашу на то что 8 символов это очень большое число уникальных значений и ключ можно сократить до 6 или 7 символов.

@aleksandr_t 2 месяца назад

@@oo_ilinКажется для того, чтобы ответить на этот вопрос, стоило понять какие конкретно символы у нас есть (алфавит), допустим если алфавит 72 (26 uppercase/lowercase, 10 цифр и 10 спец символов), то нам нужно как раз таки 6 символов (log72(10^10), 10^10 - потому что у меня получилось 12 * 10^9 ссылок за 10 лет, что примерно равно 10^10). Ну и блочный CRC как раз таки идеально подходит под эту задачу. Вообще задача хоть и тривиальная на первый взгляд, но может проверить глубокие знания и даже умение считать

@feolius Месяц назад

Если честно, то не совсем понятно, чем так плоха хэш функция для обеспечения уникальности ссылки в шардах. Допустим у нас N шардов, и есть хэш функция, которая на любую шорт ссылку возвращает число от 0 до N - 1, т.о. определяя индекс шарда. На POST запросе мы рандомно генерим ссылку, считаем от нее хэш. Идем в нужный шард и проверяем занята ли ссылка. Кажется, что при такой длине шорт ссылки (8 символов) вероятность коллизий крайне мала (62^8 возможных вариантов). Если все же сгенерили случайно уже используемую ссылку, штош, придется еще раз сгенерить, пока не сгенерим свободную. Таким видится алгоритм. Возможно я что-то упускаю или неправильно понял проблему.