Як пояснити своє рішення про архітектуру в інтерв'ю
Пояснити рішення щодо архітектури в інтерв' ю з впевненістю: структура контекст- варіанти- рішення, мова компромісу і фрази для обробки подальших питань.
У старших інженерних інтерв’ю, питання рідко є * “Що ви побудували?” * - це * “Чому ви побудували його таким чином?” * Інтерв’юери хочуть почути ваші міркування. Для носіїв, для яких англійська не є рідною, викликом є структурування складної технічної історії під ясним тиском. Цей посібник надає вам повторюваний шаблон і англійську мову для його виконання.
Основні принципи: Контекст → Опції → Рішення → Результат
Майже будь- яка історія архітектури відповідає цій формі:
- ** Контекст ** — проблема і обмеження.
- ** Варіанти ** — реалістичні альтернативи, які ви зважите.
- Рішення — що ви обрали і чому.
- ** Результат ** — що сталося, включаючи те, що ви змінили.
Інтерв’юери люблять цю структуру, тому що вона доводить, що ви розглядали альтернативи, а не вибирати першу ідею.
Встановлення контексту
Начинаем с проблемы, а не с решения.
- “Ми обробляли близько двох мільйонів подій на день, і існуючий синхронний конвеєр не міг впоратися з часом пік. Затримка зростала, і ми пропускали події. Обмеження полягало в тому, що у нас була невелика команда і жорсткий термін до запуску. ”*
Корисні фрази для рамки:
- «Головна проблема, яку ми вирішували, була…»
- «Ключеве обмеження було…»
- «В той час, ми мали справу з…»
- «Відповідальність за бізнес» (нім
Назва обмежень (розмір команди, строк, бюджет, існуючі технології) робить ваше рішення більш обґрунтованим, ніж теоретичним.
Представлення варіантів
“Ми розглянули три варіанти. Перша була масштабування існуючої служби вертикально - просто, але це тільки купило нам кілька місяців. Друга була ввести чергу повідомлень і обробляти події асинхронно. Третій був перехід на управляючу платформу потокового відтворення, яка була потужною, але додала операційну складність, яку наша команда не могла підтримувати поки що. ”
Мова для оцінки альтернатив:
- «Один варіант був X; компроміс був там…»
- “Ми виключили це, тому що…”
- «На папері, X виглядав привабливо, але на практиці…»
Показ причин, чому ви * відхилили * параметри, часто є більш вражаючим, ніж сам вибраний вами параметр.
Визначити значення і значення значення
- “Ми обирали чергу повідомлень. Це дало нам відокремлення і стійкість, які нам були потрібні без операційних витрат повної платформи потокового мовлення. Компроміс полягав у тому, що ми прийняли остаточну послідовність — деякі перегляди нижче по течії можуть бути на кілька секунд застарілими — що було прийнятно для цього випадку використання. ”*
Комбінований словник:
| Phrase | Use |
|---|---|
| ”We traded X for Y.” | Naming what you gave up. |
| ”That came at the cost of…” | Acknowledging a downside. |
| ”We optimised for X over Y.” | Showing priorities. |
| ”It was a pragmatic choice given…” | Defending a non-ideal pick. |
Слово “прагматичний” - це золото в інтерв’ю - це сигнал, що ви балансуєте ідеали з реальністю.
Власність на результат (включаючи помилки)
- “Це працювало добре — ми обробляли трафік запуску без відкидання подій. З погляду на минуле, я б раніше вклав гроші в моніторинг глибини черги, тому що ми були спіймані на ходу, коли споживач відставав.”*
Признаючись в помилці, ти стаєш більш довірливим, а не менш. Встановити як навчальний:
- “Якби я робив це знову, я б…”
- «Одна річ, яку я недооцінив, була…»
- «Ми зрозуміли важким шляхом, що…»
Розглядаються питання про подальшу долю
Допитувачі розслідують. Купи собі час на роздуми, грациозно:
“Це гарне питання - дайте мені подумати про це на секунду.” “Все залежить від масштабу. Для нашого об’єму, X мав сенс; при десятикратному навантаженні, я переглянув би це питання. ”
Коли ти не знаєш:
“Я не працював з цією конкретною технологією, але, базуючись на принципах, я б очікував…”
Ніколи не блефуй. “Все залежить, і ось від чого” - це відповідь старшого рівня.
Фрази, що вказують на старшість
“Немає ідеальної відповіді тут — це про вибір найменш поганого компромісу для контексту.” “Я намагався зробити дизайн достатньо простим, щоб команда могла дійсно ним користуватися.” “Ми навмисно уникнули передчасної оптимізації.”
Вони демонструють судження, що відрізняє старшого інженера від сильного програміста.
Основна проблема: занадто багато деталей
Під стресом, багато кандидатів занурюються в специфіку реалізації. Залишатися на правильної висоті:
- “Я можу глибше зануритися у реалізацію, якщо це буде корисно, але на високому рівні рішення було…” *
Предложение углубиться, а не сбросить все, показывает, что ты можешь читать свою аудиторию.
Пояснення архітектури в інтерв’ю - це розповідь історії зі структурою. Закочуйтесь на проблемі і обмеженнях, проходьте через варіанти, назвайте компроміс чітко, і чесно відповідайте за результат. З допомогою структури Контекст-Вибір-Рішення-Відповідь і цих фраз, ви можете перетворити нервову технічну блукання в впевнену, старше звучати оповідь - яка є саме тим, що інтерв’юер слухає.
Наприклад, слово «навигація» означає «пересування по річці»
Будьмо чесними - обговорення архітектурних виборів може бути пригнічуючим, особливо коли ви під тиском виправдовувати свої рішення. Для не рідних носіїв англійської мови нюанси технічної мови і виразні компроміси можуть бути особливо викликом. Це не просто про те, щоб сказати що ви зробили; це про те, щоб пояснити чому з ясністю і впевненістю. Ключовим є те, щоб обґрунтувати своє обґрунтування навколо структурованого підходу - контексту, варіантів, рішення - і визнати, що кожен вибір включає компроміс.
Подумайте про це так: під час перегляду коду старший інженер може запитати: « Чому ви обрали React замість Angular для цього проекту? » Проста, оборонна відповідь на зразок « React краще » не впорається з завданням. Замість цього, більш ефективною відповіддю було б: «В контексті існуючої експертизи нашої команди — ми маємо сильні навички JavaScript — і потребу в швидкому прототипуванні і частих оновленнях, React запропонував швидший шлях до надання цінності з нашим поточним набором навичок. Ми оцінювали Angular широко, але його стриманіша крива навчання і суворіші конвенції не дозволили б нам дотримуватися наших початкових термінів так ефективно.” Зауважте, як ця відповідь надає контекст (командний досвід, цілі проекту), описує розглянуті варіанти (React проти. Angular), і чітко сформулює рішення, засноване на компромісах.
Іншою корисною тактикою є активне вирішення потенційних проблем. Перед тим, як зануритися в технічні деталі, ви можете упереджено сказати щось на зразок: “Я розумію, що цей вибір може здатися незвичайним на перший погляд. Причини вибору архітектури мікросервісів - додаючи складності - були обумовлені нашою потребою в незалежному масштабуванні сервісів, оскільки ми очікували швидкого зростання користувацького трафіку і здатності швидко розгортати оновлення без впливу на всю систему. “Це демонструє обізнаність про потенційну критику і негайно встановлює ваше обґрунтування.
Нарешті, будьте готові до подальших питань, таких як: «Які були недоліки мікросервісів?» Хороша відповідь - це не просто літанія проблем; це чесна оцінка: «Звичайно, є проблеми. Ми очікували збільшення операційних витрат при управлінні декількома службами - ми вирішили це за допомогою автоматизації і надійного моніторингу. Крім того, розподілене відстеження додало складності до зневадження, але ми зменшили це, реалізувавши всеосяжні стратегії ведення журналу. » Показуючи, що ви розглянули недоліки і як ви їх вирішили, ви будуєте довіру і демонструєте продуманий підхід. Пам’ятайте, визнання компромісів не означає визнання слабкості; це стосується демонстрації стратегічного мислення і відповідального прийняття рішень - якостей, які високо цінуються в будь-якій технічній ролі.