Короче продолжение истории с FB: я осилил их онсайт к своему удивлению, задачи были уровня medium/hard leetcode, не самые простые прямо скажем
Когда первую задачу увидел думал ну все, хрен я это вспомню.. Но немного погодя мне это удалось и я смог осилить. Во время стресса организм может активизировать мозг круто.

Было всего 4 задачи + дизайн + поведенческих немного
Дизайн (instagram) выложил практически все как по брошюрке Grokking the system design + добавил чутка, что увидел на видосах в youtube.

НО..
как всегда есть свои бл*тские НО...

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

Сказали, что готовы предложить follow up, повторная телефонка

и тут я про*бался :(

задачи на follow up были простые, но я реально не помнил одну из техник и, таким образом, первую решил не очень эффективно (хотя и решил), вторая была не до конца дописана, был только скелет, но кончилось время... подглядеть была возможность, но решение в моих подсказках было прям скажем не супер.. да и 40 минут на две задачи пусть и easy, это надо решение с ходу рисовать без раздумий и долгих подглядываний

В общем я упустил пока свой шанс, парни...

----------

Еще думаю пол года тренировок и все можно сделать!

Спасибо! Это я уже взял на заметку, может еще что есть интересного :)

недавно очень впечатлился статьей человека в похожей ситуации

Дизайн-интервью. Это отдельный зверь, не очень страшный, но специфический. Здесь тебе дают очень общие начальные условия типа «Нужно построить Dropbox» и смотрят, как ты продираешься через терновые кусты неопределенности. Какие вопросы ты задаешь, как анализируешь проблему.

Мои выводы по этому типу интервью:

Первым делом нужно собрать требования. Очень четкие и конкретные требования, которым должна отвечать система. Типовые вопросы, которые можно задать: how many users, active users, time zones (one or few). Acceptance criteria — network bandwidth (in-going/ out-going traffic), RAM, storage, latency, battery life (for mobile) etc.
Представь, что интервьюер — это твой заказчик (или пользователь), для которого строится система. Что ему нужно? А что можно предложить сверх этого (сбор статистики, админпанель)?
Какие будут пользователи у этой системы? Часто их несколько — general users и administrators. И требования для них могут быть кардинально разные. Понимая это, нужно собрать все use cases. Один use case будет отвечать одному методу в API.
Определяем три ключевых элемента — UI (если таковой имеется), API, DB schema. Часто, рисуя UI, можно найти новые use cases и обговорить их.
Оценить все, что только можно, — number of users, requests (queries) per second (QPS), latency, API latency, disk space you need (for 5 years for instance), cache space, in-going/out-going traffic.
Отдельно оценить read-write ratio. Наша система read heavy или write heavy? В зависимости от этого, как мы будем писать и читать данные?
Как будет организовано хранилище данных, кеширование? Возможно, нужна очередь для обработки дорогостоящих операций? Как будут организованы replicas и shards (нужно хорошо понимать различие между этими понятиями)?
Для упрощения понимания сначала можно построить систему для 100 пользователей. После того как интервьюер согласится с таким дизайном, можно подумать, как будем его масштабировать до тысяч и миллионов пользователей.
Найти trade-offs и обсудить их. К примеру, это может быть trade-off между consistency и speed. Что важнее в данном контексте? Как этого добиться?
Когда мы рисуем диаграммы, ни один блок не должен быть в единичном экземпляре, это всегда сет из многих. При падении одного узла его тут же должен заменить его клон. Нужно продумать, какие могут быть аварийные ситуации и как мы будем с ним бороться.
И самое главное — внимательно слушать интервьюера и никогда-никогда с ним не спорить. Это кажется очевидным, но многие (и я среди них) об этом забывают.