Comments 19
Я правильно понимаю, что это перевод книги System Design Interview – An insider's guide, Second Edition (by Alex Xu)? https://www.amazon.com/System-Design-Interview-insiders-Second/dp/B08CMF2CQF/
Если для студентов, то наверное очень даже неплохо, а вот для интервью не уверен. Так поисковые роботы работали в прошлом веке.
Вот да, это уровень дизайна для джуниора. При этом вообще не понятно, зачем у джуна спрашивать системный дизайн.
Но судя и по другим отрывкам из книги, использовать советы оттуда для реального проектирования категорически не рекомендуется. Полезны ли эти советы для интервью - не знаю, у меня бы разработчик с такими ответами интервью не прошел бы.
Из интереса - а что именно не так в современном подходе? Что следует добавить/поменять, чтобы пройти условно ваше интервью?
А что вы посоветуете?
Друзья, подскажите мб в комментах, что тогда можно почитать по теме? Или мб есть ссылки на посты с подборками книг на тему
Сам не читал ещё, но часто советуют (например, тут https://github.com/Tinkoff/career/blob/main/interview.md#книги-2) "Высоконагруженные приложения. Программирование, масштабирование, поддержка" Клеппман М.
Мне было интересно с точки зрения восприятия целостной картины. На других ресурсах, конечно, можно смотреть:
Более детальные разборы
Более правильные шаблоны
Более правильные применения
И это уже будут детали.
Думаю, что для общего впечатления пойдёт. И общее впечатление передаётся, по ощущением, нормально. Не уводит в сторону чем-то плохим(изложением, применением шаблонов).
Если принять мнение, что шаблоны не очень, тогда => вообще не воспринимать эту статью, книгу, подходы? Нет. Я воспринимаю, т.к. считаю, что там изложены принципы.
Рассказано про подход из 4 стадий по созданию системы. В книге каждая из предложенных систем строится в процессе прохождения по таким стадиям. Рассказано про формат общения. Про возможные вопросы. Про построение сначала общей картины.
Это вполне резонно. Вполне укладывается в моё понимание возможного интервью. Вполне могут быть полезны такие подходы.
В общем, мне понравился стиль изложения. Самое плохое, что может случиться - это если супер углубиться в такой подход и воспроизводить по этим лекалам на настоящем интервью, а окажется, что оно идёт вообще не так. Что шаблоны вообще не такие. Тогда можно просто не пройти эту секцию, получить(этим самым, как минимум) обратную связь. И далее корректировать или отказаться от такого опыта вообще(и это тоже опыт).
А для вливания в эту тему вполне годный материал. Тем более, особо конкурирующих книг я не видел. Автор, по описанию, вполне опытный инженер. Так что пустого говорить не должен. Что-то, как минимум, должно быть релевантно.
То есть, худшее, что может случиться - потратить время в пустую. И то такого быть не может. Так как никто, как считаю, не даст универсального рецепта. Вот так, самообразованием, что-то пробуя и можно наработать знание, навык.
И если это не совсем то => всегда можно скорректировать. В любом случае, есть много материала. И для подготовки надо изучить много и с разных углов.
Хорошо, что книга позволяет понять, что такая подготовка и успешное прохождение интервью возможны. Возможно понять такую не простую тему. Не привычную для разработчика.
Книга своим понятным изложением воодушевляет. А это тоже много значит.
А что, такие вопросы реально задают при трудоустройстве НЕ в гугло/яндекс?
Даже на самом первом шаге непонятно что сказать - из чего паук сделан, если что-то примитивное навроде jsoup то он 70% страниц не отпарсит, а если в духе selenium + chromium это космические затраты машинного времени (не думаю, что гугл на этом сделан).
Плюс на каждом шаге куча крутых технических решений, взять ту же дедупликацию. В лоб она слишком дорогая даже на мизерных объемах, явно что-то гениальное придумали )
Зачем тогда такое спрашивать у обычных кодеров?
А почему только pdf? На телефонах его читать неудобно. Если текст уже набран, почему не отформатировать его в каком-нибудь текстовом формате?
Была бы у вас возможность отправлять книги за границу, цены бы не было. Я часто покупаю у вас электронные книги но мне удобнее живую книжку читать.
нигде не смог увидеть автора книги. Что здесь на хабре, что на сайте издательства автор не указан, а на изображении книги плохо видно
Здесь (https://www.amazon.de/dp/B08CMF2CQF?tag=gregdoesit03-21&keywords=system design interview&geniuslink=true) автор виден хорошо.
Интересно, когда уже наши издательства найдут нормального корректора? Не такая большая книжка, прочитал треть, нашел три смысловые опечатки.
Чтобы не быть голословным: стр. 108.
Клиент записывает в систему элемент данных D1, и запись обра- батывается сервером Sx, у которого теперь есть векторные часы D1[(Sx, 1)].
ДругойклиентсчитываетпоследнююверсиюD1,обновляетеедо D2 и записывает обратно. D2 происходит от элемента D1 и поэтому записывается вместо него. Предполагается, что запись обрабатыва- ется тем же сервером Sx, векторные часы которого теперь выглядят как D2([Sx, 2]).
ЕщеодинклиентсчитываетпоследнююверсиюD2,обновляетеедо D3 и записывает обратно. Предполагается, что запись обрабатыва- ется тем же сервером Sy, векторные часы которого теперь выглядят как D3([Sx, 2], [Sy, 1])).
"Тот же" сервер Sy первый раз упоминается в списке. И таких примеров несколько.
Следующая страница 109-110:
Если номер версии каждого члена векторных часов Y больше или равен номерам версий в X, это означает, что X является наследником Y и, сле- довательно, эти версии не конфликтуют. Например, векторные часы D([s0, 1], [s1, 1])] являются предшественником D([s0, 1], [s1, 2]), поэтому конфликт не записывается.
Здесь перепутаны понятия "наследник" и "предшественник".
Latency даже гугл переводит как "задержка", а не "латентность". (Хотя, справедливости ради, такой термин всё-таки встречается в Википедии.)
Книга «System Design. Подготовка к сложному интервью»