Як відповісти на питання інтерв'ю проектування системи англійською мовою
Структуруйте своє інтерв’ ю щодо проектування системи англійською мовою: роз’ яснення вимог, запропонування архітектури, обговорення компромісів і масштабування. Включено практичні фрази.
Інтерв’ ю з системним проектуванням тестують вашу здатність до архітектури великих програмних систем — і вашу здатність чітко висловлювати свої думки англійською мовою. Багато технічно сильних інженерів не досягають успіху в інтерв’ю з системним дизайном не тому, що їх знання відсутні, а тому, що вони занурюються в рішення без структури, не можуть задати прояснюючі питання або не можуть сформулювати компроміси таким чином, щоб інтерв’юер міг оцінити. Цей підручник надає вам мову і структуру для успішного виконання.
П’ять етапів проектування системи інтерв’ю
Кожне інтерв’ю з розробником системи йде за подібною схемою:
- Прояснити вимоги
- Оцінка масштабу
- Запропонувати архітектуру високого рівня
- Глибоко зануритися в компоненти
- Обговоріть компроміси і масштабування
Опросники хотят увидеть, что вы следуете этой структуре естественно, а не что вы запоминаете ответы. Використовуйте фрази, щоб вказати, в якій фазі ви перебуваєте.
Фаза 1: Прояснення вимог
** Ніколи не починайте проектування, не встановивши, що саме ви створюєте. Перехід прямо до архітектури свідчить про погані інженерні інстинкти. Запитайте конкретні питання протягом 3-5 хвилин.
Вступ:
- “Перед тим, як я почну проектування, я б хотів задати декілька питань, щоб переконатися, що я розумію сферу застосування.” *
** Функціональні вимоги: **
“Чи має система підтримувати сповіщення у реальному часі, чи є прийнятною послідовність?”
- “Ми розробляємо шлях читання, шлях запису, або обидва?” *
- « Чи мають користувачі мати змогу редагувати або вилучати повідомлення, чи це лише додавання? » *
** Нефункціональні вимоги: **
“Який масштаб ми плануємо? Приблизно скільки користувачів, і який очікуваний коефіцієнт читання-запису?»
- “Які вимоги до затримки? Чи потрібний час відповіді менше 100 мс, чи прийнятно кілька секунд?»*
- “Наскільки важлива довговічність даних? Чи можемо ми терпіти втрату невеликої кількості останніх подій?»*
Подтверждаю ваше понимание:
- “Тому, просто щоб підтвердити: ми створюємо службу скорочення адрес, яка має підтримувати близько 100 мільйонів адрес, з читанням значно частіше, ніж записом, і ми хочемо, щоб була забезпечена висока доступність, а не постійність. Чи це так?»*
Фаза 2: Оцінка масштабу
Покажіть, що ви з самого початку думаєте про масштаб. Виконуйте математичне завдання вголос — співбесідник оцінює вашу здатність до розумового мислення, а не лише вашу арифметику.
- “Давайте зробимо грубу оцінку ємності. Якщо у нас є 100 мільйонів користувачів і кожен користувач створює один скорочений URL на тиждень, це приблизно 14 мільйонів записів на день — близько 160 записів на секунду. Для читання, якщо кожен URL доступний близько 100 разів, це 1,4 мільярда читань на день - близько 16 000 читань на секунду. Це говорить мені, що нам потрібно сильно оптимізувати для читання шляху.”*
Фаза 3: Пропозиція архітектури високого рівня
Начнем с широкой, потом сверлим вниз. Зазначте, що ви пропонуєте перед тим, як намалювати діаграму.
- “Дозвольте мені почати з архітектури високого рівня, а потім ми зможемо збільшити компоненти, які є найцікавішими.” *
- “Я пропоную трирівневу архітектуру: рівень API з балансуванням навантаження, набір серверів програм і розподілене сховище даних.” *
- “Для зберігання даних я б схилявся до реляційної бази даних для метаданих адрес URL, оскільки схема є простою і послідовною, а перед нею є шар кешу для швидкості читання.” *
Фаза 4: Глибоке занурення в компоненти
Коли співбесідник запитає вас про подальші відомості щодо певного компонента, скористайтеся структурованою мовою, щоб вказати на свій підхід.
- « Дозвольте мені докладніше розповісти про службу створення адрес URL. » * “Існує кілька підходів. Одним з варіантів є використання гешування довгої адреси URL, але це створює ризик зіткнення. Іншим підходом є використання розподіленого генератора ідентифікаційних даних, наприклад, Twitter’s Snowflake. Я б схилявся до генератора ідентифікаційних даних, тому що…”
Фаза 5: Обговорення компромісів
Компромиси - це те, що інтерв’юери найбільше хочуть почути. Кожне архітектурне рішення передбачає компроміс — сформулювати, що ви отримуєте і чим жертвуєте.
Відповідь на питання:
- “Цей підхід забезпечує кращу швидкість читання, але він вводить затримку послідовності між кешом і базою даних. Залежно від вимог, цей компроміс може бути прийнятним або неприйнятним.”*
- “Використання можливої послідовності означає, що користувач може бачити застарілі дані протягом декількох секунд після оновлення. Для передачі в соціальних мережах, це, як правило, добре. Для фінансової книги, це абсолютно не так.»*
** Порівняння підходів: **
- “Ми можемо використовувати реляційну базу даних, яка надає нам гарантії ACID і розширені запити, або ми можемо використовувати сховище з широкими колонками, на зразок Cassandra, яке надає нам горизонтальну масштабованість запису за рахунок складних запитів. Враховуючи обсяг запису, я схиляюся до Cassandra, але я хочу зрозуміти шаблони запитів спочатку.”*
** Бути чесним про прогалини: **
- “Я менш знайомий з внутрішніми властивостями послідовного гешування, але я розумію, що це зменшує кількість ключів, які потрібно перезаписувати під час додавання або вилучення вузла. Чи варто глибоко занурюватися в це?»*
Розглядаються питання про подальшу долю
- “Це хороша думка — я не розглядав випадки, коли один користувач створює дуже велику кількість записів. Ми могли б обмежити на користувача на API-шлюзі, або ми могли б використовувати чергу для поглинання піків.”*
- “Ви маєте рацію, що одна база даних стане вузлом. Наступним кроком, який я б розглянув, є читання реплік, а потім горизонтальне шардування, якщо цього недостатньо.”*
Недоліки мови: Неможливо використовувати мови
** Починаючи з деталей реалізації:** Початок з « Я б використав Redis і Kafka » без вказівки проблеми або вимог сигналізує про погану структуру.
Описую свою непевність з наповненням:
Слабкий: “Хм… так я думаю, може ми могли б, скажімо, використовувати балансувальник навантаження?” Сильна: * “Я б розмістив балансувальник навантаження перед серверами застосунків, щоб розподілити трафік і ввімкнути горизонтальне масштабування.” *
Пропозиція без пояснення: Завжди пояснюйте чому, а не що.
Слабкий: “Я б використав PostgreSQL.” Сильна: “Я б використав PostgreSQL, тому що схема добре визначена і реляційна, а шаблони запитів вимагають з’єднань, які важко ефективно обробляти в сховищі документів.”
Інтерв’ю з системним дизайном нагороджують кандидатів, які комунікують так само добре, як вони думають. Структурована мова, чітке обговорення компромісів і впевнені питання прояснюють інженерну зрілість, яку вимагають старші ролі. Вправляйтеся у розмові уголос — словник з цього підручника допоможе вам зробити це зрозумілою, професійною англійською мовою.
Назва походить від англійського слова «refine» — «досконалювати»
Будьмо чесними - навіть досвідчені розробники можуть спіткнутися, коли формулюють складні технічні ідеї в професійному середовищі. Інтерв’ю з системним дизайном є особливо вкрай викликаючими, вимагаючи не тільки архітектурних знань, але і точних комунікаційних навичок. Для носіїв, для яких мова не є рідною, цей виклик посилюється потребою освоїти спеціалізований словник і прийняти природну фразу, яка передає впевненість і ясність. Це більше, ніж просто перекладання ваших думок; це про звучання як досвідченого інженера, який обговорює дизайн.
Однією з поширених пасток є використання надмірно формальної або технічної мови, коли простішого підходу було б достатньо. Розгляньте це повідомлення Slack, яке ви отримуєте під час перегляду PR: « Це потрібно переробити для кращої читабельності ». Хоча це технічно вірно, але в ньому бракує контексту і не запрошується співпраця. Ефективнішою відповіддю - відображаючи тип фрази, яку ви почуєте в конструктивному перегляді коду - може бути: “Я погоджуюся, що код може отримати користь від деяких спрощень. Чи можемо ми розглянути використання більш описових назв змінних і розбити цю більшу функцію на менші, більш управлянні одиниці?» Зауважте включення « Я погоджуюся », що демонструє залучення і спільне розуміння. Аналогічно, коли ви описуєте вашу запропоновану архітектуру під час інтерв’ ю, уникайте фраз на зразок « Система буде реалізована за допомогою парадигми мікросервісів ». Замість цього спробуйте: « Ми використаємо архітектуру мікросервісів для сприяння незалежному масштабуванню і розгортанню кожної служби ». Ця фраза є більш доступною і зосереджена на * перевагах * проекту.
Інша область, на якій варто зосередитися, це ефективне обґрунтування компромісів. Сказати «Це рішення має O(n) складності» може бути сприйнято як надто технічне і потенційно залякування. Кращий підхід буде таким: «Враховуючи очікуваний масштаб нашої бази користувачів, це рішення забезпечує ефективний спосіб обробки даних в один прохід - що є ключовим для мінімізації затримки». Ця фраза підкреслює *вплив * компромісу на продуктивність системи. Практикуючи сценарії, де ви пояснюєте, чому один вибір дизайну був пріоритетним над іншим, завжди ґрунтуючи ваші роздуми на реальних результатах (наприклад, вартість, масштабованість, підтримка) значно поліпшить ваше спілкування.
І, нарешті, не недооцінюйте силу активного слухання і прояснення питань. Якщо питання здається неоднозначним, це цілком прийнятно - і заохочується - сказати щось на зразок: “Чи можете ви розібратися, які аспекти системи є найбільш критичним для цієї дискусії?” або “Щоб переконатися, що я правильно розумію, чи ми в першу чергу зосереджені на початкових обмеженнях дизайну або очікуваних довгострокових вимогах масштабованості?” Продемонструвавши, що ви активно шукаєте роз’яснення, показує повагу до інтерв’юера і забезпечує ефективне вирішення їх питань. Звернення уваги на те, як запитання задаються, також може виявити основні пріоритети - здавалося б просте питання може насправді бути зондуванням для глибшого розуміння вашого процесу мислення.