Привіт усім! Мене звуть Олексій Левжинський, і я є техлітом у команді Grammarly, яка розробляє Grammarly Browser Extension. Вже понад 7 років я працюю в цій компанії і беру участь у процесі інтерв'ювання. Сьогодні я хочу розповісти вам про цікавий тип інтерв'ю, а саме - системи дизайну. Дозвольте розкрити мету цього інтерв'ю та розібрати деякі міфи, які можуть виникнути щодо цього процесу.

Насправді системи дизайну - це не рокет-наука, і ви вже знаєте багато з того, що стосується цього. Просто потрібно розуміти, на що саме воно спрямоване, і все буде добре. Сьогодні ми розглянемо цей процес ближче. Доповідь складатиметься з кількох частин. Розпочнемо з опису типового процесу інтерв'ю у нашій компанії. Шукаючи нових працівників, ми враховуємо їхні навички та потреби компанії. Стандартизація інтерв'ю допомагає знайти правильних кандидатів для конкретних позицій, де важливо забезпечити співпадіння інтересів обох сторін для довготривалого співробітництва.

Те саме стосується й людей, які шукають довгострокову роботу. Особливо в продуктових компаніях, проєкти можуть змінюватися, але загальна мета компанії залишається незмінною. Тому важливо, щоб процес інтерв'ю дозволяв кандидатові розуміти, чим саме займається компанія, чи її цілі і методи роботи відповідають кандидатові. Процес інтерв'ю може тривати довго, але це допомагає кандидатові знайомитися з різними співробітниками та зрозуміти, чи відповідає компанія його очікуванням.Оскільки процеси інтерв'ю стандартизовані, але мають свої нюанси, важливо задавати питання, розуміти, що очікувати і як готуватися. Наприклад, деякі елементи можуть включати лайф-кодінг завдання або інші аспекти, які можуть бути невідомі. Питайте і дізнавайтеся, щоб бути готовими, і розумійте очікування.

Стандартний процес інтерв'ю зазвичай розпочинається з етапу скрінінгу, де кандидат і компанія визначають, чи відповідає профіль кандидата потребам компанії. Якщо це так, в інтерв'ю переходиться до детальних етапів, спрямованих на конкретні завдання, пов'язані із сферою прикладної діяльності. Для фронтенд-інженера це може бути технічні інтерв'ю, спрямовані на знання фронтенду, або інтерв'ю з алгоритмів, що стосуються комп'ютерних наук. Також можуть бути інтерв'ю для нетехнічних позицій, таких як продуктові або менеджерські ролі.

Проте сьогодні говоримо про системний дизайн. Ну і, взагалі, як воно відбувається? По-перше, цей процес інтерв'ю, ще раз, тобто, взагалі, завжди саме питайте, що від вас очікують, які будуть процеси, тому що цей систем-дизайн може називатися по-різному, кожна компанія може, бути частина якогось іншого інтерв'ю, де вас будуть питати чисто теорію, розкажіть, будь ласка, що таке солід, або як працює поліморфізм. Або це може бути інша назва, условно, якесь там архітектурне інтерв'ю, або софтвер-дизайн та архітектура. Тобто, наповнення може бути трішки різними, і вам треба розуміти, взагалі, до чого готуватися. Проте, зазвичай, коли хтось чує системний дизайн, це, скажімо, всі думають, що це про бекенд. Тільки про бекенд і про скелінг бекенду, про якісь нюанси, як воно працює. Проте, звичайно, нема сенсу питати фронтенд-інженера, як працює бекенд, тому що, зазвичай, він може взагалі ніколи за свою кар'єру з цим не стикатися, скажімо, дуже глибоко. Тому сьогодні ми саме і говоримо про систем дизайн інтерв'ю для фронтенд-інженера. Воно теж існує, і взагалі про що це.

На цьому інтерв'ю, зазвичай, ми вважаємо, що бекенд – це такий чорний ящик, який може зробити взагалі будь-що. Тобто, будь-яке API можна зробити – там все вже умовно реалізовано. А саме, на що ми звертаємо увагу – це на фронтенд. Це архітектура клієнта, тобто, які там модулі, яка взаємодія, як ми управляємо станом, взагалі, які взаємозв'язки, що куди йде. Звісно, це буде про API, тобто, все ж таки важливо, як ми будемо комунікувати з бекендом, які протоколи, можливо, що ми будемо пересилати, як воно буде працювати, помилки, як ми їх оброблюємо. Це може бути про перформанс, тобто, це все ж таки важливо на фронтенді. Ну, і якісь такі чисто типові для фронтенду питання, як доступність, інтернаціоналізація, можливо, ще щось, чого нема тут у списку. І цікаво, на що звертають увагу кандидати і люди, які проводять це.

Ну, по-перше, так, звісно, системи дизайну – це таке дуже відкрите питання, тобто, і зазвичай, ідея такого, скажімо, практичного інтерв'ю – це зрозуміти, як людина буде вже працювати, кожен день зі своїми задачами. Тобто, не завжди задачі зрозумілі, часто це якісь доволі, там, щось треба зробити, і вам треба піти і розібратися, як це буде робитися. Ну, і саме ідея, на що звертаєте увагу – це, по-перше, вирішення цих задач, тобто, дивляться, наскільки людина взагалі може зрозуміти завдання, звичайно, ніхто не може, умовно, якщо скажуть «зробіть Фейсбук», ну, за 60 хвилин його ніхто не зробить, ну, і, звичайно, взагалі, там тисячі людей над ним працюють, тобто, проте тут ідея, що людина розуміє, взагалі, що від неї треба, і, як зазвичай, ділиться на якісь маленькі частини, і вже маленькі частини можна більш-менш якось зрозуміти, як вирішувати, в цілому так це і працює на практиці. Для цього потрібно, звичайно, задавати правильні питання, і, так, звичайно, що ще важливо, що людина буде розуміти, що будь-яке рішення, воно не універсальне, тобто, завжди будуть якісь обмеження, і це треба теж розуміти, які можуть бути нюанси.

Наступне, це умовно, що важливо, ми не зустрічаємо десь посередині, а все ж таки ми намагаємося вирішити все ж таки нашу проблему, тобто, від початку до кінця, тому що так і в реальному житті, так ми можемо стикатися з якимись дуже важко вирішуємими питаннями, проте ми можемо якось обійти, і це теж тут важливо. Ну і, звичайно, це якісь розуміння таких технічних речей, наприклад, як банальні принципи проєктування, паттерни, ну і, звичайно, розуміння фронтенду. Добре, більш-менш розібралися. Про що це? Тепер давайте подивимося на щось більш-менш таке реальне.

Сьогодні, наприклад, на прикладі Твіттера подивимося, як взагалі, яка послідовність того, що можна робити на цьому інтерв'ю, і як це теоретично може виглядати. Перед тим, як почнемо, тут, звичайно, можна умовно для себе розділити процес цього інтерв'ю на декілька частин. Ну, звичайно, саме перша частина вам розказують завдання. Завдання може будь-яке. Тобто, насправді, це може бути щось дуже загальне, як зробіть, будь ласка, Твіттер, зробіть, будь ласка, Фейсбук. Або може бути більш детально, коли вам вже розказують про обмеження чи обмеження, які треба, обмеження, скажімо так, задачі. Тобто, якийсь конкретний там частину, наприклад, того ж Твіттера. Все ж таки, після того, як ви побачили завдання, вам потрібно, якось, більш детально зрозуміти, що ж саме потрібно, особливо, якщо це дуже загальне питання. Тобто, і зрозуміти, що саме сьогодні ми будемо вирішувати. Тобто, звичайно, ми не будемо будувати увесь Твіттер. Далі, скажімо так, основну частину інтерв'ю займає саме фаза дизайну. Ну, і якесь таке завершення. Це, можливо, якісь там додаткові питання, які запитає той, хто проводить інтерв'ю, або вже поглиблення у ці модулі, які були побудовані, скажімо так, під час фази дизайну. Одразу хочу сказати, що той приклад, який сьогодні буде, він такий більш, скажімо, загальний, і він, звичайно, хочу сказати, що це не буде, скажімо так, золота пуля, або єдине рішення, яким треба проходити системний дизайн інтерв'ю. Це більш таке щось загальне, яке має допомогти зрозуміти, а взагалі, що потрібно робити і в яку сторону потрібно двигатися під час цього інтерв'ю. Ось, тому давайте почнемо.

Що перше має побачити користувач? Окей, він має побачити, умовно кажучи, нашу стрічку. Добре, він має мати можливість робити пости. Добре, ще щось ми хочемо? Наприклад, ми хочемо, щоб людина могла побачити реплай нашого конкретного поста, Твіта в нашій стрічці. Добре, а як? Чи важливо, як ця людина побачить наші реплаї? Ну, тобто, це може бути поп-ап або окрема сторінка? Тут також можуть бути відповіді, наприклад. Ну, виріште самі.

Добре, давайте подумаємо. Ну, в цілому, як це краще зробити? Ну, поп-ап може бути незрозумілим, якщо людина там перегружає сторінку, якось нам треба підгружати всю стрічку на фоні десь. Як це має виглядати? Чи потрібні нам ці додаткові запити? Ну, давайте не будемо, давайте зробимо окрему сторінку. В цілому це наче логічно. А що має бути всередині? Що саме має бути в Твіті? Ну, давайте з простого почнемо, це буде просто стрічка. Ми не будемо брати там відео або картинки, спростимо. Валідація? Так, зробимо валідацію. Щодо навантаження? Це також треба зрозуміти. Взагалі, наскільки багато даних може бути?

Тобто, це мільйони, не мільйони? Якщо так, то це буде впливати на вирішення нашого завдання. Тобто, окей, ми, скоріш за все, кажемо, що буде щось там 50 твітів на сторінку, тобто ми розуміємо, що так, нам потрібно буде подумати про багінацію, тобто, значить, нам треба буде подумати, який API нам для цього потрібен. Ну і, можливо, щось таке завершуюче, а взагалі, як, що у нас має бути? Чи хочемо ми це в реальному часі? Ну, наче нам не потрібен реальний час, тобто ми, окей, там раз на, умовно, 10 секунд робити запити і все. Ну і, звісно, а що хочемо кешування? Офлайн-режим, щось таке? Ну, давайте без офлайн-режиму, це вже складне завдання, а нас немає на цей час, наприклад. А щодо того, щоб хочемо, щоб коли людина почала писати твіт, то і потім пішла на якусь іншу сторінку, то у неї зберігся цей статус. Тобто, повернулися, побачили, продовжили, запостили. Ну і останнє таке загальне щось, типу, а ми хочемо щось конкретне по фронтенду, наприклад. Чи якийсь фреймворк. Ну, тут, скажімо, давайте подивимось на помилки і подивимось на те, що ми можемо робити з доступністю. Все. Всього досить. Далі є такий доволі простий фреймворк, як це можна все записати, умовно у нас є функціональні, не функціональні вимоги. Що таке функціональні, це фактично те, що має робити система, а не функціональні, це саме, можливо, як вона має це робити. Щось про, скажімо так, перформанс її системи.

Ось, ну, виходить, ми наче описали те, що ми будемо робити. Далі будемо ми робити щось доволі просте, тобто у нас є стрічка, у нас є форма поста і у нас є ще можливість подивитися на конкретний твіт, на його реплай, умовно на окремій сторінці. Далі йдемо, у нас є, як це далі можна структурувати в цілому. Добре, ми зрозуміли, що ми хочемо зробити, тепер нам треба зробити, скажімо так, дизайн цього нашого додатку, нашого такого маленького твітера. Тут є умовно, можна розділити на етапи, вони можуть бути в різній послідовності, в залежно від завдання, тобто нам потрібна така висока рівнева діаграма того, що там буде, тобто це наш, скажімо так, фінальний стейт.

Також важливо поговорити про певно, які дані у нас будуть, як хто буде ці дані використовувати, скажімо так, нашу модель, і взаємодію з нашим сервером, тобто що, як, який транспорт ми будемо використовувати. Тут важливий момент, що фактично це інтерв'ю про взаємодію з Whiteboard. Дуже важливо, щоб все, що, скажімо, ви кажете, було намальовано або записано на ці самі Whiteboard, тобто навіть ці функціональні і не функціональні вимоги, тому що, по-перше, це вам допомагає під час інтерв'ю не забувати, що відбувалося і взагалі, що потрібно було робити.

Ну, і наприкінці ви буде зрозуміло, взагалі, до чого ми дійшли, тому що все, що слова, вони можуть бути забуті, а конкретна схема, яка намальована, вона буде як результат. Умовно, це в цілому не треба малювати, це більше для пояснення, тобто умовно, так звичайно, будь-який додаток можна намалювати так, у нас є клієнт-сервер, яка між ними взаємодіє, і тут саме питання, як почати? Тобто тут можна сказати, чи має сенс взагалі я казав, що сервер це в цілому блекбокс, такий чорний ящик, проте ви можете, якщо, наприклад, десь під час питань було важливо про якусь оптимізацію або перформанс, ви можете сказати, добре, ми в цілому, я от, наприклад, пропоную, щоб було у нас там сервер-сайрендеринг условно, чи потрібно нам зараз про нього говорити, чи не потрібно. Ну, в даному випадку ми про нього не будемо говорити, будемо вважати, що у нас таке типове single-page класичне аплікейшн, добре, давайте почнемо з клієнта, тобто тут важливо взагалі постійно, постійно, періодично, питати інтерв'ювера, чи взагалі ми на правильному шляху, тобто, чи саме то, це те, куди ми йдемо.

Ну, тут перепитаємо, чи я хочу почати з клієнта, чи є в цьому сенс. Так, давайте почнемо з клієнта. І ще раз хочу сказати, що спочатку треба, рекомендація така, спочатку важливо розуміти взагалі високорівнево, що ми робимо. А потім вже ми будемо говорити про конкретні деталі, наприклад, про якісь модулі маленькі, якісь там взаємодії всередині цих модулів, тому що ми просто можемо витрачати час, все ж таки, інтерв'ю у нас, тому словно, 60 хвилин і не дійти до більш-менш зрозумілого рішення.

Тут все доволі просто. Починаємо. Що у нас є? Ну, у нас є фронтенд, будуть у нас якісь view. Далі, у нас буде якась логіка, скажімо так, логіка додатку, яка буде, скажімо, допомагати рендерити ці view. Тобто, де ми її будемо розміщати. Тут, умовно, я додаю контролер, проте хочу одразу сказати, що це більше для прикладу, тобто в реальному житті тут дуже важливо. Саме на цьому етапі ви можете запропонувати, окей, а я буду використовувати такий фреймворк, або у мене ця логіка буде, умовно, ми зробимо її на хоках, або я все ж таки пропоную зробити, у нас буде якась додаткова логіка, яка буде обслуговувати view, вона буде view-моделлю, презентером, що завгодно.

А важливо цим контролерам, що я саме хочу тут показати, що ми розуміємо, що у нас є додаток, ми його будемо розширяти, додавати, змінювати і, скоріше за все, ми дуже хочемо розділити саме логіку презентації, бізнес і логіку додатку. Тому контролер тут в лапках, це, щоб умовно ви розуміли, що тут може бути щось інше. Так, звичайно, у нас буде якийсь стейт нашого додатку, і ми з ним будемо взаємодіяти; про це поговоримо на подальших слайдах. Ну і, звичайно, сервер, тут нічого дивного. Окей, ми пам'ятаємо наші вимоги; вони у нас поруч десь записані. Ми пам'ятаємо, що нам треба зробити декілька view, тобто у нас є стрічка, у нас є форма нового твіта і у нас є окремий твіт. Ми казали, що це буде сторінка; тоді, скоріше за , всю цю логіку у нас не буде умовно обслуговуватися якоюсь одним тим самим куском кода. Тобто це у нас, скоріше за все, буде умовно декілька контролерів, декілька якихось частин. Скоріше за все, ми можемо зробити умовно, що у нас є якийсь фітс-контролер, який буде нам якось обробляти ці івенти користувача з однієї сторінки; у нас буде інша сторінка, яка буде у неї умовно окремий контролер.

Що робити зі стейтом? Чи має бути це один стейт? Чи має бути це декілька окремих стейтів, які будуть для кожної сторінки свої? Тут гарне питання, і це має сенс саме зараз і проговорити. По-перше, скоріше за все, ми захочемо, щоб у нас була доволі швидка взаємодія з нашими додатками. Тобто ми переходимо, скажімо так, з однієї сторінки на іншу; ми бачимо нашу стрічку, переходимо в якийсь окремий твіт, повертаємося назад. Скоріше за все, було б краще з точки зору юзер-експірінг, щоб ми одразу щось показали, а вже потім у нас був лендінг, або оновлення. Тому, скоріше за все, ми захочемо мати якийсь глобальний стейт, який у нас буде використовуватися між нашими сторінками.

Добре, іще одне ми пам'ятаємо, що ми хотіли таку функцію зробити, щоб якщо людина почала писати твіт, а потім перейшла, наприклад, в стрічку, натиснула на якийсь твіт, і почитала там щось, на ріплай відповіла, повернулася назад, у нас залишився цей драфт. Теж, скоріше за все, ми будемо це в нашому загальному стейті зберігати і просто потім з нього считувати, коли переходимо. Так, звичайно, тут у нас умовно буде така взаємодія. Так, звичайно, тут ще раз хочу сказати, що це не якесь єдине правильне рішення. Тобто тут можуть бути варіанти. Ви можете все ж таки розділити цей стейт, ви можете якось по-іншому згрупувати ці компоненти. Проте важливо, щоб, скажемо так, це саме рішення буде залежати від тієї задачі, яку ви вирішуєте, можливо, від вхідних параметрів, які ви обговорили з інтерв'юером. Тому тут ще раз можна перепитувати, чи на правильному є шляху, чи взагалі має це сенс те, що ми робимо.

Добре, вважаємо, що ми на правильному шляху, продовжуємо. Що далі? Ми вже казали, у нас буде декілька стрінок. Скоріше за все, у нас буде роутер. Тобто нам десь треба розуміти, що ми перемикаємося з однієї стрінки на іншу, наприклад. А також, скоріше за все, нам десь треба, хоч ми казали, що нам авторизація не потрібна, але нам все ж таки потрібно, буде певно, ми захочемо десь аватарку користувача, наприклад, показати, або, я не знаю, його ім'я написати. Тобто ця логіка має бути десь. Наприклад, ми її помістимо в наш умовний аплікейшн контр. Теж в лапках, тому що це все залежить від фреймворку, який ви виберете. Ну і, звичайно, взаємодія з бекендом. Взаємодія з бекендом, так звичайно, для фідів у нас буде свій набір запитів. Для відправки, для показу реплаїв у нас буде інший API. Можливо, у нас ще буде API, як ми отримуємо інформацію про користувача. І, грубо кажучи, все це буде взаємодія з сервером.

Ще раз перепитали, чи ми робимо те, що очікувалось. Можливо, тут можуть бути відповіді коли як за. А от уточніть, будь ласка, а що ми будемо робити у тому варіанті. А там, наприклад, а уточніть, будь ласка, я не зовсім розумію, можливо, моделі якісь треба прояснити. А як стейт? Якщо так, ми повертаємося до цього, уточнюємо нашу діаграму. Якщо ні, ну, продовжуємо. Наприклад, що наступне, давайте поговоримо, а що у нас в нашому стейті буде, тобто, нашу, умовно, модель даних. Тобто, взагалі, що ми там будемо зберігати, як воно буде виглядати, можливо, якісь деталі хочемо тут проговорити. Ну, по-перше, користувачі. Тут все доволі просто, інформація, юзернейм, URL, нічого складного. Ми йдемо далі, стрічка. А що має бути в стрічці? Ну, в стрічці, скоріше за все, будуть наші твіти. Ми казали, що у нас буде контент тільки зі строки. Можливо, кількість лайків нам треба показати. Ну, звичайно, ID. Ми будемо клікати на них, відкривати стрінку. Тобто, ми, скоріше за все, цю ID будемо використовувати, звичайно, для отримання саме конкретного твіта. Що ще ми можемо зберігати? Ну, ми можемо тут, наприклад, ми казали про пагінацію. Тобто, пагінацію як ми будемо робити? Ну, давайте, звичайно, зробимо інфініті скрол. Тобто, користувач це скролить, і у нього підгружається якась інформація.

Ну, тут ми можемо як зробити? Щоб, скажімо так, денормалізувати наші дані і використовувати, наприклад, таймстамп останнього твіта. Тобто, нам тут пейдж-каунтер не дуже підходить, тому що, насправді, поки там юзер щось читав, поки вирішив поскролити, скоріш за все, ми вже знаходимося на першій стрінці. Це взагалі, якщо у нас твіти будуть відсортовані за часом створені. Ані, ще буде якась окрема додаткова логіка. Ну, так як ми про це нічого не казали, то будемо вважати, що якщо людина скролить, наш користувач скролить місць, то ми просто будемо робити запит на, а що там було перед останнім, який ми бачили. Далі ми казали, що нам потрібен режим драфту, тобто, скоріш за все, ми теж хочемо це зберігати.

Тобто, як контент, контент ми казали тільки строка, ну, і статус, який там у нас, валідація, не валідація, ми в процесі відправки, можливо, там щось ретрає, будемо робити про це пізніше. Ну, і який статус, тобто, коли ми ходимо між стрінками, ми раз таки вичитали цю інформацію з нашого стейта і показали те, що там було. Вважаємо, що це поки що все. Ще раз перепитали, нічого ми не пропустили, окей. Двигаємося далі. Тобто, що ми отримуємо, у нас є, ви пам'ятаєте, у нас є десь реквайермент, у нас є така високорівнева діаграма і у нас є наша дата-модель десь біля стейту. Так, звичайно, якщо у вас буде декілька стейтів, то має сенс проговорити про кожен з них, можливо, стейт там всередині компонентів, або як ви конкретно будете вирішувати конкретну задачу.

Добре, є ще, якщо ми проговорили, що все добре, тоді логічно, що нам треба переключатися на наступний етап, це у нас API. Тут, насправді, дуже важливо зрозуміти, а яка саме у нас буде взаємодія. Чи потрібна нам двостороння взаємодія, чи потрібно нам в реалтаймі це робити, я не знаю, можу використовувати вебсокет, лонгполінг, http, ес, звичайно, все має бути сек'юрно, або нам це, під час реквайерментів ми це проговорили, тому, насправді, тут нам особливо можна не думати, тобто ми казали, що з періодичністю в 10 секунд ми будемо ходити і питати, що ж там відбувається. Теж двостороння, та наче не потрібно нам нічого туди слати, щоб отримувати у відповідь. І тоді давайте проговоримо, а взагалі що ми будемо туди-сюди пересилати. Взагалі це може бути оформлено дуже по-різному, ви можете це написати просто списком в якомусь текстбоксі, ви можете намалювати це, скоріше це буде списком написати взагалі, які у нас буде інпоінти і що вони будуть робити. Проте саме тут для наглядності у нас є такі два прямокутники, клієнт-сервер, у нас тут будуть стрілочки, які будуть показувати наші запити. Значить перше, що нам потрібно? Користувач відкрив сторінку, ми пам'ятаємо, нам треба загрузити список наших твітів, щось показати. Яке тут може бути API? По-перше, певно, що це буде простий get-запит. Можливо, ми можемо сюди додати кількість, яку ми хочемо.

Ми казали, що там буде 50. Можемо зазамовчувати до 50, проте вдруг ми захочемо якось цим експериментувати чи це вираховувати на клієнті. Хай буде count. І, як ми казали, для пагінації нам потрібен таймстамп. Тут він має бути опціональним, тому що зазвичай ми можемо використовувати один тай самий інпоінт для різних цілей. Тобто, зазамовчуванням це буде останній, наприклад. А якщо ми передамо таймстамп, то це будуть з початку, від цього таймстампу в минуле. У відповідь ми отримуємо наш масив твітів. Наступне. Окрема сторінка. Так, ми клікуємо на твіт. І в нас має відкритися сторінка. Тут звичайний get-запит, який нам достатньо ID, і він буде нам повертати інформацію про кількість наших запитів.

Вибачте за кількість наших твітів. І я не знаю, як великий цей масив наших відповідей. Йдемо далі. Що нам потрібно? Скоріше за все, тут у нас буде такий же інфініті скрол. Тому, ми захочемо додавати ці реплай, якщо їх більше, наприклад, 50, які були у нас в початковому масиві. Відповідно, будемо використовувати той самий API, що і для підгрузки наших твітів. І, звісно, останнє, що ми хочемо – це пост, в якому ми будемо створювати новий твіт. Тут у відповідь нам просто буде приходити твіт, і ми його додамо до нашої стрічки, наприклад, зверху. Майже все обговорили тут. Знову перепитаємо, чи нічого ми не пропустили, чи, можливо, ми хочемо ще про щось поговорити, чи, я не знаю, чи потрібно щось більше складне API.

Звісно, якщо маємо справу з колаборацією або синхронізацією між клієнтами, то це вимагатиме іншого підходу. Там можливі вебсокети, long polling, і можливо, трошки більше часу для обговорення API, оскільки виникають питання щодо вирішення конфліктів між клієнтом та сервером, або те, як ми вирішуємо оновлення тощо. Якщо все в порядку, то зараз ми маємо високорівневу діаграму, і переходимо до етапу більш конкретної дискусії щодо наших модулів, можливо, з уточненнями, які можуть знадобитися. Також важливо взяти паузу тут і знову запитати, чи хочемо ми обговорити щось конкретне. У цьому випадку ми вже пам'ятаємо, що ми говорили про доступність і помилки, і ми будемо говорити про них, але якщо ви все розглянули швидко, можна спитати, чи є щось, що потрібно обговорити. Якщо вас запитають, чи можливо ви ще щось покращите, тут вже час використовувати ваші глибокі знання фронтенду і розповісти про конкретні аспекти, які ви володієте.

Наприклад, ви можете запропонувати обговорення аспектів доступності. Я знаю багато про accessibility. Давайте обговоримо це, я вважаю, що це важливо. Добре, у нашому випадку дві теми: обробка помилок і accessibility. Щодо обробки помилок, очевидно, що ми повинні враховувати можливі проблеми з мережею, невстановлене Інтернет-з'єднання і т.д. Тут виникають різні варіанти, такі як 500, 404, повторення тощо. Якщо повторення не допомагають, ми можемо показати сповіщення про те, що щось пішло не так. Можливо, навіть варто розглянути більш складні сценарії, такі як робота в автономному режимі, але, можливо, в нас немає такого плану. Можемо вивести офлайн/онлайн статус і показати повідомлення, якщо сайт не доступний. Тут можна також розглянути можливість створення сервісу або мідлвару, що слідкуватиме за запитами і визначатиме, якщо вони повертають помилку, перевірятиме статус офлайн/онлайн і відображатиме повідомлення або сповіщення.

Щодо доступності, головне питання полягає в тому, які конкретні рішення ми хочемо впровадити для нашого сайту. Тут можна відзначити початок з простих аспектів, таких як семантична верстка, табордери, контраст, шрифти, і поступово переходити до більш складних питань, таких як підтримка скрінрідерів. Якщо є відкриті питання, можна вивести їх і пропонувати конкретні рішення. В цілому, ми переходимо в деталі, періодично перепитуючи, чи є сенс розглядати ще більше глибоких аспектів, чи можливо, маємо інші питання для обговорення. На кінцевому етапі ми перепитуємо, чи бажаємо ще щось обговорити. Якщо ні, інтерв'юер підтверджує, що всі питання вирішені, і ми завершуємо обговорення.

Отже, що ми отримуємо в кінці? Ми отримуємо нашу діаграму API, можливо, з якими-то уточненнями, наприклад, наша сторінка помилок (Error Page) з'явилася, і ми також маємо наші вимоги. І так, у нас є розуміння того, до чого ми дійшли. Можливо, ми щось пропустили або неправильно зрозуміли, але у нас все ж є розуміння того, в якому напрямку ми рухаємося з цією задачею. І, на завершення, декілька рекомендацій або того, на що варто звернути увагу. По-перше, ще раз підкреслюється важливість розуміння завдання, оскільки завдання можуть бути різними. Слід намагатися не спиратися на свої попередні досвіди, оскільки навіть якщо ви вже стикалися зі схожою задачею, може бути якийсь нюанс, який робить ваші звичайні рішення непридатними для конкретного випадку.

Тому важливо не поспішати, спокійно періодично перевіряти наші вимоги, які ми записали, і перепитувати інтерв'юера, чи ми на правильному шляху, чи все в порядку. Має сенс уникати занадто складних рішень, починати з високорівневого підходу і потім поглиблюватися, докладно обговорюючи кожен модуль. Звісно, слід контролювати час, оскільки можна застрягти на одному модулі, і не вистачить часу на вирішення всіх завдань.

Якщо ви щось не знаєте або не розумієте, це абсолютно прийнятно сказати. Краще відверто заявити, що ви не розумієте, ніж вигадувати щось на ходу, оскільки це легко помітити. Використовуйте свої знання, готуйтеся, нічого складного в цьому немає, все досить стандартно. Щодо ресурсів по системам дизайн-інтерв'ю для фронтендів, їх не так багато, але ось декілька корисних посилань. Наприклад, на FWD декілька років тому була цікава доповідь про архітектуру в інтерв'ю, можливо, вам буде цікаво подивитися інтерв'ю з іншого ракурсу. І, звісно, нагадуємо всім підтримувати Україну, надавати допомогу і пам'ятати, що кожен донат є важливим. Дякую, це все.