[Карьера в IT-индустрии] Как я научился проходить архитектурные секции
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Архитектурные секции у многих вызывают чувство неопределенности и тревоги: формулировки не изобилуют деталями, как проверить ответ — непонятно. При этом способность пройти архитектурную секцию отличает вчерашнего выпускника от человека, которому можно доверить строить нечто большее, чем обход бинарных деревьев. В определенный момент я решил как следует подготовиться секции по дизайну, потратил на это около пары недель и выработал системный подход, которым хочу с вами поделиться.
План
Очень важно его иметь. Даже если вы где-то ошибетесь и свернете не туда в своих рассуждениях, общая структурированность подхода сыграет вам на руку. В самом начале можно умеренно тупить и расспрашивать собеседующего о подробностях, но начиная с некоторого момента (который в моем плане ниже соответствует пункту 3) инициатива должна быть полностью у вас и лучшее ее не отпускать до самого конца. Мой план был примерно таким:
1. Собрать список ключевых фич и выписать их в углу доски. Этот простой трюк поможет вам не забыть важное ограничение или допущение.
2. Понять, какими техническими характеристиками должна обладать система: ожидаемый RPS, диапазон допустимых времен ответа, ожидания в плане консистентности и надежности.
3. Собрать простейшее решение, рассчитанное на одну машину, которое будет хоть как-то работать. Начинать с 20 датацентров по всему миру не нужно, гораздо лучше к этому постепенно прийти.
4. Найти единую точку отказа или узкое место в плане производительности.
5. Предложить один или больше вариантов решения проблемы, внятно объяснить плюсы и минусы каждого из них
6. Выбрать один из вариантов и перейти к пункту 4, если время еще есть, а если оно заканчивается — перейти к следующему пункту
7. Прикинуть размеры стораджей, количество серверов, пропускную способность сети, аккуратно это все выписать
8. Бонус: поговорить про дополнительные фичи, внедрение ML, метрики продукта, эксперименты
Очень важно контролировать время. Я старался минут 5-10 тратить на два первых пункта и минут 5 на два последних.
Трейдофы
Их нужно проговаривать, даже если они кажутся очевидными. После внедрения любой новой детали важно сказать что-нибудь в духе «мы добавили новый элемент, это решит такую-то проблему, но за это мы заплатим тем-то». Трейдофы могут быть какими-то например такими:
1. Любые новые компоненты системы или рост количества уже существующих запчастей решают проблему нагрузки/скорости ответа, но добавляют головной боли с поддержкой и деплоем.
2. Шардирование решает проблему нагрузки и нехватки места, но добавляет проблем с перешардированием в будущем.
3. Реплицированное хранилище решает проблему нагрузки и надежности, но в случае наличия read и write реплик заставляет думать о протухших значениях и противостоянии доступности и консистентности
4. Кэш решает проблему с нагрузкой, но заставляет думать о протухших значениях и cache coherency.
5. Собственное решение можно легко менять и оптимизировать для своих нужд, но его придется сперва написать.
6. Существующее решение хорошо тем, что оно уже существующее, но в нем придется разбираться.
Числа
Все знают про latency numbers every programmer should know, но числа по ссылке на мой взгляд структурированы не самым удобным образом и я их в процессе подготовки переформатировал для удобства запоминания.
В конечном итоге важно следующее:
1. Знать временные расходы на чтение данных из разного уровня процессорных кэшей, памяти, SSD, HDD и сети.
2. Помнить время round trip'ов внутри датацентра и вокруг земного шара, а также минимальную задержку, которую человек ощущает как лаг (~100ms).
3. Уметь быстро конвертировать байты в гигабайты, наносекунды в секунды и т.д., этот скилл у меня выработался сам собой в процессе практики.
Практика
Я купил маркерную доску, брал уже существующие сервисы и пытался придумать, как бы я их сделал с нуля. Рисовал на доске схемы, прикидывал нагрузку и необходимые ресурсы, искал в своем дизайне слабые места. Еще у меня есть классные друзья, с которыми мы устраивали псевдосекции и тренировались друг на друге — это был суперполезный опыт. После практики можно лезть в интернет и искать, как это на самом деле сделано, а потом пробовать еще раз. После 10-20 раундов с разными сервисами наступает просветление и отдельные повторяющиеся запчасти в существующих системах начинают быть отчетливо видны. Запчасти могут быть например такими:
1. Поиск (желательно с возможностью в реальном времени обновлять индекс)
2. Файловое хранилище (gfs, haystack)
3. Распределенное kv-хранилище (cassandra, dynamo)
4. Message queue и pub-sub системы в целом (kafka)
4. Лента новостей (twitter, instagram, facebook)
5. Чат, мессенджер, сервер для онлайн-игры (whatsapp, telegram, battle.net)
6. Стриминг, видео и аудио-чат (skype, twitch, youtube)
Ресурсы
1. Grokking the system design interview. Не все решения оттуда оптимальны, некоторые откровенно слабы, но материал хорошо структурирован и служит неплохой стартовой точкой.
2. System design primer. По этой ссылке много полезного материала, но в нем легко запутаться.
3. Видео с конференций на тему как это устроено (тысячи их). После пары десятков видосов начинаешь видеть слабые места решений из первых двух пунктов. Реальные системы иногда устроены проще, чем их дизайнят в обучающих материалах, а иногда наоборот.
4. Cайт High Scalability
5. Ну и самый важный ресурс — это ваши друзья и знакомые, которые знают, как устроены их системы и могут вам про них рассказать.
Несколько хороших видео и каналов
1. Scalability
2. Intro to Architecture and Systems Design Interviews
3. Four Distributed Systems Architectural Patterns
4. Dropbox в 2012
5. Slack
6. Twitter
7. Reddit
8. Instagram
9. Youtube в 2007
10. Канал про System Design от соотечественника
11. Еще канал
12. И еще канал
Если жестких временных рамок у вас нет, но перспектива собеседования уже маячит на горизонте, самой правильной тактикой будет постоянно в фоне что-то читать/смотреть на тему устройства больших систем. С алгоритмическими задачками то же самое: лучше их периодически решать и быть всегда в тонусе, чем на выходных перед интервью пытаться осилить весь литкод. Тем не менее, интенсивная подготовка к архитектурной секции за короткий срок сделала меня значительно более лучшим специалистом.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка веб-сайтов, Разработка мобильных приложений, Разработка под Android, Карьера в IT-индустрии, Разработка под Windows] Нужен ли еще один сервис (opensource)? (в конце опрос)
- [Высокая производительность, Программирование, Go] Чистая архитектура с Go
- [Управление разработкой, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Создание программного продукта и управление его развитием. Позиционирование продукта
- [Управление разработкой, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Создание программного продукта и управление его развитием. От реализации идей — к проверке гипотез
- [Учебный процесс в IT, Карьера в IT-индустрии] В США стартапы начали набирать студентов, которые оказались на карантине из-за пандемии
- [Управление персоналом, Карьера в IT-индустрии] Бесплатные образовательные курсы: бэкенд-разработка
- [Управление персоналом, Карьера в IT-индустрии, Лайфхаки для гиков, Удалённая работа] Что кроется за “проактивностью” в ИТ-вакансиях?
- [IT-эмиграция, Карьера в IT-индустрии, Интервью, IT-компании] [Личный опыт] Amazon vs Microsoft: чем отличается процесс собеседований в крупных ИТ-компаниях
- [Карьера в IT-индустрии] В какую сторону течёт вода?
- [Учебный процесс в IT, Образование за рубежом, Карьера в IT-индустрии] Google говорит, университеты больше не нужны (перевод)
Теги для поиска: #_karera_v_itindustrii (Карьера в IT-индустрии), #_sobesedovanie (собеседование), #_sobesedovanija (собеседования), #_arhitektura (архитектура), #_karera_v_itindustrii (
Карьера в IT-индустрии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 02:01
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Архитектурные секции у многих вызывают чувство неопределенности и тревоги: формулировки не изобилуют деталями, как проверить ответ — непонятно. При этом способность пройти архитектурную секцию отличает вчерашнего выпускника от человека, которому можно доверить строить нечто большее, чем обход бинарных деревьев. В определенный момент я решил как следует подготовиться секции по дизайну, потратил на это около пары недель и выработал системный подход, которым хочу с вами поделиться. План Очень важно его иметь. Даже если вы где-то ошибетесь и свернете не туда в своих рассуждениях, общая структурированность подхода сыграет вам на руку. В самом начале можно умеренно тупить и расспрашивать собеседующего о подробностях, но начиная с некоторого момента (который в моем плане ниже соответствует пункту 3) инициатива должна быть полностью у вас и лучшее ее не отпускать до самого конца. Мой план был примерно таким: 1. Собрать список ключевых фич и выписать их в углу доски. Этот простой трюк поможет вам не забыть важное ограничение или допущение. 2. Понять, какими техническими характеристиками должна обладать система: ожидаемый RPS, диапазон допустимых времен ответа, ожидания в плане консистентности и надежности. 3. Собрать простейшее решение, рассчитанное на одну машину, которое будет хоть как-то работать. Начинать с 20 датацентров по всему миру не нужно, гораздо лучше к этому постепенно прийти. 4. Найти единую точку отказа или узкое место в плане производительности. 5. Предложить один или больше вариантов решения проблемы, внятно объяснить плюсы и минусы каждого из них 6. Выбрать один из вариантов и перейти к пункту 4, если время еще есть, а если оно заканчивается — перейти к следующему пункту 7. Прикинуть размеры стораджей, количество серверов, пропускную способность сети, аккуратно это все выписать 8. Бонус: поговорить про дополнительные фичи, внедрение ML, метрики продукта, эксперименты Очень важно контролировать время. Я старался минут 5-10 тратить на два первых пункта и минут 5 на два последних. Трейдофы Их нужно проговаривать, даже если они кажутся очевидными. После внедрения любой новой детали важно сказать что-нибудь в духе «мы добавили новый элемент, это решит такую-то проблему, но за это мы заплатим тем-то». Трейдофы могут быть какими-то например такими: 1. Любые новые компоненты системы или рост количества уже существующих запчастей решают проблему нагрузки/скорости ответа, но добавляют головной боли с поддержкой и деплоем. 2. Шардирование решает проблему нагрузки и нехватки места, но добавляет проблем с перешардированием в будущем. 3. Реплицированное хранилище решает проблему нагрузки и надежности, но в случае наличия read и write реплик заставляет думать о протухших значениях и противостоянии доступности и консистентности 4. Кэш решает проблему с нагрузкой, но заставляет думать о протухших значениях и cache coherency. 5. Собственное решение можно легко менять и оптимизировать для своих нужд, но его придется сперва написать. 6. Существующее решение хорошо тем, что оно уже существующее, но в нем придется разбираться. Числа Все знают про latency numbers every programmer should know, но числа по ссылке на мой взгляд структурированы не самым удобным образом и я их в процессе подготовки переформатировал для удобства запоминания. В конечном итоге важно следующее: 1. Знать временные расходы на чтение данных из разного уровня процессорных кэшей, памяти, SSD, HDD и сети. 2. Помнить время round trip'ов внутри датацентра и вокруг земного шара, а также минимальную задержку, которую человек ощущает как лаг (~100ms). 3. Уметь быстро конвертировать байты в гигабайты, наносекунды в секунды и т.д., этот скилл у меня выработался сам собой в процессе практики. Практика Я купил маркерную доску, брал уже существующие сервисы и пытался придумать, как бы я их сделал с нуля. Рисовал на доске схемы, прикидывал нагрузку и необходимые ресурсы, искал в своем дизайне слабые места. Еще у меня есть классные друзья, с которыми мы устраивали псевдосекции и тренировались друг на друге — это был суперполезный опыт. После практики можно лезть в интернет и искать, как это на самом деле сделано, а потом пробовать еще раз. После 10-20 раундов с разными сервисами наступает просветление и отдельные повторяющиеся запчасти в существующих системах начинают быть отчетливо видны. Запчасти могут быть например такими: 1. Поиск (желательно с возможностью в реальном времени обновлять индекс) 2. Файловое хранилище (gfs, haystack) 3. Распределенное kv-хранилище (cassandra, dynamo) 4. Message queue и pub-sub системы в целом (kafka) 4. Лента новостей (twitter, instagram, facebook) 5. Чат, мессенджер, сервер для онлайн-игры (whatsapp, telegram, battle.net) 6. Стриминг, видео и аудио-чат (skype, twitch, youtube) Ресурсы 1. Grokking the system design interview. Не все решения оттуда оптимальны, некоторые откровенно слабы, но материал хорошо структурирован и служит неплохой стартовой точкой. 2. System design primer. По этой ссылке много полезного материала, но в нем легко запутаться. 3. Видео с конференций на тему как это устроено (тысячи их). После пары десятков видосов начинаешь видеть слабые места решений из первых двух пунктов. Реальные системы иногда устроены проще, чем их дизайнят в обучающих материалах, а иногда наоборот. 4. Cайт High Scalability 5. Ну и самый важный ресурс — это ваши друзья и знакомые, которые знают, как устроены их системы и могут вам про них рассказать. Несколько хороших видео и каналов 1. Scalability 2. Intro to Architecture and Systems Design Interviews 3. Four Distributed Systems Architectural Patterns 4. Dropbox в 2012 5. Slack 6. Twitter 7. Reddit 8. Instagram 9. Youtube в 2007 10. Канал про System Design от соотечественника 11. Еще канал 12. И еще канал Если жестких временных рамок у вас нет, но перспектива собеседования уже маячит на горизонте, самой правильной тактикой будет постоянно в фоне что-то читать/смотреть на тему устройства больших систем. С алгоритмическими задачками то же самое: лучше их периодически решать и быть всегда в тонусе, чем на выходных перед интервью пытаться осилить весь литкод. Тем не менее, интенсивная подготовка к архитектурной секции за короткий срок сделала меня значительно более лучшим специалистом. =========== Источник: habr.com =========== Похожие новости:
Карьера в IT-индустрии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 02:01
Часовой пояс: UTC + 5