Усім привіт! Я — Артем Грицаєнко, Head of Engineering у продукті AddMile, який створює IT компанія Headway Inc.
Маю загалом досвід в різних доменах: роботизована логістика, e-commerce та EdTech. Останні 5 років працював на позиціях Staff Engineer, Engineering Manager та Head of Engineering. За цей час мені вдалося побути як на місці кандидата, що проходить System Design Interview (інтервʼю щодо проєктування системи), так і на місці інтерв’юера. Я провів понад 30 таких співбесід. У цій статті поділюся поширеними помилками кандидатів, дам поради, як їх уникнути, а також як підготуватися до System Design Interview.
З кожним роком процес інтерв’ю стає все складнішим для розробників. System Design Interview допомагає розвивати загальний погляд на систему, розширяти знання про інші архітектурні підходи. Інтерв’юеру System Design Interview допомагає побачити експертизу і глибину знань кандидата: як він може вирішувати проблеми, як підбирає компоненти, наскільки його архітектура є практичною, а також оцінити комунікативні навички: як кандидат висловлює думки, захищає своє рішення.
Далі розгляну поширені помилки кандидатів, які не дають їм розкритися. Почну з доволі простих, а далі перейду до більш комплексних.
Помилка № 1. Закриватися та сприймати інтервʼюера як опонента
Звучить досить очевидно, проте це одна з найпоширеніших помилок на інтервʼю усіх типів.
Натомість пропоную ставитися до інтервʼюера як до потенційного колеги, продакт-овнера з технічними знаннями й активно ставити запитання.
Помилка № 2. Обирати перший ліпший інструмент для малювання
Я не раз бачив кандидатів, які починали нервувати через те, що не можуть знайти правильні фігури або в них не вписується текст. Інтервʼю — це апріорі некомфортне середовище, тому краще уникати зайвого стресу і заздалегідь «проклікатись» та познайомитись з інструментом.
Помилка № 3. Одразу стрибати в імплементацію
Отримуючи завдання задизайнити систему, кандидати часто одразу стрибають в імплементацію: обирають компоненти, розповідають про підходи. Не розуміючи навантаження системи та інших деталей, вони будують систему на основі декількох почутих юзкейсів. Краще перші
Помилка № 4. Орієнтуватися на FAANG
На YouTube є чимало відео про System Design Interview для підготовки до співбесід у FAANG. Проте слід розуміти, що не всі бізнеси мають навантаження рівня Google чи Netflix та всі гроші світу на побудову архітектури. Тому краще підходити до дизайну системи більш прагматично та не намагатися дизайнити ще один Google.
Помилка № 5. Забувати, що дизайн системи — це компроміси
Наприклад, є завдання зробити повнотекстовий пошук. І перше, що спадає на думку — додати якийсь Lucene-based інструмент: Elasticsearch або Sphinx. Водночас з кожним новим інструментом та компонентом система стає складнішою. Кандидат має бути готовим до запитань про синхронізацію: наприклад, коли ми пишемо в основну БД, а потім в іншу, як впевнитися, що дані консистентні?
Також не варто поспішати додавати інструменти, не отримавши достатньо інформації про систему. Наприклад, якщо даних небагато, буде цілком достатньо вбудованого повнотекстового пошуку у вашій основній БД.
Помилка № 6. Неправильно фіксувати функціональні вимоги
Функціональні вимоги стосуються поведінки системи. Часом на інтервʼю кандидати намагаються їх запамʼятати або вибірково занотувати. Скоріше за все, за 15 хвилин згадати їх буде важко. Рекомендую записувати вимоги на тій дошці, де ви будете малювати. Так інтерв’юер зможе одразу побачити, якщо якогось параметра не вистачатиме, і повідомити про це. Як варіант, фіксувати їх у форматі юзкейсів.
Водночас треба ідентифікувати, хто і як працює з системою. Наприклад, якщо під час інтервʼю ви дизайните систему для бронювання апартаментів, з нею можуть працювати як користувачі, так і адміністратори. Це допоможе коректно записати функціональні рекваєрменти.
Помилка № 7. Не враховувати нефункціональні рекваєрменти
Нефункціональні вимоги стосуються якості системи, тому на цьому етапі важливо зрозуміти ключові параметри. Наприклад, кількість користувачів системи, яку ви дизайните, Daily Active Users та плани на зростання за рік-два допоможуть розрахувати базовий RPS (Request Per Second).
Також важливо зрозуміти, чи є вимоги до latency, зокрема повний цикл response time (а не тільки клієнтській чи серверний). Ви можете спитати, чи важлива оптимізація до 90, 95 чи 99 персентиля. Варто спробувати розрахувати сторедж, дізнатися, якими ресурсами оперують (зображення, відео чи аудіо).
Крім RPS, можна спробувати порахувати TPS (Transaction Per Second). На прикладі з системою для резервування готелів, багато користувачів приходять і дивляться доступні варіанти, але лише умовно 10% здійснює бронювання. Тож запитів на читання буде набагато більше, ніж на резервування.
Врахуйте, з чим більше працює система: із записом, читанням, чи з тим та іншим? Ця інформація допоможе краще розрахувати вашу систему та підібрати правильні компоненти. Наприклад, для Write-Heavy системи можна дивитися в бік log structure записів, з використанням LSM-дерев, MemTable, зокрема такої бази даних як Cassandra. Водночас для Read-Heavy системи валідним є використання реляційної бази даних з B-Tree індексом, зокрема PostgreSQL.
Помилка № 8. Не фокусуватися на поточних проблемах
Часом помічаємо, що кандидати починають вигадувати додаткові рекваєрменти, які не стосуються завдання. Це добре, коли людина має продуктове мислення та пропонує ідеї, але краще це залишити на кінець інтерв’ю.
Іноді, коли кандидат не знає, як вирішити проблему, він починає відповідати абстрактно та «лити воду». Краще запропонувати гіпотезу, ніж намагатися дизайнити щось поза скоупом. Траплялися кандидати, які
Загалом System Design Interview містить чимало вимог, які потрібно покрити. Тому рекомендую не впадати в абстракції та думки, а намагатися задовольнити якомога більше вимог за виділений час.
Помилка 9. Не розділяти етапи System Design Interview
Іноді кандидати намагаються вирішити завдання одним махом. Рекомендую розділити процес на етапи.
Помилка № 10. Розв’язувати всі проблеми в один спосіб
Коли ми тривалий час працюємо з якоюсь технологією, це виглядає, наче у нас є лише молоток і цвяхи, якими ми розвʼязуємо усі проблеми. Наприклад, є система із навантаженням 5 rps, в якій потрібно зберігати профайл користувача. Кандидат пропонує відправляти запит на бекенд, де payload проходить через меседж-брокер та відправляється асинхронно. А браузер тримає конекшени та рендерить картинку через Server-Sent Events чи WebSockets.
Коли ми намагаємося запропонувати кандидату спростити рішення, питаємо, чи впевнений він, що тут потрібна асинхронна комунікація, він все одно повертається до механізму черг та асинхронного підходу. Отже, рекомендую тримати себе в тонусі та звертати увагу на інші підходи.
Помилка № 11. Не аргументувати свій вибір
Коли ви пропонуєте дизайн системи, важливо аргументувати, чому ви обираєте саме такий підхід. Наприклад, «для API я обираю JSON поверх текстового протоколу (JSON-RPC). Цей підхід дає можливість робити batch-запити — простий та не ускладнений ресурсами спосіб взаємодії» або «я обираю архітектурний підхід GraphQL, оскільки він дозволяє користувачам самим визначити, які дані запитувати, і це забезпечує більшу гнучкість для клієнтів». Також опишіть переваги та недоліки підходу.
Коли на запитання «чому для системи з 10 rps ви обираєте Kubernetes», кандидат аргументує, що це стандарт — це не найкраща аргументація. Краще навести приклади, які переваги має Kubernetes порівняно з іншими підходами.
Насправді ця аргументація — не стільки про прихильність до певної технології, скільки спосіб зрозуміти, чи копає кандидат в глибину, чи розуміє деталі інструментів, які використовує.
Помилка 12. Робота в конкурентному середовищі
Під час System Design Interview кандидата можуть спитати, як він контролюватиме конкурентність у системі. Коли ми пишемо вебзастосунки, ми зазвичай контролюємо її не на рівні аплікейшену, а на рівні баз даних. У такому разі кандидат може розповісти про варіанти блокування:
- Песимістичне — коли блокуються певні рядки, й інші користувачі, які намагаються щось зробити з ними, пропускаються. Такий вид блокування може не підходити у випадку великої кількості запитів до одного ресурсу.
- Оптимістичне — блокування за допомогою версіонування, таймстемпів, логічних годинників.
Помилка 13. Не вміти пояснити, як тримати систему в консистентному стані
Коли кандидат пропонує використати мікросервісну архітектуру, його можуть спитати, як можна впевнитися, що система знаходиться в консистентному стані. Наприклад, ми пишемо в сервіс А, B, С. Проте, коли записували в С, стався мережевий збій, що робити?
Можливим рішенням є ретраї. Однак варто розуміти, що не всі вони є безпечними. Тут допоможе ідемпотентність, яка гарантує, що повторний запит не призведе до небажаних наслідків. Також є складніші підходи:
- Try-Confirm/Cancel (коли ми робимо запит на систему, і якщо все добре, наступає стадія Confirm, у випадку Cancel зміни відкочуються назад);
- Saga (коли сервіси спілкуються за допомогою івентів, і якщо щось пішло не так, генеруються компенсаторні івенти);
- Двохфазний коміт, коли зміни здійснюються на рівні бази даних.
Пропонуючи кожен з цих підходів, кандидат має усвідомлювати, коли їх краще використовувати, за якого навантаження системи. Деякі з них значно ускладнюють код і не завжди релевантні.
Помилка 14. Забувати, що System Design Interview — процес з відкритим фіналом
Дизайн систем — це творчий процес, у якого немає ідеального рішення. Неможливо за годину змоделювати найкращу систему — на це потрібні тижні та місяці. Головна мета цього інтервʼю — цікава розмова. Інтерв’юер хоче зрозуміти, наскільки кандидат прокачений у комунікації та технічному плані, чи хочеться з ним працювати. І навпаки — кандидат вирішує, чи хоче працювати з таким інтерв’юером.
Власний кейс: встигнути за 30 хвилин
Розповім про один зі своїх досвідів проходження System Design Interview у ролі кандидата.
Завданням було спроєктувати механізм аутентифікації в TV-застосунку через QR-код. Час на виконання завдання —
Попри те, що часу було обмаль, перші 10 хвилин я ретельно розпитував інтерв’юера, щоб з’ясувати, які є функціональні та нефункціональні вимоги.
Функціональні вимоги були такими:
1. Генерація QR-коду при відкритті застосунку.
2. Сканування QR-коду.
3. Перехід на сторінку аутентифікації у мобільному браузері.
4. Сповіщення про успішний вхід на смарт-телевізорі.
Нефункціональні вимоги:
1. Швидка аутентифікація — до декількох секунд після сканування QR-коду.
2. Безпека, мінімізація ризиків повторного використання QR-коду.
3. Масштабованість, підтримка одночасної реєстрації до 1000 користувачів.
Я запропонував загальну архітектуру, де ключовими компонентами були телевізійний застосунок, мобільний пристрій та бекенд-сервер. Телевізійний застосунок мав показувати QR-код і «слухати» зміни статусу аутентифікації в реальному часі. Мобільний пристрій сканує QR-код і переходить за унікальним URL, що веде на сторінку входу — наприклад, через Google Sign-In або інший механізм OAuth.
На бекенді генерується QR-код, який містить унікальний session_id з часом життя близько 5 хвилин. Це дозволяє мінімізувати ризик повторного використання коду. Статус аутентифікації оновлюється у Firestore, яку я запропонував як основну базу даних — передусім завдяки відстеженню оновлень у реальному часі, міжрегіональній доступності та здатності автоматично масштабуватись.
Я обрав саме таку архітектуру, оскільки вона поєднує швидкість реакції, простоту масштабування й безпечне зберігання сесій. Такий підхід дозволив задовольнити як функціональні, так і нефункціональні вимоги — і, як результат, отримати схвальний фідбек від інтерв’юера.
Подібні інтервʼю зі стислими термінами реалізації змушують кандидатів швидко генерувати ідеї та приймати рішення. І для кандидатів це щонайменше — чудовий брейнсторм і спосіб застосувати свої знання.
Корисні матеріали
Якщо після прочитання цієї статті у вас є запитання або бажання познайомитись, пишіть мені в LinkedIn.
Сподобалась стаття автора? Підписуйтесь на його акаунт вгорі сторінки, щоб отримувати сповіщення про нові публікації на пошту.
