Інтерв'ю англійською мовою для System Design Rounds: Phrases That Show Senior Thinking
Освоєння англійської мови під час інтерв’ ю з розробниками систем: пояснення вимог, пропонування компромісів, оцінювання масштабу і обробка відмов. Фрази і скрипти для старших інженерів.
Інтерв’ ю з розробкою системи тестує дві речі одночасно: * чи можете ви розробити систему * і * чи можете ви чітко передати дизайн? * Якщо англійська не є вашою першою мовою, друга половина може вас потопити, навіть якщо ви чудовий інженер. Хороші новини: інтерв’ю з розробниками систем дуже описані. Одні й ті ж п’ять фаз виникають кожен раз, і є набір фраз для кожної. Вивчіть їх, і ви будете звучати як старший інженер, який робив це багато разів.
П’ять фаз (і що сказати в кожній)
- ** Прояснити вимоги **
- Оцінка масштабу
- Запрошуємо на розробку високого рівня
- Зануріться глибше і обговоріть компроміси
- Розв’язати проблеми і завершити
Давайте напишем сценарий для каждого.
Фаза 1: Прояснення вимог
Ніколи не починайте проектування відразу — співбесідник хоче побачити, як ви розв’ язуєте проблему. Корисні відкривачі:
- «Перед тим, як я перейду до дизайну, я б хотів роз’яснити вимоги»
- “Дай мені переконатися, що я розумію обсяг. Чи ми проектуємо X, чи також Y?»
- «Які функціональні вимоги проти нефункціональних вимог тут?»
- Чи варто мені припускати, що це read-heavy або write-heavy?
- Чи потрібна сильна послідовність, чи є можлива послідовність прийнятною?
“Дай мені пояснити сферу. Чи ми розробляємо шлях запису скорочення URL — створення коротких посилань — шлях читання — перенаправлення — або обидва? І чи потрібна нам аналітика, чи це за межами сфери застосування?»
Задавать такие вопросы - это свидетельствовать о зрелости. Інтерв’юери часто кажуть, що кандидат, який добре роз’яснив обсяг, вже напівпройшов.
Фаза 2: Оцінка масштабу (задні частини конверта)
От тебя будут ожидать, что ты будешь делать грубые вычисления вслух. Англійська мова для “грубих математичних” є ** back-of-the-envelope estimation **. Корисне обрамлення:
- «Дай мені зробити швидкий задні-з-конверта розрахунок.»
- «Поговоримо про числа»
- Припустимо, що щодня активними користувачами є приблизно 100 мільйонів людей, і кожен з них робить 10 запитів, то це приблизно один мільярд запитів на день
- «Тоді ми розглядаємо ** приблизно ** 10 000 запитів на секунду в піковій точці.»
Словник величин:
- по порядку - приблизно, в цьому діапазоні
- порядок величини - 10x
- пикова проти середньої напруги
-
- стабільний стан * — нормальна, тривала операція
«В стабільному стані ми очікуємо близько 5000 записів за секунду, але я б розробив для піку може 3x, щоб бути безпечним»
Фаза 3: Представлення проекту високого рівня
Покажите общую картину, прежде чем подробности. Дикторський супровід під час малювання:
- «На високому рівні, я б поставив load balancer перед stateless application tier.»
- “Запит ** тече ** від клієнта, через шлюз, до служби шару, і в сховище даних.”
- «Я почну з простого і ми можемо ітерувати звідти»
Фрази, що вказують на місце, де слід триматися, щоб співбесідник не зник:
- «Є три основні компоненти. Перший… Другий… Третій…»
- «Дозвольте мені **провести вас через ** життєвий цикл запитів.»
- «Зоммінг у сторону на секунду, ключова ідея є…»
- «Зомінг в на базі даних, ось як я б розірвав її»
Фаза 4: Комбінації — найважливіша англійська
Це місце, де співбесідник відокремлює кандидатів старшого рівня від середнього. Старші не стверджують, що є одна правильна відповідь; вони обговорюють компроміси.
- «Існує компроміс тут між послідовністю і доступністю.»
- «Ми могли б використовувати SQL або NoSQL. Причинами для SQL є сильна послідовність і з’єднання; Причинами проти є важче горизонтальне масштабування.»
- «Я схиляюсь до кешування тут, але з застереженням, що нам буде потрібна стратегія кешування-недійсності.»
- «Це залежить від того, чи ми ставимо пріоритет на затримку або вартість.»
- «Немає безкоштовного обіду — купівля доступності тут коштує нам послідовності»
“Ми могли б денормалізувати для прискорення читання, **за рахунок ** більш складних записів. Оскільки це важко для читання, я ** зроблю цей компроміс ** і прийму складність запису. ”
** Фрази для прийняття рішення ** (завершити, не зупинятися):
- «Я б пішов з тобою…» (фр
- «Зважаючи на обмеження, моя рекомендація є…»
- “Я за замовчуванням X, якщо ви не хочете, щоб я оптимізував для Y.”
Фаза 5: Втрати і закриття
Покажіть, що ви можете знайти слабкі місця у вашому * власному * дизайні:
- «Очевидне боttleneck це шлях запису бази даних.»
- Це єдина точка невдачі — дозвольте мені додати копію. ”
- «Щоб розширити це, я б запровадив шардинг за ID користувача»
- «Якби у мене було більше часу, я б збільшив режими невдач — що відбувається, коли кеш йде вниз?»
Завершуючи інтерв’ю:
- “Для ** підсумку **, ми маємо безстатевий рівень за балансуванням навантаження, шардований склад даних і кеш для читання шляху.”
- «Головні ризики це X і Y, і ось як я зменшу кожен з них»
Граціозно відбиває удари
Опросники будут специально бросать вам вызов, чтобы посмотреть, как вы отреагируете. Не ставьтесь в оборону. Купуй час і залучайся:
- «Це **справедлива точка ** — дайте мені переглянути.»
- “Хороший пойманий. Ти маєш рацію, що не буде масштабуватися. Дозвольте мені адаптуватися»
- «Я розумію, що ви маєте на увазі. Альтернативою була б…»
- «Чи можу я взяти хвилину, щоб ** подумати про це**?»
Если ты действительно не знаешь:
- «Я не впевнений, але моя інтуїція така, що… — Я б хотів перевірити це за допомогою тесту навантаження»
Признаючи невизначеність спокійно читає як * старший *. Блеф читается как младший.
Нерідко виникли проблеми з ненадійними інженерами
- Мовчання під час роздумів Інтерв’юери не можуть читати ваші думки. Розповідь: «Дай мені подумати вголос на секунду»
- Сказати “Я зроблю” замість “Я зроблю”. Використовуйте умовний вираз — “Я використаю чергу тут” — це звучить більше як роздуми, ніж як фіксований план.
- “Чем лучше, тем быстрее”. Просто “лучше, быстрее”. І краще більша пропускна здатність, менша затримка.
- ** Перебільшення вибачень. ** Одного “хорошого пострілу” достатньо; не кажіть “вибачте” кілька разів.
20-секундний сценарій для запам’ятовування
“Дякую. Перед тим, як щось розробляти, я б хотів роз’яснити вимоги і згодитися на обсяг. Потім я зроблю швидку задню частину конверта оцінку масштабу, нарисую високорівневий проект, і ми можемо глибоко зануритися в той компонент, який вам здається найбільш цікавим. По дороге я скажу, что я делаю. Чи працює цей підхід для вас?»
Скажи это, и ты уже показал структуру, стаж и плавность в первые 20 секунд.
Ключевые вещи
- Інтерв’ю з проектуванням системи проходять п’ять передбачуваних фаз - сценарій кожної з них.
- Спочатку визначити об’єкт. Це половина битви.
- Мова компенсацій є тим, що відрізняє старшого інженера: причина за/проти, за рахунок, на балансі.
- Розкажіть вголос про свої думки і використовуйте умовний («Я б використав…»).
- Обходьтеся з відступом з “справедливою точкою” і “добрим ловом”, і спокійно визнайте невизначеність - це будує довіру.
Навигація Nuance: Рефінансування Вашої фрази для ясності
Багато не-рідних носіїв вважають складним негайно перекласти технічні поняття в вільну, професійну англійську. Це не просто про знання слів; це про передачу намірів, продемонстрування розуміння інженерних принципів і будівництво відносин з вашою командою. Ключовим аспектом, який часто ігнорується, є розпізнавання тонких нюансів у фразуваннях, які можуть суттєво вплинути на те, як ваші ідеї будуть сприйматися. Розглянемо сценарій: ви обговорюєте запропоновану стратегію шардингу бази даних під час перегляду дизайну. Просто заявивши «Ми повинні розділити базу даних», можна сприйняти як недостатньо докладне. У нього немає контексту і не демонструє розуміння потенційних проблем. Сила в том, как ты выражаешь свою потребность.
Ефективнішим підходом було б: «Щоб зменшити потенційні вузли масштабування з нашим очікуваним зростанням користувачів — прогнозуючи приблизно 3-кратне збільшення протягом наступних двох років — я пропоную послідовну стратегію гешування для поля ідентифікатора користувача, вирівняного з вертикальною моделлю шардингу. Це дозволяє нам передбачувано розподіляти дані між декількома екземплярами і підтримувати низьку затримку доступу, особливо для часто доступних профілів користувачів. Також варто розглянути можливість спостереження за продуктивністю запиту після його реалізації, щоб переконатися, що обраний ключ- шард ефективно розподіляє навантаження. Зауважте додавання кваліфікаторів — « зменшити », « проектування », « вирівняти з » — які демонструють активний процес мислення і розуміння потенційних наслідків. Це про те, щоб продемонструвати, що ви * подумали * через наслідки, а не просто вказати на рішення.
Кроме того, не бойся признавать сложность. Фрази на кшталт “Це вводить певні компроміси…” або “Дослідимо наслідки…” сигналізують про інтелектуальну чесність і готовність до критичної дискусії. Уникайте надто спрощених пояснень, які можуть сприйматися як відкидання альтернативних точок зору. Аналогічно, при поясненні оцінених потреб у ресурсах - скажімо, для нової мікросервісу - краще оформити його з впевненістю, але також прозорістю: “Заснований на нашій поточній архітектурі і очікуваних профілях навантаження, я оцінюю, що ця служба потребуватиме приблизно 4-8 віртуальних машин з [спеціфічними специфікаціями CPU / RAM]. Однак, ми повинні постійно моніторити використання ресурсів і коригувати конфігурацію за потреби за допомогою автоматичного масштабування. “Це визнання постійного моніторингу підсилює прагматичний підхід до проектування системи.
Нарешті, активний пошук зворотнього зв’язку є ключовим. Замість того, щоб просто представити ваше рішення, спробуйте сформулювати його у вигляді запитання: « Я б був вдячний за вашу точку зору на те, чи відповідає ця стратегія шардингу нашим загальним цілям послідовності даних, враховуючи очікуваний обсяг транзакцій. » Це запрошує до співпраці і демонструє, що ви цінуєте різноманітні думки — це відмітна риса старшого інженерного мислення. Пам’ятайте, чітке спілкування - це більше, ніж просто ідеальна граматика; це передавання впевненості, демонстрація розуміння і сприяння продуктивному діалогу.