Інтерв’ю з розробниками систем - це інтерв’ю з розмовою. Менеджер, який приймає на роботу, не просто оцінює ваші знання з архітектури — він оцінює, як ви * спілкуєтесь * у невідомості, як ви структуруєте своє мислення, і як ви поводитесь з неоднозначністю. Для людей, для яких англійська не є рідною мовою, це подвійний виклик: вам потрібно вільно розмовляти англійською мовою * і* одночасно мислити за допомогою складних розподілених систем.
Цей посібник надає вам мовні підвалини — фрази і структури, які можна використовувати знову і знову — щоб ви могли зосередити свою розумову енергію на архітектурі, а не на пошуку правильних слів.
Чому так важко думати вголос
На собеседовании по программированию, молчание допустимо, пока ты думаешь. У інтерв’ю з системним дизайнером, мовчання - це червоний прапор. Інтерв’юер не може побачити всередині вашої голови - якщо ви припините говорити, вони вважають, що ви застрягли.
Пастка для носіїв мови, для яких англійська не є рідною: ви знаєте, що думати, але ви сповільнюєте пошук точної англійської фрази. Коли ти знайдеш цю фразу, ти вже втратиш нить свого розуму.
Рішення: вивчіть невеликий словник повторюваних сполучених фраз, які не потребують часу на пошук. Вони стають автоматичними — ви можете застосовувати їх, поки ваш мозок працює над технічною проблемою.
Структура відповіді на питання про проектування системи
Більшість відповідей на питання про розробку системи відповідають цій структурі:
** 1. Роз’яснення вимог** → 2. Оцінка масштабу → 3. Визначити API → 4. Дизайн високого рівня → 5. Глибоке занурення в компоненти → 6. Визначити вузли та компроміси → **7. Заверши
Кожен етап має свій власний словник. Давайте створимо банк фраз для кожного.
Стадія 1: Роз’яснення вимог
Ніколи не починайте проектування, не встановивши, що саме ви створюєте. Это сигналы мышления старшего уровня.
** Функціональні вимоги (що робить система): **
“Перед тим, як я почну, я хочу переконатися, що я розумію сферу. Чи ми розробляємо шлях запису, шлях читання, або обидва?» keep_warm Чи повинна система підтримувати оновлення в реальному часі, або є прийнятною послідовність? keep_warm “Are we handling file uploads, or just text data?” keep_warm Які найважливіші функції для користувачів для цієї першої версії?»
** Нефункціональні вимоги (як добре він повинен працювати): **
“What are the latency requirements? Чи це API, що звернений до користувача, або ми можемо терпіти кілька секунд часу обробки?» keep_warm «Скільки щоденних активних користувачів ми розробляємо? 100 мільйонів доларів» keep_warm «Що таке очікуваний коефіцієнт читання-запису — переважно читання, як новини, або збалансований, як програма обміну повідомленнями?» keep_warm Чи ми дбаємо про сильну послідовність, або можемо прийняти кінцеву послідовність для кращої доступності і продуктивності?
** Припущення (зазначте їх чітко): **
«Я припускаю, що ми розробляємо для 10 мільйонів щоденних активних користувачів — дайте мені знати, якщо це занадто високо або занадто низько» keep_warm «Я припускаю, що основний випадок використання є важким для читання — близько 90% читає, 10% пише» keep_warm «Я збираюся зосередитися на основному щасливому шляху спочатку, а потім ми можемо обговорити крайові випадки»
Стадія 2: Оцінка масштабу (розрахунки збоку конверта)
Собеседники уважают кандидатов, которые делают грубые вычисления перед тем, как начать проектирование. Це показує, що ви розумієте, що масштаб формує архітектуру.
** Перехідні фрази: **
«Дай мені зробити грубі розрахунки збоку конверта, перш ніж я почну проектування» keep_warm Я оцінюю масштаб, щоб зрозуміти, з чим ми маємо справу
** Шаблони обчислень: **
«Якщо у нас є 100 мільйонів щоденних активних користувачів, і кожен користувач надсилає приблизно 10 повідомлень на день, це 1 мільярд повідомлень на день, або близько 10 000 повідомлень на секунду в середньому» keep_warm Припускаючи, що піковий трафік становить 5 × середній, нам потрібно обробляти близько 50 000 записів на секунду в піковій точці keep_warm “Кожне повідомлення має приблизно 100 байтів. 1 мільярд повідомлень на день × 100 байтів = 100 ГБ нових даних на день. За рік, це близько 36 ТБ — нам буде потрібно масштабоване рішення зберігання» keep_warm «З співвідношенням читання до запису 10:1, ми спостерігаємо 500 000 читання за секунду в піковій точці. Це свідчить про те, що нам знадобиться значне кешування»
** Корисні номери для запам’ятовування під час інтерв’ю: **
- 1 мільйон секунд ≈ 11,5 днів
- 10 мільйонів DAU × 10 дій/день = 100 мільйонів подій/день ÷ 86,400 = ~1,160 подій/секунду
- 1 кБ = 103 байтів, 1 МБ = 106, 1 ГБ = 109, 1 ТБ = 1012
Стадія 3: Визначення API
Розробка API перед внутрішніми якорями зафіксує розмову і демонструє мислення про продукт.
** Перехідні фрази: **
«Перед тим, як я нарисую компоненти, дозвольте мені нарисувати поверхню API — це допомагає прояснити, що система повинна робити» keep_warm «Я почну з точки зору клієнта і визначу, які API виклики система виставляє»
** Фрази опису API: **
«Клієнт викликає POST /messages з JSON-запитом, що містить sender_id, recipient_id і content.» keep_warm Відповідь поверне 201 Створено з присвоєним message_id і часовим штампом на стороні сервера keep_warm Для читання подачі, ми використаємо GET /feed?user_id=X&cursor=Y — Я використовую курсор-засноване сторінкування для ефективної обробки великого обсягу елементів keep_warm «Ми будемо потребувати WebSocket з’єднання для реалізації в реальному часі, але повернемося до опитування для клієнтів, які не підтримують WebSockets»
Стадія 4: Дизайн високого рівня
Тепер ти малюєш архітектуру. Перший крок тримайте простим — не перебільшуйте на цьому етапі.
** Перехідні фрази: **
«Дозвольте мені почати з простого, наївного дизайну, а потім ми визначимо його обмеження» keep_warm «Я нарисую компоненти високого рівня — будівельні блоки — перед тим, як ми зануримося в будь-який з них» keep_warm “Ось найпростіший дизайн, який міг би працювати. Ми вдосконалим його, як ми визначимо вузькі місця»
Describing components:
«Клієнт відправляє запити до API-шлюз, який обробляє автентифікацію і маршрутизує запит до відповідної мікросервісу.» keep_warm «Служба запису обробляє вхідні повідомлення і зберігає їх у первинній базі даних» keep_warm «Служба сповіщень відповідає за доставку оновлень в реальному часі до підключених клієнтів через WebSocket.» keep_warm «У нас є черга повідомлень тут — Kafka або SQS — яка відокремлює шлях запису від процесорів нижнього рівня. Якщо служба сповіщення повільна, черга поглинає затримку.”
Describing data flow:
«Запит тече від клієнта → API шлюзу → запису послуги → message broker → notification service.» keep_warm «На шляху читання, клієнт запитує подачу → служба подачі перевіряє кеш спочатку → на кеш-провал, він запитує базу даних і заповнює кеш для подальших читання»
Стадія 5: Глибоке занурення в компоненти
Тут ти глибоко занурюєшся в один компонент. Виберіть найцікавіше або найскладніше з них і поясніть, чому ви обрали саме цей варіант.
** Перехідні фрази: **
«Дозвольте мені збільшити рівень зберігання — саме там знаходяться найцікавіші компроміси» keep_warm «Я хочу поговорити про вибір бази даних більш детально.» keep_warm «Дозвольте мені глибше зануритися в проблему розширення — це головний виклик масштабованості для цього дизайну»
Explaining choices:
«Я вибираю NoSQL-склад, тому що дані вимагають багато запису, а шаблон доступу завжди за user_id — реляційна схема не додає цінності, а NoSQL дає нам кращу горизонтальну масштабованість» keep_warm “Ми розділимо базу даних за user_id, так що всі дані користувача будуть на одному шарді. Це робить запити з обсягом користувача ефективними і уникають перехресно-складних з’єднань» keep_warm «Я використовую кеш зі стратегією запису, а не запису назад, тому що тут важлива послідовність — ми не можемо показувати застарілі дані на сторінці профілю»
Стадія 6: Trade-offи і вузли
Це найбільш мовленнєво-інтенсивна частина і та, де нерідкісні носії часто борються найбільше. Сильні кандидати показують, що вони розуміють, що кожен вибір дизайну має свої витрати.
Identifying bottlenecks:
«Перше вузьке місце, яке я бачу, це пропускна здатність запису бази даних — при 50K записів на секунду, один основний вузол буде перевантажений» keep_warm Проблема розширення: для популярного користувача з 10 мільйонами послідовників, запис до кожного послідовника на пості вимагає 10 мільйонів записів бази даних синхронно. Це не буде масштабуватися» keep_warm «Єдиний API-шлюз є потенційною однією точкою невдачі — ми повинні розгорнути його в декількох зонах доступності»
Мова торгівлі — найважливіший словник:
| Phrase | When to use |
|---|---|
| “The trade-off here is…” | Introduce a choice with two-sided consequences |
| “The advantage of X is… however, the downside is…” | Compare options fairly |
| “This approach sacrifices X in favour of Y” | Acknowledge what you give up |
| “This is a classic consistency vs availability trade-off” | Reference CAP theorem |
| “I’m optimising for the read path here at the cost of some write complexity” | Show you understand the imbalance |
| “This works well at low scale, but will become a bottleneck at…” | Frame limitations honestly |
| “If we needed stronger guarantees, we could…” | Show you know alternatives |
Full trade-off sentences:
«Trade-off з денормалізацією подачі є записом посилення — кожен пост запускає N записів (один на послідовника). Перевага полягає в тому, що читання є одним пошуком бази даних замість дорогого з’єднання» keep_warm «Я вибираю кінцеву послідовність тут, тому що сильна послідовність вимагає розподілених замків, що значно збільшить затримку і зменшить доступність. Для соціальної подачі користувачі можуть терпіти побачити пост з декількома секундами запізнення» keep_warm «Використання реляційної бази даних дає нам ACID гарантії, що спрощує логіку застосування. Trade-off полягає в тому, що горизонтальне масштабування складніше, ніж з NoSQL-сховищем» keep_warm «Ця конструкція використовує синхронну обробку, яка простіше для роздумів і зневадження. Недоліком є те, що повільна служба вниз заблокує весь ланцюг запитів — ми б хотіли перейти на асинхронний, якщо затримка стане проблемою»
Стадія 7: Завершення
Закрити сеанс безпечно. Підсумуйте те, що ви створили, і запропонуйте наступні кроки.
Заключні фрази:
«Підсумую: я розробив систему, яка обробляє [основний випадок використання] з [ключовими архітектурними рішеннями]. Основні компроміси, які ми зробили, були [X] з [Y] причин» keep_warm «Області, які я б хотів дослідити далі, якби у нас було більше часу: стратегія анульування кешу, налаштування реплікації між центрами даних, а також дизайн моніторингу і попередження» keep_warm «Я не описав безпеку в деталях — для виробничої системи я додав би обмеження швидкості на користувача, запит автентифікації через JWT і аудит журналювання для відповідності» keep_warm “Чи має ця архітектура сенс? Чи є якийсь конкретний компонент, на який ви хотіли б, щоб я глибоко занурився?»
Управління невизначеністю
Ти не завжди знаєш відповідь. Правильна відповідь - це не мовчання - це структуроване мислення вголос.
** Коли ви не впевнені: **
«Я не на 100% впевнений у точних обмеженнях Cassandra в цьому масштабі — я перевірив би це перед тим, як прийняти рішення. Але архітектурно, це має сенс, тому що…» keep_warm «Я знаю, що Kafka часто використовується тут, але я б хотів порівняти його з Kinesis, враховуючи нашу інфраструктуру AWS. Моє припущення полягає в тому, що вартість і операційні витрати будуть нижчими з управляемою службою» keep_warm «Я бачу два підходи тут і я не впевнений, який з них кращий — чи можу я подумати через обидва?» keep_warm «Я зроблю припущення тут: Я припущу, що співвідношення читання-запису становить 10:1. Якщо б це було інакше, дизайн змінився б [спеціальним чином]»
Підсилювачі вільності для носіїв, для яких мова не є рідною
Це фрази, що поєднують і з’ єднують слова, які надають вашому висновку структуру, навіть якщо ви ще не вміли розібратися у деталях:
| Phrase | Purpose |
|---|---|
| “Let me think through this step by step…” | Buys thinking time, signals organised mind |
| “That’s a good question. My first instinct is…” | Acknowledges the question before answering |
| “I want to come back to that after we cover…” | Manages the flow without losing threads |
| “If I understand correctly, the requirement is…” | Confirms before committing |
| “One thing I want to flag is…” | Introduces an important concern |
| “Let’s zoom out for a second…” | Returns to the big picture |
| “One alternative here would be…” | Shows you know multiple solutions |
| “The reason I prefer X over Y is…” | Justifies your choices |
| “I’ll simplify for now and we can add complexity later” | Sets expectations for an iterative approach |
| “Does that make sense so far?” | Checks alignment and invites questions |
Поширені помилки, яких слід уникати
** 1. Початок проектування без пояснень** Перехід прямо до малювання системи без запитів щодо масштабу або вимог виглядає не дуже вдало. Завжди витрачайте 2-3 хвилини на пояснення.
**2. Занадто швидко, занадто глибоко Опис структури B- дерева індексів вашої бази даних за хвилину — до того, як буде встановлено дизайн високого рівня — втрачає інтерв’ юера. Сначала ширина, потом глубина.
** 3. Ігнорування нефункціональних вимог** Розробка системи без згадки про затримку, доступність або вимоги до послідовності виглядає неповним. Проактивно викликати теорему CAP, SLA і сценарії невдач.
** 4. Не визнає компромісів** Сказати «Я використаю X, тому що це найкращий варіант» без обговорення вартості X є червоним прапором. Кожен вибір має свої мінуси - їх назва демонструє розуміння старшого рівня.
**5. Тихо, замість того, щоб думати вголос 30- секундна пауза гірша за « Я думаю, чи використовувати реляційний чи нереляційний склад — дозвольте мені проаналізувати шаблони доступу ». Не відпускайте співбесідників.
Швидкий словник
| Term | Meaning in system design context |
|---|---|
| scalability | Ability to handle more load by adding resources |
| latency | Time for a single request to get a response |
| throughput | Requests/data processed per unit time |
| availability | Uptime; fraction of time the system is functional |
| consistency | All clients see the same data at the same time |
| partition tolerance | System works despite network splits (CAP theorem) |
| trade-off | A design choice where gaining X costs Y |
| bottleneck | The component that limits overall system performance |
| fan-out | One write triggering many downstream writes (e.g., push to followers’ feeds) |
| idempotent | Repeating an operation has the same effect as doing it once |
| eventual consistency | Data converges to the same state eventually, not immediately |
| sharding | Splitting data horizontally across multiple database nodes |
| replication | Copying data to multiple nodes for fault tolerance and read scaling |
| cache hit/miss | Whether requested data was found in cache (hit) or not (miss) |
| single point of failure | A component whose failure brings down the whole system |
Мовні шаблони, наведені вище, можна використовувати для будь- якого питання проектування системи — скорочення URL, подача Twitter, розподілене зберігання ключів і значень або система оплати. Практикуйтеся вимовляти їх вголос, поки вони не стануть автоматичними. Коли слова автоматичні, твій мозок вільний зосередитись на архітектурі.
Продовжуй практику
Закріпи прочитане вправами
П’ятихвилинні вправи з миттєвим фідбеком — на такій самій реальній IT-лексиці.
Поширені запитання
Про що ця стаття "Технічне інтерв'ю англійською: How to Think Out Loud in System Design"?
Як проходити співбесіду з system design англійською: структура відповіді, фрази, мова компромісів і розібрані приклади. Для тих, хто знає технології, але важко формулює думки англійською.
Чи безкоштовна ця стаття?
Так. Усі статті на CoderSlingo, включно з цією, доступні безкоштовно без реєстрації.
Скільки часу займає читання "Технічне інтерв'ю англійською: How to Think Out Loud in System Design"?
Приблизно 11 min.
Коли опубліковано цю статтю?
Цю статтю опубліковано у 2026 році.